how to revoke Shared Access Signature in Azure SDK

Question

I could not find any code sample for revoking the created Shared Access Signature access on blob, can anyone provide me link or reference for removing the Shared Access Signatu

Answer 1

You can't revoke a shared access signature unless it is based on a stored access policy. See http://msdn.microsoft.com/en-us/library/azure/dn140257.aspx for more information:

To revoke a stored access policy, you can either delete it, or rename it by changing the signed identifier. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Deleting or renaming the stored access policy immediately effects all of the shared access signatures associated with it.

Answer 2

Even if shared access signature (SAS) is based on a stored access policy (SAP), you can only revoke SAP, not individual SAS.

Azure Storage security guide has good details: https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide#revocation

SAS not based on SAP - can't be revoked:

If you are using ad hoc URIs, you have three options. You can issue SAS tokens with short expiration policies and wait for the SAS to expire. You can rename or delete the resource (assuming the token was scoped to a single object). You can change the storage account keys. This last option can have a significant impact, depending on how many services are using that storage account, and probably isn't something you want to do without some planning.

SAS based on SAP - can be revoked by revoking SAP:

If you are using a SAS derived from a Stored Access Policy, you can remove access by revoking the Stored Access Policy – you can just change it so it has already expired, or you can remove it altogether. This takes effect immediately, and invalidates every SAS created using that Stored Access Policy. Updating or removing the Stored Access Policy may impact people accessing that specific container, file share, table, or queue via SAS, but if the clients are written so they request a new SAS when the old one becomes invalid, this will work fine.

Best practice:

Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.

Answer 3

I had the same problem and this is how I solved it:

The communication between the redacted service and Azure Blob Storage is done through the SDK v8.0.

Answer 4

Context

• MSFT Azure storage account (live version as of 2019-11-26)
• MSFT Azure storage permissions as managed by Shared Access Signature (SAS)

Problem

• User user145610 wants to immediately revoke a deployed SAS
  • (e.g., because SAS allows authentication into Blob Storage, and the SAS has been compromised, requiring immediate remediation to prevent unauthorized data breach)

Workarounds already mentioned

• Other answers already appear in this thread discussing the use of Shared Access Policy (aka Stored Access Policy) (SAP)
• SAS generated based on SAP has limitations, only five SAPs can be attached to a storage account

Workaround: Regenerating Account Keys

• One workaround that does not appear in this thread (at the time of this posting) is the ability to regenerate the account key used to originally create the SAS, as documented in one of the links in the see also section of this answer.

Regenerating an account key will cause all application components using that key to fail to authorize until they're updated to use either the other valid account key or the newly regenerated account key. Regenerating the account key is the only way to immediately revoke an ad hoc SAS.

• Consequently, one potential workaround is to generate and deploy SASs based on the secondary account key, and have the expectation that you will routinely regenerate the secondary account key whenever immediate revocation of one or more SASs becomes necessary.
  • (Obviously, this is not a desirable circumstance where many SAS tokens are deployed and dependent on the secondary account key, because they will all be rendered invalid upon regeneration of the key)

Solution

• The inability to deploy a large number of SAPs, combined with the potentially unfavorable side-effects of having to regenerate account keys suggests that a potential solution is to re-engineer the architecture of your project to use ActiveDirectory for controlling authorization and access control, and the generation of SAS tokens.
• SASs based on SAPs may be better suited for cases where there are only few clients requiring access, and the probability of the SASs getting compromised is extremely low.
• As of this writing, MSFT Azure storage supports the generation and use of SAS tokens based on ActiveDirectory accounts.

See also

• How many access policies can I create and add on the same one Azure container?
• https://docs.microsoft.com/en-us/azure/storage/common/storage-auth
• https://docs.microsoft.com/en-us/rest/api/storageservices/create-service-sas#revocation-of-a-sas
• https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview#types-of-shared-access-signatures
• https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas
• https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview#best-practices-for-using-sas