What is a Shared Access Signature (SAS) in Azure?

Introduction

Shared Access Signature (SAS) in Azure is a secure way to grant limited access to Azure Storage resources without sharing our account keys. It provides a fine-grained mechanism to control access to specific resources in our storage account for a specified period and with designated permissions. This is commonly used to allow temporary or delegated access to storage resources.

Why Use SAS?

Imagine we need to share a file or let an app access our storage—but we don’t want to share our primary account keys or give more access than necessary. That’s where SAS comes in. With SAS, we can:

• Control Access: Decide exactly what actions can be performed (read, write, delete, etc.).
• Set a Time Limit: Define when the access starts and ends.
• Restrict to Specific Resources: Share only what’s needed—nothing more.

It’s like handing someone a key that works only for one door, only for a specific time, and only for specific tasks.

How Does SAS Work?

1. Generate a SAS Token:
   A SAS token is a unique string containing permissions, expiration times, and other access details. It’s appended to the resource’s URL.
2. Share the SAS URL:
   This URL grants access to the resource under the rules we’ve defined. For example:https://mystorage.blob.core.windows.net/mycontainer/myfile.txt?sv=2024-08-01&sp=rw&se=2024-11-30T00:00:00Z&sig=signature
3. Access the Resource:
   The recipient uses the URL to interact with the resource as permitted.

Types of SAS

Azure offers three types of SAS to fit different use cases:

1. Service SAS
   • Grants access to a specific resource, such as a blob, file, or queue.
   • Permissions are customizable (e.g., read-only, write, delete).
   • Example: Allow a client to upload files to a specific container.
2. Account SAS
   • Provides broader access, covering multiple services in our storage account (blobs, files, queues, tables).
   • Example: Temporarily grant access to multiple storage types for a data migration.
3. User Delegation SAS
   • Ideal for Blob Storage when using Azure Active Directory (Azure AD) for authentication.
   • Example: Grant temporary access to a user authenticated via Azure AD.

How to Create SAS in Azure Portal

Here’s a quick guide to creating the three types of SAS in the Azure Portal:

1. Service SAS

Grants access to a specific resource (e.g., blob, file, or queue).

1. Navigate to our Storage Account.
2. Select the desired resource (e.g., A specific Blob, Container, Queue, or Table).
3. Go to Shared Access Tokens in the settings and set the following:
   • Signing method as Account key. Options are Account key and User delegation key.
   • Signing key (Key1 | Key2)
   • Stored access policy (optional)
   • Permissions (e.g., Read, Write)
   • Start and expiry date/time
   • Allowed IP addresses (optional)
   • Allowed protocols (HTTPS only | HTTPS and HTTP). 
4. Click on Generate the SAS token and URL
5. Share it.

What is a Stored Access Policy?

A Stored Access Policy is a centralized method for managing permissions and time constraints for Shared Access Signatures (SAS) in Azure. Instead of embedding these settings in every SAS token, the policy is attached to a container or blob, allowing multiple SAS tokens to reference it. This makes access control more streamlined and manageable.

One of the key benefits of a Stored Access Policy is centralized management, where permissions, start times, and expiry times are defined in a single location. We can modify or revoke access centrally, instantly affecting all linked SAS tokens. It also provides reusability, enabling the same policy to be applied across multiple SAS tokens, reducing redundancy. Additionally, it enhances security by offering a single point of control for access settings.

A Stored Access Policy is ideal for scenarios where multiple SAS tokens share the same settings or where frequent updates or revocations are required. However, it has some limitations: it is only available for Blob Storage and File Storage, and a maximum of five stored access policies can be created per container or file share. 

2. Account SAS

Provides broader access across multiple services in the storage account.

1. Navigate to our Storage Account.
2. Under Security+Networking, select Shared Access Signature.
3. Set the following options:
   • Allowed services (Blob | File | Queue | Table)
   • Allowed resource types (Service | Container | Object)
   • Allowed permissions (Read | Write | Delete | List | Add | Create | Update | Process | Immutable storage | Permanent delete)
   • Blob versioning permissions (Enables deletion of versions checkbox)
   • Allowed blob index permissions (Read/Write | Filter).
   • Start and expiry date/time – Start is optional and Expiry is mandatory
   • Allowed IP addresses
   • Allowed protocols (HTTPS only | HTTPS and HTTP)
   • Preferred routing tier (Basic (Default) | Microsoft network routing | Internet routing) – Ensure that the endpoints are explicitly published under ‘Firewalls and virtual networks’ settings before selecting the routing tier options Microsoft network routing and Internet routing.
   • Signing key (Key1 | Key2)
4. Click on Generate SAS and connection string
5. Copy the SAS token or full URL and share it with the authorized users or applications.

3. User Delegation SAS

Ideal for secure access to Blob Storage with Azure AD authentication. 

1. Navigate to our Storage Account.
2. Go to Access control (IAM), add a role assignment (e.g., Storage Blob Data Contributor), select the user or service principal, and save; allow up to 10 minutes for the changes to take effect.
3. Go back to our Storage Account’s main page, select the resource (e.g., A Blob or a Container), and go to Shared Access Access in case of container or Generate SAS in case of a blob. 
4. For Signing method, choose User delegation key. If enough permissions are not there as we did in step 2, we will get an error like “You don’t have permissions to grant read access. You can still create a shared access signature, but you’ll need an RBAC role with additional permissions before you can grant that level of access to your signature recipient.”.
5. Set Permissions
6. Set Start and expiry date/time.
7. Set Allowed IP addresses (Optional).
8. Set Allowed protocols (HTTPS only | HTTPS and HTTP)
9. Click Generate the SAS token or URL 
10. Share SAS token or URL.

Example Use Case

Let’s say you have a video stored in Azure Blob Storage, and you want to share it with a colleague for 48 hours. Here’s how you do it:

1. Generate a SAS token with read-only permissions and set it to expire in 48 hours.
2. Share the SAS URL with your colleague.
3. They can access the video until the token expires.

Once the time is up, the SAS token becomes invalid, and the URL stops working.

Best Practices for Using SAS

• Set Short Expiry Times: Limit how long the SAS token is valid to reduce security risks.
• Restrict Permissions: Grant only the minimum permissions needed (e.g., read-only if that’s all that’s required).
• Use HTTPS Only: Ensure secure transmission by enforcing HTTPS.
• Monitor and Revoke: Keep an eye on SAS activity and revoke tokens if suspicious behavior occurs.

Conclusion

Shared Access Signatures (SAS) in Azure are a powerful yet simple way to securely share and manage access to your storage resources. They give you precise control over who can access what, for how long, and what they can do.

Whether it’s sharing a file, enabling an app to upload data, or granting temporary access to a service, SAS helps you stay in control while keeping your account secure. Next time you need to grant access to Azure Storage, use SAS—it’s like a temporary key that works exactly how you want it to.

See also

• Read the blog post Understanding signing methods for azure shared access signatures sas.
• Read the blog post What is a stored access policy in azure.