Shared Access Signatures (SAS) are one way to provide secure access to your Azure Storage Accounts. SAS tokens come in 3 different flavors, each with their own positives and negatives. What are the differences between each type of SAS? Which one should you use, and when? What are Microsoft's recommended best practices? Well, that's what I plan on discussing in this post.
Basics
First, let's discuss some basics of Azure Storage & SAS Tokens.
Azure Storage supports 4 major services:
Azure Blob Storage
Azure Queue Storage
Azure Table Storage
Azure Files
SAS tokens come in 3 possible flavors:
User Delegation SAS
Service SAS
Account SAS
The 3 types of SAS tokens are quite different from each other. Things that vary include which of the 4 storage services are supported, how the SAS token in signed, whether the SAS token supports Stored Access Policies, and more. Here's a high level comparison of the 3 types of SAS tokens. This will all be explained further in this post.
SAS Type | Supports | Signed By | Stored Access Policy | Notes |
|---|---|---|---|---|
User Delegation | Blob | User Delegation Key | No | Microsoft recommended |
Service | Blob, Queue, Table, File (1 per service) | Storage Account Key | Yes | Some operations not permitted |
Account | Everything in the account | Storage Account Key | No |
Lastly, each Storage Account has 2 "master" keys, called the Storage Account Keys. These master keys can be used to sign certain types of SAS Tokens.
Security
It is very important that you take security in mind when dealing with SAS tokens. SAS tokens are like passwords that grant permission to the underlying Storage Account. You should protect SAS tokens the same way you would protect a normal password.
Some unfortunate negatives around SAS tokens and security:
Per the Microsoft documentation, it is NOT possible to audit the creation of SAS Tokens. Azure Storage doesn't track the number of SAS tokens that have been created, and no API exists that can provide this info.
This means if a user has the necessary permissions, then they can create a SAS Token without notifying the owner of the Storage Account.
Anybody who obtains a SAS Token is able to use it, regardless of who created it. This means if a SAS Token is accidentally exposed, then it can be used by anyone in the world.
An unlimited number of SAS Tokens can be created on the client side.
I hope you can see that you need to take great care in dealing with SAS Tokens. Be cautious about which users have the ability to create SAS Tokens. And make sure to properly secure all SAS Tokens as well. Lastly, it is very important to have a plan in place for when a SAS Token is compromised.
SAS type 1: User Delegation SAS
The first type of SAS Token we'll discuss is the User Delegation SAS. This type of token is signed by a User Delegation Key, which is tied to a specific user credential from Entra ID. Microsoft's recommendation is to use this type of SAS Token whenever possible as a security best practice.
One drawback is that the User Delegation SAS supports the Blob service only. It does not support the Queue, Table, of Files services.
The final permissions that are granted on the Storage Account will be a combination of:
The Entra ID's RBAC permission on the Storage Account
The permission on the SAS Token
SAS type 2: Service SAS
Service SAS Tokens are created at the individual service level. So, you would create one SAS for Blob, one SAS for Queue, etc. You could even be more granular than that, if you wish. For example, you could create a Service SAS on an individual Blob Container, or even an individual Blob Container Folder (but this requires the Storage Account to be configured with the hierarchical namespace feature).
Service SAS Tokens are signed by the Storage Account Keys, so you must either possess those or have permissions to access those.
One drawback is that a Service SAS is not allowed to do certain types of operations. For example, it can not create a Blob Container. For a full list of the disallowed operations, please see the docs.
Optionally, Service SAS Tokens can be connected to a Stored Access Policy. Using Stored Access Policies is actually a best practice recommendation from Microsoft. Note that Stored Access Policies only support Service SAS Tokens, they do not work with the other 2 types of SAS Tokens. A Stored Access Policy defines settings such as token start time, token expiration time, and token permissions. A single Stored Access Policy can be used to generate one or more Service SAS Tokens, and those tokens will inherit the settings defined by the Policy.
SAS type 3: Account SAS
Account SAS Tokens are created at the top-level of the Storage Account, and they have access to everything included in the Storage Account. This will let you do anything, even the operations that are not permitted by Service SAS Tokens.
Account SAS Tokens are signed by the Storage Account Keys, so you must either possess those or have permissions to access those.
Revoking SAS Tokens
It's important to understand how to revoke a SAS Token.
User Delegation SAS Tokens (type 1) will be revoked when one of the following happens:
The SAS Token has reached its expiration time.
The User Delegation Key has been revoked, and therefore any SAS Tokens signed by that key will be revoked.
There is a specific API that can be used to revoke the User Delegation Key.
Change or remove the RBAC role assignment on the Storage Account for the Entra ID security principal that was used to create the SAS
Service SAS or Account SAS Tokens (types 2 & 3) will be revoked when:
An ad-hoc SAS Token has reached its expiration time.
A Stored Access Policy has reached its expiration time. Therefore, any SAS Tokens tied to the policy will be revoked.
A Stored Access Policy has been deleted. Therefore, any SAS Tokens tied to the policy will be revoked.
A Storage Account Key has been re-generated. Therefore, any SAS Tokens signed by the Account Key will be revoked.