In the context of Azure Storage management, securing data relies heavily on properly handling authentication credentials. Two fundamental components of this security model are **Access Keys** and **Stored Access Policies**.
**Access Keys**
When you create a storage account, Azure generates two 512…In the context of Azure Storage management, securing data relies heavily on properly handling authentication credentials. Two fundamental components of this security model are **Access Keys** and **Stored Access Policies**.
**Access Keys**
When you create a storage account, Azure generates two 512-bit access keys (Key1 and Key2). These keys act as 'root passwords,' granting full administrative rights and unlimited access to all data within the account. Because they provide absolute control, they must be protected rigorously. Azure provides two keys specifically to facilitate **key rotation** without downtime. Administrators can configure applications to use the secondary key, regenerate the primary key, and then swap back. Best practices dictate that keys should never be hard-coded in applications; instead, they should be managed via Azure Key Vault or ideally replaced by Microsoft Entra ID authentication where possible.
**Stored Access Policies**
While Shared Access Signatures (SAS) allow you to grant granular, time-limited access without sharing the master keys, managing individual SAS tokens is risky. If a standard SAS is compromised, it remains valid until it expires unless you regenerate the master Access Keys, which disrupts all users. **Stored Access Policies** provide a solution to this management challenge. Defined at the container level (blob container, file share, queue, or table), these policies group shared constraints like permissions, start times, and expiration dates.
By associating a SAS token with a Stored Access Policy, you gain the ability to modify or revoke access centrally. If you need to cancel access, you simply update or delete the policy, and all linked SAS tokens become invalid immediately. This mechanism offers a robust way to manage external access lifecycles without compromising the primary storage account keys.
Manage Storage Access Keys and Stored Access Policies for AZ-104
Understanding Storage Access Management
In the Azure Administrator (AZ-104) curriculum, managing storage security is critical. At the core of storage account authentication are Access Keys and Stored Access Policies. Understanding how these function, how to secure them, and how handle their lifecycle is essential for both real-world administration and the exam.
1. Storage Account Access Keys
What are they? When you create a Storage Account, Azure generates two 512-bit storage account access keys (Key1 and Key2). These keys function as 'root' passwords for your storage account.
Why are they important? Possessing an access key grants unrestricted access to the storage account. Anyone with the key can perform any operation on any data within that account. Because they are so powerful, they must be guarded strictly. They are primarily used for server-side applications that require full administrative access or to generate Shared Access Signatures (SAS).
How they work (Key Rotation): Azure provides two keys to allow for key rotation with zero application downtime. The standard workflow for rotation is: 1. Update your applications/connection strings to use Key2. 2. Regenerate Key1 in the Azure Portal or via CLI/PowerShell. 3. Update your applications/connection strings to use the new Key1. 4. Regenerate Key2.
Note: It is highly recommended to use Azure Key Vault to manage and rotate these keys automatically.
2. Stored Access Policies
What are they? A Stored Access Policy provides an additional layer of control over Shared Access Signatures (SAS). While a standard SAS token has its permissions and expiry defined within the token string itself, a Stored Access Policy is defined on the server side (on the container, file share, queue, or table).
Why are they important? (The Revocation Problem) Standard SAS tokens cannot be revoked individually; you would have to regenerate the master Access Keys to invalidate them, which affects all services using those keys. Stored Access Policies solve this. By associating a SAS token with a policy, you can revoke the SAS simply by deleting or modifying the policy, without touching the master keys.
How they work: You create a policy on a specific storage resource (e.g., a Blob Container). You define the start time, expiry time, and permissions (Read, Write, List) in the policy. When generating a SAS, you link it to this policy. If you need to cut off access, you simply change the expiry date on the policy or delete the policy entirely.
Exam Tips: Answering Questions on Manage access keys and stored access policies
When facing AZ-104 scenarios, look for specific keywords to determine the correct answer:
Scenario 1: Administrative Access If the question asks for full administrative access or the ability to regenerate keys programmatically, the answer usually involves Access Keys. However, if the question mentions 'least privilege,' Access Keys are rarely the right answer unless no other option exists.
Scenario 2: Revoking Access If a question asks how to ensure you can revoke access for a specific vendor or app without affecting other applications or regenerating the primary keys, the answer is Stored Access Policies combined with a Service SAS.
Scenario 3: Secure Key Management If the question asks how to securely manage keys and rotate them automatically, look for Azure Key Vault integration.
Scenario 4: Shared Access Signatures (SAS) vs. Keys Use Keys for trusted backend services. Use SAS (linked to policies) for untrusted clients or temporary access. Remember: Only Service SAS supports Stored Access Policies; Account SAS does not.