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

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