Shared Access Signatures (SAS) in Azure provide secure delegated access to resources in your storage account without exposing your account keys. SAS tokens grant granular permissions to clients, allowing them to access specific resources for a defined time period.
**Types of SAS:**
1. **User Dele…Shared Access Signatures (SAS) in Azure provide secure delegated access to resources in your storage account without exposing your account keys. SAS tokens grant granular permissions to clients, allowing them to access specific resources for a defined time period.
**Types of SAS:**
1. **User Delegation SAS** - Secured with Azure AD credentials and applies to Blob storage only. This is the most secure option as it uses Azure AD authentication.
2. **Service SAS** - Secured with the storage account key and delegates access to a resource in a single Azure Storage service (Blob, Queue, Table, or File).
3. **Account SAS** - Secured with the storage account key and delegates access to resources in one or more storage services, offering broader permissions.
**Creating a SAS:**
To create a SAS, you specify:
- **Permissions** (read, write, delete, list, etc.)
- **Start and expiry times**
- **Allowed IP addresses**
- **Allowed protocols** (HTTPS only recommended)
- **Resource types** being accessed
**Implementation Example:**
csharp
BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
BlobContainerName = containerName,
BlobName = blobName,
Resource = "b",
StartsOn = DateTimeOffset.UtcNow,
ExpiresOn = DateTimeOffset.UtcNow.AddHours(1)
};
sasBuilder.SetPermissions(BlobSasPermissions.Read);
**Best Practices:**
- Always use HTTPS protocol
- Set the shortest practical expiration time
- Grant minimum required permissions following principle of least privilege
- Use stored access policies when possible for easier revocation
- Prefer User Delegation SAS over Service or Account SAS
- Implement proper error handling for expired tokens
**Stored Access Policies:**
These provide additional control by defining constraints on the server side. You can modify or revoke a stored access policy, which affects all SAS tokens associated with it, providing a mechanism to invalidate tokens when needed.
Create and Implement Shared Access Signatures (SAS)
Why Shared Access Signatures Are Important
Shared Access Signatures (SAS) are a critical security mechanism in Azure that allows you to grant limited access to your storage resources without exposing your account keys. This is essential for the AZ-204 exam because secure access delegation is a fundamental requirement for cloud applications. Using SAS tokens enables you to follow the principle of least privilege, giving clients only the permissions they need for a specific time period.
What Are Shared Access Signatures?
A Shared Access Signature is a URI that grants restricted access rights to Azure Storage resources. SAS tokens contain all the information needed to authenticate a request, including:
- The resource being accessed - The permissions granted (read, write, delete, list, etc.) - The time window during which the SAS is valid - The IP addresses from which requests are allowed - The protocol required (HTTPS or HTTP)
Types of Shared Access Signatures
1. User Delegation SAS (Recommended) - Secured with Azure AD credentials - Applies to Blob storage only - Most secure option as it does not require storing account keys
2. Service SAS - Secured with the storage account key - Delegates access to a resource in only one Azure Storage service (Blob, Queue, Table, or File)
3. Account SAS - Secured with the storage account key - Delegates access to resources in one or more storage services - Can delegate access to service-level operations
How Shared Access Signatures Work
1. Token Generation: You create a SAS token by specifying parameters like permissions, start time, expiry time, and allowed IP ranges.
2. Signing: The token is signed using either the storage account key (for Service and Account SAS) or Azure AD credentials (for User Delegation SAS).
3. Distribution: The SAS URI is provided to clients who need access to the resource.
4. Validation: When a client makes a request using the SAS URI, Azure Storage validates the signature and checks all constraints before granting access.
Creating a SAS in Code
For Blob Storage using C#:
User Delegation SAS: - Use BlobServiceClient with DefaultAzureCredential - Call GetUserDelegationKeyAsync() - Use BlobSasBuilder to define permissions and expiry - Generate the SAS token with ToSasQueryParameters()
Service SAS: - Use BlobSasBuilder with the storage account key - Set permissions, expiry, and resource type - Generate using ToSasQueryParameters() with StorageSharedKeyCredential
Best Practices for SAS Implementation
- Always use HTTPS to prevent token interception - Set the shortest practical expiration time - Grant minimum required permissions - Use User Delegation SAS when possible - Implement a stored access policy for Service SAS to enable revocation - Plan for SAS token renewal before expiration - Never include SAS tokens in application logs
Stored Access Policies
A stored access policy provides additional control over Service SAS tokens. Benefits include: - Ability to modify start time, expiry time, and permissions after the SAS is issued - Ability to revoke the SAS by deleting or modifying the policy - Up to 5 stored access policies per container
Exam Tips: Answering Questions on Create and Implement Shared Access Signatures
1. Know the SAS types: Questions often ask which SAS type is most appropriate. Remember that User Delegation SAS is the most secure and recommended option for Blob storage.
2. Understand revocation: Service SAS can only be revoked if created with a stored access policy. User Delegation SAS can be revoked by revoking the user delegation key.
3. Permission combinations: Be familiar with permission letters (r=read, w=write, d=delete, l=list, a=add, c=create, u=update, p=process).
4. Security scenarios: When a question mentions Azure AD or managed identities, User Delegation SAS is typically the answer.
5. Stored access policies: Remember they only work with Service SAS, not Account SAS or User Delegation SAS.
6. Time sensitivity: Questions about temporary access or time-limited scenarios point toward SAS solutions.
7. Code recognition: Be able to identify BlobSasBuilder, GetUserDelegationKeyAsync, and ToSasQueryParameters in code snippets.
8. Protocol requirements: If security is emphasized, the answer should include HTTPS-only SAS tokens.