azurepermissionsazure-storageazure-blob-storage

Reputation: 3025

how to revoke Shared Access Signature in Azure SDK

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 Signature access created earlier.

Upvotes: 24

Answers (5)

Ilya Berdichevsky

Reputation: 1298

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://learn.microsoft.com/en-us/rest/api/storageservices/create-service-sas#revoke-a-sas

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.

Upvotes: 20

Tommy Leong

Reputation: 3030

Came across this topic too. As per highlighted by @IlyaBerdichevsky on the top, Best practice is to use a SAS derived from a Stored Access Policy.

TLDR;

Watch this youtube tutorial

(Step by step) How to create a SAS Derived from Store Access Policy?

First, setup Stored Access Policy

Go to your Azure Storage Resource
Click on containers (left panel under Data Storage), choose your container (because different container may setup different policy).
Click on Access Policy (left panel under Settings)
Click on Add policy
Here you may specify the desired policy you want (Sample in screenshot)
Click on OK
Tap on Save button on top (it reflects quickly actually, although it claimed to take about 30 seconds)

Second, generate SAS based on the SAP (Stored Access Policy) created

Back to Azure Storage Resource
Click on Storage Explorer (preview)
In my case I'm using Blob container, so I'll expand my blob container and click on the container I want. You shall see your file inside the container, once you've selected.
Right click on the file, click on Get Shared Access Signature.
Select the policy you have just created under the dropdown.
Tap on create
DONE! You've gotten your token now :)

How to revoke/extend the SAS token created for client?

Back to the policy you have setup
Update the expiry time
Save
TAAA-DAHH! Same link with the SAS token should expired/work now.

Upvotes: 4

dreftymac

Reputation: 32400

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 a blob container within 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.