In the context of Azure storage management, a Shared Access Signature (SAS) is a signed URI that grants restricted access rights to Azure Storage resources without exposing the master storage account keys. It is a critical mechanism for Azure Administrators to implement secure, delegated access adh…In the context of Azure storage management, a Shared Access Signature (SAS) is a signed URI that grants restricted access rights to Azure Storage resources without exposing the master storage account keys. It is a critical mechanism for Azure Administrators to implement secure, delegated access adhering to the principle of least privilege.
A SAS token allows granular control over three key parameters: the resources exposed (e.g., a specific blob versus an entire container), the permissions granted (e.g., Read, Write, List, Delete), and the duration of access (start and expiry times).
There are three primary types of SAS tokens:
1. **User Delegation SAS:** Secured via Microsoft Entra ID credentials. This is the most secure option for Blob storage as it does not require managing storage keys.
2. **Service SAS:** Delegates access to specific resources in the Blob, Queue, Table, or File services.
3. **Account SAS:** Grants access to operations at the service level (e.g., creating file systems) that a Service SAS cannot handle.
A crucial concept for the AZ-104 exam is the **Stored Access Policy**. If a standalone SAS is compromised, it can only be revoked by rotating the account keys, which may affect other applications. However, if a Service SAS is associated with a Stored Access Policy defined on the container, the administrator can revoke or modify access immediately by editing the policy, invalidating the tokens linked to it. Best practices include always using HTTPS, setting short expiration times, and prioritizing User Delegation SAS to minimize key exposure.
Mastering Shared Access Signature (SAS) Tokens for Azure Administrator (AZ-104)
What is a Shared Access Signature (SAS)? A Shared Access Signature (SAS) is a URI that grants restricted access rights to Azure Storage resources. It serves as a "guest pass" that allows you to provide granular access to clients who should not have the master Storage Account Key. The SAS is a string of query parameters appended to the resource URI, containing the permissions, timing, and security constraints.
Why is it Important? In the AZ-104 context, SAS tokens are vital for adhering to the Principle of Least Privilege. Sharing the primary Storage Account Key gives a user full administrative control (Super User access), which is a massive security risk. SAS tokens solve this by allowing you to specify: 1. Which resources (e.g., a specific blob vs. a whole container). 2. What permissions (e.g., Read-only, Write-only, List). 3. When access is valid (Start time and Expiry time). 4. Network constraints (Specific IP addresses or HTTPS only).
Types of SAS Tokens You must distinguish between these three types for the exam: 1. User Delegation SAS: Secured by Microsoft Entra ID credentials rather than the storage account key. This applies only to Blob and Azure Data Lake Storage Gen2. This is the most secure option and the Microsoft-recommended best practice. 2. Service SAS: Secured by the storage account key. It delegates access to a resource in one of the storage services: Blob, Queue, Table, or File. 3. Account SAS: Secured by the storage account key. It delegates access to resources across one or more of the storage services and includes service-level operations (like Get/Set Service Properties) not available in a Service SAS.
The Role of Stored Access Policies A Stored Access Policy is defined at the container level (blob container, file share, queue, or table). It is crucial for revocation. If you create a SAS without a policy (ad-hoc), the only way to revoke it is to regenerate the Storage Account Key, which breaks all other applications using that key. If you associate a SAS with a Stored Access Policy, you can revoke the SAS simply by deleting or modifying the policy.
Exam Tips: Answering Questions on Shared Access Signature (SAS) tokens When facing scenario-based questions in the AZ-104 exam, apply this logic:
1. Security Hierarchy: If the question asks for the most secure way to grant temporary access to blobs, choose User Delegation SAS (backed by Entra ID). If Entra ID is not an option, choose a Service SAS with a Stored Access Policy.
2. The "Vendor" Scenario: A common question involves allowing a third-party vendor to upload logs to a specific container for 24 hours. The answer is usually to generate a SAS token with Write permissions and a set Expiry Time. Do not give them the Access Key.
3. Revocation Requirements: If a requirement states, "You must be able to revoke access immediately without affecting other users," the answer must involve a Stored Access Policy. You cannot easily selectively revoke an ad-hoc SAS.
4. Troubleshooting Connectivity: If a user has a valid SAS but cannot connect, check the IP address restrictions or the Protocol (ensure they are using HTTPS if the SAS enforces it).
5. URI Structure: Recognize the parameters: sp=r (Read permission), se=2024... (Expiry date), and sig=... (The cryptographic signature).