AZ-204 Developing Solutions for Microsoft Azure Exam

Understand the Types and Permissions of SAS

Shared Access Signature (SAS) is a URI that lets you delegate access to Azure storage resources without sharing your account keys. With a SAS, you can define permissions, start and expiry times, and allowed protocols to restrict how clients interact with your storage. This approach enforces the principle of least privilege by granting only the rights needed for a limited period. By using SAS tokens, you reduce the risk of exposing sensitive keys and simplify token management. Temporary access and fine-grained control make SAS an essential tool for secure data sharing.

Account SAS is signed with the storage account key and grants access across multiple services and resource types. This token covers blob, queue, table, and file services, making it useful for automation tasks that span your entire storage account. It supports permissions at the service, container, and object levels with operations such as read, write, delete, and list. Because it provides wide-ranging control, you should limit its use to scenarios that truly require cross-service access.

• Services: blob, queue, table, file
• Resource Types: service (s), container (c), object (o)
• Permissions: read, write, delete, list, add, create, update

Service SAS scopes access to a specific resource, like a blob container or queue, reducing exposure of the entire account. It is signed with the account key but balances security with functionality. You grant only the needed operations on that resource, such as read or write, without giving broader account rights.

• Scope: specific container, blob, queue, or table
• Permissions: read (r), write (w), delete (d), list (l)

User-delegation SAS is signed with Microsoft Entra ID credentials instead of account keys, offering stronger identity controls. It applies only to the Blob service and binds the token to a specific Azure AD principal. You can revoke it instantly by removing the user’s role assignment, which is not possible with account-key-based SAS. This makes it ideal for scenarios with strict security or compliance requirements. It aligns with the concept of ephemeral credentials tied to user identities.

When creating any SAS token, follow these best practices to minimize risk. Always generate tokens with the shortest expiry time and the fewest permissions necessary. Use stored access policies to enable easy revocation and give yourself auditing capabilities. Restrict tokens to known IP address ranges and enforce HTTPS to secure data in transit. By combining these measures, you maintain tight control over your storage resources.

Conclusion

Azure Shared Access Signatures let you grant time-bound, limited access to storage resources without exposing account keys. By choosing among Account SAS, Service SAS, and User-delegation SAS, you can match the scope and permissions to your application’s needs while keeping security strong. Adhering to best practices—such as minimal permissions, stored access policies, IP restrictions, and HTTPS enforcement—helps you implement SAS tokens safely. Mastering these options ensures that your Azure storage solutions follow the least privilege principle and remain secure and manageable.