Managing Shared Access Signatures (SAS)
In this tutorial, we will learn and understand about managing shared access signatures (SAS).
However, a shared access signature (SAS) provides secure delegated access to resources in your storage account without compromising the security of your data. You also have granular control over how a client may access your data with a SAS. You may also restrict the client’s access to resources and the permissions they have on those resources.
Types of shared access signatures
Azure Storage assists three types of shared access signatures:
- Firstly, User delegation SAS. This is secured with Azure Active Directory (Azure AD) credentials and also by the permissions specified for the SAS. However, a user delegation SAS applies to Blob storage only.
- Secondly, Service SAS. This refers to a secured SAS with the storage account key. However, a service SAS delegates access to a resource in only one of the Azure Storage services like blob storage, Queue storage or Table storage, or Azure Files.
- Thirdly, Account SAS. This is secured with the storage account key that assigns access to resources in one or more storage services. However, all of the operations available via a service or user delegation SAS are also available via an account SAS.
Further, a shared access signature can take one of two forms:
- Firstly, Ad hoc SAS. In this when you create an ad hoc SAS. Then, the start time, expiry time, and permissions for the SAS are all specified in the SAS URI. However, any type of SAS can be an ad hoc SAS.
- Secondly, Service SAS with stored access policy (SAP). Here, SAP outlines on a resource container, that can be a blob container, table, queue, or file share. Moreover, it can be useful in managing constraints for one or more service shared access signatures. And, when you associate a service SAS with a stored access policy. Then, the SAS inherits the constraints—the start time, expiry time, and permissions—defined for the stored access policy.
Working of Shared Access Signature
A signed URI that points to one or more storage locations is referred to as a shared access signature (SAS). It also contains a token with a unique set of query parameters. In this case, the token specifies how the client can access the resources. However, the signature, one of the query parameters, is created using SAS parameters. The SAS was then signed using the key that was used to create it. This signature is used by Azure Storage to authorise access to the storage resource.
SAS signature and authorization
There are two ways to sign a SAS token:
- Firstly, with a user delegation key that was created using Azure Active Directory (Azure AD) credentials.
- Secondly, with the storage account key (Shared Key). However, both a service SAS and an account SAS are signed with the storage account key.
However, when a request includes a SAS token, that request is authorized based on how that SAS token is signed. And, Azure storage also use the same access key or credentials that you use for creating a SAS token. This is for granting access to a client that possesses the SAS.
Summarizing how each type of SAS token is authorize when it includes on a request to Azure Storage. Check the below table:
When to use a shared access signature
SAS provides secure access to resources in your storage account to any client with having no permissions to those resources. A scenario where a SAS is useful is a service for users to read and write their own data to storage account include:
- Firstly, clients upload and download data via a front-end proxy service, which performs authentication. However, this front-end proxy service has the benefits of allowing validation for business rules. But, it may be costly for large amounts of data or transactions to create a service that can match demand.
- Secondly, a lightweight service authenticates the client as needed and then generates a SAS. And, after the client application receives the SAS, they have access to storage account resources directly with the permissions by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all data through the front-end proxy service.
Additionally, a SAS is necessary for authorizing access to the source object in a copy operation in certain scenarios:
- Firstly, when you copy a blob to another blob that resides in a different storage account. Then, you must use a SAS to authorize access to the source blob. However, you can optionally use a SAS for authorizing access to the destination blob as well.
- Secondly, when you copy a file to another file that resides in a different storage account, then you must use a SAS to authorize access to the source file. However, you can optionally use a SAS to authorize access to the destination file as well.
- Thirdly, when you copy a blob to a file or a file to a blob, then you must use a SAS for authorizing access to the source object.
Best practices when using SAS
When you use shared access signatures in your applications, then you need to be aware of two potential risks:
- Firstly, if there is a leak in SAS, then anyone who obtains it can use it, that can potentially compromise your storage account.
- Secondly, if a client application expires that SAS provides and the application is unable to retrieve a new SAS from your service, then the application’s functionality may delay.
Some of the following recommendations for using shared access signatures can help in mitigating these risks:
- Firstly, always use HTTPS for creating or distributing a SAS. However, if a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack is able to read the SAS and can use it just as the intended user.
- Secondly, use a user delegation SAS when possible. That is to say, a user delegation SAS provides superior security to a service SAS or an account SAS. Moreover, it is secure with Azure AD credentials, so that you do not need to store your account key with your code.
- Thirdly, have a revocation plan in place for a SAS.
- Fourthly, define a stored access policy for a service SAS. In other words, a stored access policy gives you the option to revoke permissions for a service SAS without having to regenerate the storage account keys.
- Then, be careful with the SAS start time. As if you set the start time for a SAS to the current time, then you may notice failures occurring intermittently for the first few minutes due to different machines having slight variations. However, in general, set the start time to be at least 15 minutes in the past. And, the same generally applies to expiry time as well–remember that you may notice up to 15 minutes of clock skew in either direction on any request. Further, for clients using a REST version prior to 2012-02-12, the maximum duration for a SAS that does not reference a stored access policy is 1 hour.
Reference: Microsoft Documentation