Customer-managed keys for Azure Storage encryption
You can use your own encryption key to protect the data in your storage account. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Customer-managed keys offer greater flexibility to manage access controls.
You must use one of the following Azure key stores to store your customer-managed keys:
You can either create your own keys and store them in the key vault or managed HSM, or you can use the Azure Key Vault APIs to generate keys. The storage account and the key vault or managed HSM can be different Azure Active Directory (Azure AD) tenants, regions, and subscriptions.
Azure Key Vault and Azure Key Vault Managed HSM support the same APIs and management interfaces for configuration.
About customer-managed keys
The following diagram shows how Azure Storage uses Azure AD and a key vault or managed HSM to make requests using the customer-managed key:
The following list explains the numbered steps in the diagram:
- An Azure Key Vault admin grants permissions to encryption keys to a managed identity. The managed identity may be either a user-assigned managed identity that you create and manage, or a system-assigned managed identity that is associated with the storage account.
- An Azure Storage admin configures encryption with a customer-managed key for the storage account.
- Azure Storage uses the managed identity to which the Azure Key Vault admin granted permissions in step 1 to authenticate access to Azure Key Vault via Azure AD.
- Azure Storage wraps the account encryption key with the customer-managed key in Azure Key Vault.
- For read/write operations, Azure Storage sends requests to Azure Key Vault to unwrap the account encryption key to perform encryption and decryption operations.
The managed identity that is associated with the storage account must have these permissions at a minimum to access a customer-managed key in Azure Key Vault:
For more information about key permissions, see Key types, algorithms, and operations.
Azure Policy provides a built-in policy to require that storage accounts use customer-managed keys for Blob Storage and Azure Files workloads. For more information, see the Storage section in Azure Policy built-in policy definitions.
Customer-managed keys for queues and tables
Data stored in Queue and Table storage isn't automatically protected by a customer-managed key when customer-managed keys are enabled for the storage account. You can optionally configure these services to be included in this protection at the time that you create the storage account.
For more information about how to create a storage account that supports customer-managed keys for queues and tables, see Create an account that supports customer-managed keys for tables and queues.
Data in Blob storage and Azure Files is always protected by customer-managed keys when customer-managed keys are configured for the storage account.
Enable customer-managed keys for a storage account
When you configure a customer-managed key, Azure Storage wraps the root data encryption key for the account with the customer-managed key in the associated key vault or managed HSM. Enabling customer-managed keys doesn't impact performance, and takes effect immediately.
You can configure customer-managed keys with the key vault and storage account in the same tenant or in different Azure AD tenants. To learn how to configure Azure Storage encryption with customer-managed keys when the key vault and storage account are in the same tenants, see one of the following articles:
- Configure encryption with customer-managed keys stored in Azure Key Vault.
- Configure encryption with customer-managed keys stored in Azure Key Vault Managed HSM.
To learn how to configure Azure Storage encryption with customer-managed keys when the key vault and storage account are in different Azure AD tenants, see one of the following articles:
- Configure cross-tenant customer-managed keys for a new storage account
- Configure cross-tenant customer-managed keys for an existing storage account
When you enable or disable customer-managed keys, or when you modify the key or the key version, the protection of the root encryption key changes, but the data in your Azure Storage account doesn't need to be re-encrypted.
You can enable customer-managed keys on both new and existing storage accounts. When you enable customer-managed keys, you must specify a managed identity to be used to authorize access to the key vault that contains the key. The managed identity may be either a user-assigned or system-assigned managed identity:
- When you configure customer-managed keys at the time that you create a storage account, you must use a user-assigned managed identity.
- When you configure customer-managed keys on an existing storage account, you can use either a user-assigned managed identity or a system-assigned managed identity.
To learn more about system-assigned versus user-assigned managed identities, see Managed identities for Azure resources.
You can switch between customer-managed keys and Microsoft-managed keys at any time. For more information about Microsoft-managed keys, see About encryption key management.
Customer-managed keys rely on managed identities for Azure resources, a feature of Azure AD. Managed identities do not currently support cross-tenant scenarios. When you configure customer-managed keys in the Azure portal, a managed identity is automatically assigned to your storage account under the covers. If you subsequently move the subscription, resource group, or storage account from one Azure AD tenant to another, the managed identity associated with the storage account is not transferred to the new tenant, so customer-managed keys may no longer work. For more information, see Transferring a subscription between Azure AD directories in FAQs and known issues with managed identities for Azure resources.
The key vault that stores the key must have both soft delete and purge protection enabled. Azure storage encryption supports RSA and RSA-HSM keys of sizes 2048, 3072 and 4096. For more information about keys, see About keys.
Using a key vault or managed HSM has associated costs. For more information, see Key Vault pricing.
Update the key version
When you configure encryption with customer-managed keys, you have two options for updating the key version:
Automatically update the key version: To automatically update a customer-managed key when a new version is available, omit the key version when you enable encryption with customer-managed keys for the storage account. If the key version is omitted, then Azure Storage checks the key vault or managed HSM daily for a new version of a customer-managed key. If a new key version is available, then Azure Storage automatically uses the latest version of the key.
Azure Storage checks the key vault for a new key version only once daily. When you rotate a key, be sure to wait 24 hours before disabling the older version.
Manually update the key version: To use a specific version of a key for Azure Storage encryption, specify that key version when you enable encryption with customer-managed keys for the storage account. If you specify the key version, then Azure Storage uses that version for encryption until you manually update the key version.
When the key version is explicitly specified, then you must manually update the storage account to use the new key version URI when a new version is created. To learn how to update the storage account to use a new version of the key, see Configure encryption with customer-managed keys stored in Azure Key Vault or Configure encryption with customer-managed keys stored in Azure Key Vault Managed HSM.
When you update the key version, the protection of the root encryption key changes, but the data in your Azure Storage account isn't re-encrypted. There's no further action required from the user.
To rotate a key, create a new version of the key in the key vault or managed HSM, according to your compliance policies. You can rotate your key manually or create a function to rotate it on a schedule.
Revoke access to customer-managed keys
You can revoke the storage account's access to the customer-managed key at any time. After access to customer-managed keys is revoked, or after the key has been disabled or deleted, clients can't call operations that read from or write to a blob or its metadata. Attempts to call any of the following operations will fail with error code 403 (Forbidden) for all users:
- List Blobs, when called with the
include=metadataparameter on the request URI
- Get Blob
- Get Blob Properties
- Get Blob Metadata
- Set Blob Metadata
- Snapshot Blob, when called with the
- Copy Blob
- Copy Blob From URL
- Set Blob Tier
- Put Block
- Put Block From URL
- Append Block
- Append Block From URL
- Put Blob
- Put Page
- Put Page From URL
- Incremental Copy Blob
To call these operations again, restore access to the customer-managed key.
All data operations that aren't listed in this section may proceed after customer-managed keys are revoked or a key is disabled or deleted.
Customer-managed keys for Azure managed disks
Customer-managed keys are also available for managing encryption of Azure managed disks. Customer-managed keys behave differently for managed disks than for Azure Storage resources. For more information, see Server-side encryption of Azure managed disks for Windows or Server side encryption of Azure managed disks for Linux.
Submit and view feedback for