Manage Access Keys
Storage account access keys are 512-bit keys that Azure generates for each storage account, and they provide full control over all data in that account through a method called Shared Key authorization. These keys do not expire and are not tied to a user identity, which makes them a significant security risk if they are exposed. Microsoft recommends disabling Shared Key authorization whenever possible and instead using Microsoft Entra ID for authentication, because identity-based security provides better control over who can access your data.
Azure Role-Based Access Control (RBAC) lets you assign specific roles to users that determine what they can do with storage account keys. The Owner, Contributor, and Storage Account Contributor roles all include the Microsoft.Storage/storageAccounts/listkeys/action, which allows a user to view and regenerate keys. For users who only need to read data from storage, assign the Reader role instead, because it specifically excludes access to account keys and follows the principle of least privilege.
Shared Access Signatures (SAS) create temporary, limited access to storage resources through a signed URL that includes an expiration time. There are three types: Service SAS grants access to a specific resource using the account key, Account SAS grants access across multiple storage services, and User Delegation SAS uses Microsoft Entra credentials instead of account keys. The user delegation SAS is the most secure option for blob storage because it relies on identity-based security and is not affected when you rotate account keys.
Organizations should store and automatically rotate keys using Azure Key Vault, which acts as a secure central repository for secrets and keys. When you rotate keys manually, always use two keys so your applications stay online while you update connection strings. For the strongest security, disable Shared Key access entirely to force Microsoft Entra ID authentication with Managed Identities, which lets you apply Conditional Access policies such as multi-factor authentication. Enable Microsoft Defender for Storage to monitor for unusual activity and detect potential key leaks.
Evaluate Key Security and Compliance Requirements
Access keys grant full control over storage account resources, so protecting them is essential for both security and regulatory compliance. Azure generates two access keys per storage account, and you can regenerate one while the other remains active, which enables smooth key rotation without service interruption. You should never hard-code access keys in your applications or store them in plain text files, because anyone who finds those keys gains complete control over your data.
Azure Key Vault provides centralized management for cryptographic keys and secrets, including storage account access keys. Key Vault can integrate with Hardware Security Modules (HSMs) for storing high-value keys, and it provides detailed logging through Azure role-based access control to track who accessed which keys. Grant access at the minimum required scope and regularly audit key usage to limit exposure and maintain compliance. Key Vault also supports soft delete and purge protection, which lets you recover keys if they are accidentally or maliciously deleted.
Key rotation is a fundamental compliance requirement that reduces the window of opportunity for attackers if a key is compromised. Azure supports both manual rotation through the portal or command-line tools and automated rotation through Key Vault, which can automatically generate new keys on a schedule. When rotating keys, you must update all dependent applications and services to use the new key, otherwise they will lose access to storage. Setting a key expiration policy and monitoring compliance using Azure Policy ensures keys do not remain valid indefinitely.
Access control strategies should follow the principle of least privilege, which means granting only the minimum permissions needed to perform a task. Use Microsoft Entra ID with managed identities for authentication wherever possible, because this approach eliminates long-lived keys and enables granular RBAC. When you must use keys, restrict and monitor access closely, and prefer user delegation SAS tokens over shared keys for limited, time-bound access. Disabling Shared Key authorization forces all access through identity-based security, which provides better audit trails and control.
Compliance alignment requires that all key management activities—including generation, storage, rotation, and revocation—are logged and auditable. Enable resource logs and use Azure Monitor and Azure Defender for Storage to detect suspicious activities and generate alerts. For regulatory compliance, use customer-managed keys stored in Key Vault or Managed HSM, which lets you control key lifecycle operations and demonstrate compliance with standards such as FIPS 140-2/3.
Rotate and Regenerate Access Keys
Each Azure storage account has two access keys—Key1 and Key2—so you can rotate one key while the other continues serving your applications. Microsoft recommends setting a key expiration policy to remind you to rotate keys at regular intervals, because regular rotation reduces the risk that compromised credentials remain valid. The rotation process involves updating your application to use one key, regenerating the other key, updating your application again, and then regenerating the first key.
Azure provides three methods to regenerate access keys without causing downtime. Through the Azure portal, use the Access keys blade under Security + networking in your storage account. Through PowerShell, run the New-AzStorageAccountKey cmdlet with the -KeyName parameter set to either key1 or key2. Through Azure CLI, use az storage accounts keys renew with the --key parameter set to primary or secondary. All three methods create a new key while leaving the existing key active until you update your applications.
To rotate keys safely, follow this specific sequence: first, update all connection strings in your applications to reference the secondary access key instead of the primary. Second, regenerate the primary key and wait until your application successfully uses the new key. Third, update connection strings again to reference the new primary key. Finally, regenerate the secondary key so that both keys have been rotated. This approach ensures your applications maintain continuous access to storage throughout the rotation process.
StudyCerts
StudyCerts