You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
A stored access policy is a server-side template used to centrally manage groups of service-level shared access signatures (SAS). These policies allow administrators to define and enforce specific permissions and timeframes for accessing Azure Storage resources like blob containers, file shares, queues, and tables.
When configuring a policy, you specify granular permissions for the storage service. These include Read, Write, Delete, and List for data management, as well as Add, Create, Update, and Process for specific service operations. It is crucial to know that these policies only work with service SAS tokens and cannot be used with account SAS or user delegation SAS. You can define a maximum of five policies for any single resource container.
The lifecycle of a policy begins with its creation. You can create or modify a policy using the Azure portal, PowerShell, or the .NET client library. These operations require authorization using the storage account access keys, as Microsoft Entra ID credentials are not supported. Once active, you can dynamically update a policy's expiry time or permissions without having to issue new SAS tokens to your users.
A key security feature is the ability to perform immediate revocation. If a SAS token is compromised, you can invalidate all tokens linked to a policy by deleting the policy, renaming it, or setting its expiration to a past time. This provides a major security advantage over ad hoc SAS tokens, which cannot be revoked before their built-in expiry without rotating the entire storage account key. For compliance, experts recommend using short expiration times and enforcing HTTPS for all SAS traffic, following the principle of least privilege.
Stored access policies add a server-side layer of control for service-level SAS tokens. They allow you to group tokens and apply or change restrictions, such as start time, expiry time, or permissions, even after the SAS has been issued to users.
Stored access policies can be applied to specific Azure Storage resource containers. The supported resources are Blob containers, File shares, Queues, and Tables.
Creating a stored access policy requires using the Set Container ACL operation. This operation must be authorized using Shared Key credentials (the storage account access keys); Microsoft Entra ID authorization is not supported. Using the .NET client library, you can create a policy with methods like BlobContainerClient.SetAccessPolicy. The process involves defining one or more policies with a unique ID, a start time, an expiry time, and a string of permissions.
A code example shows creating a policy named "mysignedidentifier" that is effective for one day and grants read/write ("rw") permissions. The policy is then applied to the container. The critical points are that stored access policies are only supported for service SAS, not for account or user delegation SAS. They provide a secure and manageable way to control access by specifying permissions and durations centrally, which can then be inherited by individual SAS tokens.
Integrating Stored Access Policies with Shared Access Signatures (SAS) provides centralized control over SAS token permissions and expiration. A service SAS can be associated with a stored policy, causing the SAS to inherit the policy's defined start time, expiry time, and permissions.
The main advantage of this integration is the ability to revoke or modify access after a SAS token is issued. If a SAS token linked to a policy is compromised, you can invalidate it by either deleting the associated stored policy or changing the policy's expiry to a past time. This offers a vital security control not available with ad hoc SAS tokens, which remain valid until their own expiry and cannot be revoked early.
A stored access policy acts as an enforceable template. Any service SAS referencing a policy cannot specify permissions, start time, or expiry that exceed the policy's limits. This ensures consistent security rules are applied. With up to five policies per container, you can support different permission sets for various scenarios. This structure simplifies management, as you can set a policy with a long expiry for flexibility but issue individual SAS tokens with much shorter validity for security.
For best security practices, you should always use stored access policies with service SAS when possible. This allows you to manage tokens centrally and revoke them if needed. A common pattern is to set the policy's expiry far in the future for management ease, while generating short-lived SAS tokens from it. If revocation is required, you simply modify the stored policy, instantly affecting all associated SAS tokens without the disruptive need to rotate the storage account keys.
StudyCerts
StudyCerts