Grant Access using Shared Access Signatures
A shared access signature (SAS) provides secure delegated access to resources in your storage account without compromising the security of your data. With a SAS, you have granular control over how a client can access your data. You can control what resources the client may access, what permissions they have on those resources, and how long the SAS is valid, among other parameters.
Types of shared access signatures
Azure Storage supports three types of shared access signatures –
- User delegation SAS. A user delegation SAS is secured with Azure Active Directory (Azure AD) credentials and also by the permissions specified for the SAS. A user delegation SAS applies to Blob storage only.
- Service SAS. A service SAS is secured with the storage account key. A service SAS delegates access to a resource in only one of the Azure Storage services: Blob storage, Queue storage, Table storage, or Azure Files.
- Account SAS. An account SAS is secured with the storage account key. An account SAS delegates access to resources in one or more of the storage services. Additionally, with the account SAS, you can delegate access to operations that apply at the level of the service, such as Get/Set Service Properties and Get Service Stats operations.
Assigning SAS Signature
We can sign a SAS in one of two ways:
- With a user delegation key that was created using Azure Active Directory (Azure AD) credentials. A user delegation SAS is signed with the user delegation key. To get the user delegation key and create the SAS, an Azure AD security principal must be assigned a role-based access control (RBAC) role that includes the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action. For detailed information about RBAC roles with permissions to get the user delegation key, see Create a user delegation SAS (REST API).
- With the storage account key. Both a service SAS and an account SAS are signed with the storage account key. To create a SAS that is signed with the account key, an application must have access to the account key.
How to use a shared access signature?
Use a SAS when you want to provide secure access to resources in your storage account to any client who does not otherwise have permissions to those resources.
A common scenario where a SAS is useful is a service where users read and write their own data to your storage account. In a scenario where a storage account stores user data, there are two typical design patterns:
- Clients upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service has the advantage of allowing validation of business rules, but for large amounts of data or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.
- A lightweight service authenticates the client as needed and then generates a SAS. Once the client application receives the SAS, they can access storage account resources directly with the permissions defined 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.
Best Practices for using SAS to mitigate Risks
- Always use HTTPS
- Use a user delegation SAS when possible
- Have a revocation plan in place for a SAS
- Define a stored access policy for a service SAS
- Use near-term expiration times on an ad hoc SAS service SAS or account SAS
- Have clients automatically renew the SAS if necessary
- Be careful with SAS start time
- Be careful with SAS datetime format
- Be specific with the resource to be accessed
- Understand that your account will be billed for any usage, including via a SAS
- Validate data written using a SAS
- Know when not to use a SAS
- Use Azure Monitor and Azure Storage logs to monitor your application
Reference: Microsoft Documentation