3.1.5.2. Implement Shared Access Signatures (SAS)

First Principle: Shared Access Signatures (SAS) enable secure, granular, and time-limited access to Azure "Storage resources"—without exposing "storage account keys". "SAS tokens" are appended to "resource URIs", specifying what access is allowed, for how long, and under what conditions.

What It Is: A "Shared Access Signature (SAS)" is a URI that grants restricted access rights to your Azure "Storage resources".

Visual: "Shared Access Signature (SAS) Workflow"

Loading diagram...

Types of SAS:

• "Service SAS": Grants access to a specific resource (blob, file, queue, or table) within a "storage account".
• "Account SAS": Grants access to multiple services ("blob", "file", "queue", "table") in a "storage account", allowing broader operations than a "Service SAS".
• "User Delegation SAS": Uses "Entra ID" credentials and "RBAC" for authentication, providing enhanced security and auditing compared to "Service" or "Account SAS". Preferred for "blobs"/"containers" if supported.

"SAS Token Components":

• "Resource URI": The address of the "storage resource".
• "Signed Start/Expiry Time": Defines when access begins and ends, ensuring time-limited access.
• "Permissions": Specifies allowed actions (read, write, delete, list, etc.).
• "IP Address Range" (optional): Restricts access to specific client IPs.
• "Protocol": Enforces "HTTPS"-only access for security.

Common Use Cases:

• Allowing clients to upload/download files directly to "storage" (e.g., direct upload from a browser to "Blob Storage").
• Granting temporary access to analytics or processing jobs to specific data.
• Distributing access to specific files or data to external partners for a limited time.

Best Practices:

• Set the shortest practical expiry time.
• Grant only the minimum permissions needed ("least privilege").
• Always use "HTTPS" to prevent "SAS token" interception.
• Revoke "SAS tokens" immediately if compromise is suspected (by revoking the underlying stored access policy, if used, or changing the "storage account key" for "account SAS").
• Prefer "User Delegation SAS" for "blobs"/"containers" when possible as it offers better auditing.

Scenario: You have an Azure Blob Storage container where users upload large video files. Your application's client-side JavaScript code needs to upload these files directly, but you don't want to expose your storage account access keys to the client. The access should be valid for only 30 minutes for each upload.

Reflection Question: How does implementing "Shared Access Signatures (SAS)" (specifically a "Service SAS" with limited permissions and a short expiry time) fundamentally enable secure, granular, and time-limited access to Azure Storage resources without exposing storage account keys, making it ideal for direct client-side uploads?

💡 Tip: Never hardcode "SAS tokens" directly into client-side code. Always generate them on your backend service and provide them to the client just-in-time.