Azure Storage Shared Access Signatures (SAS)

Introduction to Shared Access Signatures

Azure Storage Shared Access Signatures (SAS) provide a secure way to delegate limited access to objects in your Azure Storage accounts without exposing your account access keys. SAS allows you to grant clients access to specific resources for a specified period, with a specific set of permissions.

This tutorial will guide you through understanding, creating, and managing SAS for your Azure Storage data.

What are Shared Access Signatures?

A Shared Access Signature is a URI that contains a security token in its query parameters. This token allows a client to access storage resources only as permitted by the SAS, including:

• Permissions: What operations are allowed (e.g., read, write, delete).
• Access Policy: When the SAS is valid (start and expiry time).
• Resource Type: What resources the SAS applies to (e.g., a blob, container, queue, table).
• IP Address/HTTP Headers: Constraints on where the request can originate from.

SAS is a powerful tool for granting temporary, granular access to your storage, enhancing security and control.

Types of SAS

Azure Storage supports two types of SAS:

Creating a Shared Access Signature

You can generate a SAS using various methods:

Using the Azure Portal

The Azure Portal provides a user-friendly interface for generating SAS:

1. Navigate to your storage account in the Azure Portal.
2. In the left-hand menu, select the resource (e.g., Blob containers, File shares, Queues, Tables).
3. Select the specific resource (e.g., a blob, a queue).
4. In the resource's menu, find the "Shared access signature" option.
5. Configure the desired permissions, expiry date/time, and any other constraints.
6. Click "Generate SAS token and URL".
7. The SAS token and its full URL will be displayed. Copy these securely.

Using Azure CLI

The Azure CLI provides command-line tools for generating SAS:

az storage blob generate-sas --account-name mystorageaccount --container-name mycontainer --name myblob.txt --permissions r --expiry 2024-12-31T12:00:00Z --output tsv

This command generates a read-only SAS for a specific blob that expires on December 31, 2024.

Using Azure PowerShell

Azure PowerShell also offers cmdlets for SAS generation:

New-AzStorageBlobSASToken -Service Blob -Container "mycontainer" -Blob "myblob.txt" -Permission r -ExpiryTime (Get-Date).AddDays(1) -FullUri

This PowerShell command generates a read-only SAS for a blob that is valid for one day.

Using SDK

You can programmatically generate SAS using Azure Storage SDKs for various languages like .NET, Java, Python, and Node.js. This is ideal for applications that need to dynamically generate SAS.

For example, in Python:

from azure.storage.blob import BlobServiceClient, AccountSasPermissions, ResourceTypes

                    connect_str = "YOUR_AZURE_STORAGE_CONNECTION_STRING"
                    blob_service_client = BlobServiceClient.from_connection_string(connect_str)

                    sas_permissions = AccountSasPermissions(read=True, list=True)
                    sas_resource_types = ResourceTypes(container=True, object=True)

                    sas_token = blob_service_client.generate_account_sas(
                        resource_types=sas_resource_types,
                        permission=sas_permissions,
                        expiry=datetime.utcnow() + timedelta(hours=1)
                    )
                    print(f"Account SAS token: {sas_token}")

Understanding SAS Permissions

SAS permissions are granular and can be assigned to different resource types:

• Read (r): Allows clients to read data and metadata.
• Write (w): Allows clients to write data and metadata.
• Delete (d): Allows clients to delete data.
• List (l): Allows clients to list blobs/files within a container/share.
• Add (a): Allows clients to add blobs/files.
• Create (c): Allows clients to create blobs/files.
• Update (u): Allows clients to update blob properties.
• Process (p): Allows clients to process messages in a queue.
• All (a): Grants all available permissions.

SAS Expiry and Constraints

When creating a SAS, you must define its validity period and other constraints:

• Expiry Time: The date and time when the SAS becomes invalid. It's crucial to set a reasonable expiry to mitigate security risks if the SAS is compromised.
• Start Time: (Optional) The date and time when the SAS becomes valid.
• IP Address/HTTP Headers: You can restrict access to specific IP addresses or require specific HTTP headers for requests made with the SAS. This adds an extra layer of security.

Best Practices for Using SAS

• Principle of Least Privilege: Grant only the necessary permissions.
• Set Expiry Dates: Always specify an expiry time. Avoid creating indefinitely valid SAS.
• Use HTTPS: Always use HTTPS to ensure the SAS token is transmitted securely.
• Store SAS Securely: Treat SAS tokens like connection strings or access keys.
• Revoke SAS if Compromised: If you suspect a SAS has been compromised, the best way to revoke it is to regenerate the account access key. For service SAS, revoking often means waiting for the expiry.
• Consider Account SAS Carefully: Account SAS are powerful. Use them judiciously and with strict expiry policies.

Common SAS Use Cases and Examples

• Granting temporary upload access to a web application: Allow users to upload files to a blob container for a limited time.
• Sharing read-only access to a public asset: Provide a SAS URL for a user to download a specific image or video without exposing container access.
• Allowing a background job to process messages in a queue: Grant a service read and delete permissions for messages in a queue for a specific duration.

For more detailed code examples in various languages, please refer to the official Azure Storage documentation.