Shared Access Signature (SAS) tokens are great for sharing (limited) access to Azure Storage resources without using the storage account’s main key. You can generate a SAS-token on practically every storage resource and share them with your colleague’s, customers or anyone that needs to access your storage resource in any way.
You might wonder if SAS tokens are actually secure and safe to use. As usual, it depends. SAS tokens by themselves are secure in the sense that it is an encrypted token. The ‘sharing’-nature of SAS tokens however makes them susceptible to falling in the wrong hands. You see, once a SAS token is created, it cannot be revoked, it can only expire.
So how to secure SAS tokens then?
Assuming you want to share your tokens with non-Azure AD users (in that case you can use Azure’s IAM or User delegated SAS Tokens), there are some ways to increase the security of your SAS tokens. By the way, Azure has some best practices on SAS tokens here.
The basics, expiration, HTTPS, specificity and permissions
Your standard SAS token-generation window (see image below) in the Azure Portal allows you to set an array of security parameters when generating your token.
Be considerate for each one of the parameters you can choose, and use some common sense. Don’t set the expiry-date unnecessarily far into the future, don’t enable more permissions than required, always use HTTPS and only generate a token on the lowest level needed. If you only need to share 1 particular file, generate a read-token on that specific file and not on the entire container.
Also consider using the IP-addresses option to enable only selected IP-addresses to access your resources.
Okey…but what about revoking a SAS token when it’s no longer needed or compromised?
This is the problem with the standard use of SAS tokens, once created, they’re out there…uncontrolled, unrevokable….unsafe? Well there is a way to combat this helplessness and that is by using Stored Access Policies.
By creating a Stored Access Policy you can bind all your (selected) SAS tokens to a specific policy. Not only can you use these policies for centralizing common SAS settings (such as default permissions), but by deleting a policy, you automatically revoke all bound SAS tokens.
Therefor it is recommended that if you are sharing SAS tokens with no known expiration requirement, use Access Policies to take control back and to enable you to revoke the tokens when they are no longer needed (or compromised).
As a suggestion, create Access Policies for each group of token(s) for which you need to fully control its lifetime. Create one for a specific team that needs access to a certain Table in Table Storage, or for a specific customer that needs to access a container and you don’t want to send new tokens every so often.
Depending on the type of storage resource, you can generate Stored Access Policies via Settings > Access Policy
Then add a new policy and consider creating multiple policies for multiple revocation possibilities.
Don’t forget to press Save on the top of the screen after you added the policy.
Next, if you create a SAS token on a resource that has an Access Policy configured, select the policy and now your SAS token is bound to the policy. Removing the policy results in revoking the SAS token. Only need a token for a day for internal use? No worries, you can still create SAS tokens without your policy.
Using the Azure Storage Explorer for example, right click any resource that you’ve created the policy for (on its parent or itself), select Get Shared Access Signature and you will see the option to select your policy.
As you can see the token parameters are now grayed out because they are inherited from the Access Policy.
Try it out yourself and revoke a SAS token!