Managing Customer-Managed Keys in Azure Storage

Introduction: The Imperative of Data Sovereignty

In the landscape of modern cloud computing, data is the most valuable asset an organization possesses. While cloud providers offer baseline security measures, such as platform-managed encryption keys, many organizations operate under strict regulatory requirements or internal policies that demand greater control over their data’s lifecycle. This is where Customer-Managed Keys (CMK) come into play. By using CMK, you move the responsibility—and the authority—of encryption key management from the cloud service provider to your own security team.

Understanding how to implement and manage Customer-Managed Keys is not just a technical requirement for passing certification exams; it is a fundamental skill for any cloud engineer or security architect. When you use CMK, you are essentially creating a "bring your own key" (BYOK) scenario. You maintain the ability to rotate, disable, or revoke access to the keys used to encrypt your Azure Storage data at any time. This capability provides a powerful lever for security compliance, allowing you to respond instantly to potential security breaches or fulfill audit requests for data destruction by simply destroying the key.

In this lesson, we will explore the mechanics of Azure Storage encryption, the architecture of integration with Azure Key Vault, the configuration process, and the operational best practices required to ensure your data remains secure and accessible.

Understanding Encryption at Rest in Azure

Before diving into the configuration of CMK, it is essential to understand how Azure handles encryption at rest. By default, all data written to Azure Storage is encrypted using 256-bit AES encryption. This is transparent to the user and is managed entirely by the platform. This default approach is known as Service-Managed Keys (SMK).

When you transition to Customer-Managed Keys, you are essentially instructing the Azure Storage service to use a key that you own and store within an Azure Key Vault instance. The storage service does not actually "see" your key in plaintext; rather, it uses the key to wrap the data encryption keys (DEKs) that are generated by the storage service itself. This process is known as Envelope Encryption.

The Role of Envelope Encryption

Envelope encryption is the industry-standard method for managing large datasets. Instead of encrypting the actual data directly with your master key, the storage service generates a random data encryption key (DEK). The data is encrypted with this DEK. Then, your master key (the key you manage in Key Vault) is used to encrypt (wrap) the DEK.

1. Data Encryption Key (DEK): Used to encrypt the actual blobs, files, or tables.
2. Key Encryption Key (KEK): This is your Customer-Managed Key stored in Azure Key Vault. It wraps the DEK.

When you need to read the data, the Azure Storage service sends a request to Azure Key Vault to unwrap the DEK. If the service has the necessary permissions, Key Vault performs the unwrap operation and returns the DEK to the storage service, which then uses it to decrypt the data.

Callout: Platform-Managed vs. Customer-Managed Keys

Platform-Managed Keys (PMK) are the default. They are easy to use because Microsoft handles rotation and availability. However, they lack the granularity that security-conscious organizations require. Customer-Managed Keys (CMK) provide the ability to track key usage, control the rotation schedule, and instantly revoke access to data by disabling the key. The trade-off is the increased operational burden: if you lose access to your key or delete it accidentally, your data becomes permanently unrecoverable.

Architecture and Prerequisites

Implementing CMK requires a specific architectural setup. You cannot simply flip a switch; you must ensure that your Azure Storage account and your Key Vault instance are configured to communicate securely and reliably.

Essential Components

• Azure Storage Account: Must be a General Purpose v2 account, a BlockBlobStorage account, or a FileStorage account.
• Azure Key Vault: Must be a Premium or Standard tier vault. Crucially, the vault must have "Soft Delete" and "Purge Protection" enabled. These are non-negotiable for production environments.
• Managed Identity: The storage account must have an associated managed identity (System-Assigned or User-Assigned) that is granted permission to access the Key Vault.

Setting Up the Environment

Before you can enable CMK, you must ensure that your Key Vault is prepared to handle the storage account's requests.

1. Enable Soft Delete and Purge Protection: These features prevent accidental deletion of your keys. Without them, an accidental deletion of the key would result in the permanent loss of all data encrypted by that key.
2. Grant Permissions: You must configure an Access Policy or Role-Based Access Control (RBAC) on the Key Vault to allow the storage account’s managed identity to perform wrapKey, unwrapKey, and getKey operations.

Warning: The Risk of Data Loss

When using CMK, you are the custodian of the key. If you delete the key in Key Vault, Azure Storage will lose the ability to decrypt your data. Even if you have backups of your data, they will be useless without the original key. Always ensure that "Purge Protection" is enabled in Key Vault to prevent malicious or accidental permanent deletion of keys.

Step-by-Step Configuration

Configuring CMK can be performed through the Azure Portal, Azure PowerShell, or the Azure CLI. We will focus on the process using the Azure CLI as it provides the most clarity regarding the individual steps involved.

Step 1: Create or Update the Storage Account with a Managed Identity

First, enable the managed identity on your existing storage account.

# Enable System-Assigned Managed Identity on the storage account
az storage account update \
    --name <your-storage-account-name> \
    --resource-group <your-resource-group> \
    --assign-identity

Step 2: Configure Key Vault Permissions

After enabling the managed identity, you must retrieve the Principal ID of that identity and grant it access to the Key Vault.

# Retrieve the Principal ID
PRINCIPAL_ID=$(az storage account show \
    --name <your-storage-account-name> \
    --resource-group <your-resource-group> \
    --query identity.principalId \
    --output tsv)

# Grant access to Key Vault
az keyvault set-policy \
    --name <your-key-vault-name> \
    --object-id $PRINCIPAL_ID \
    --key-permissions get wrapKey unwrapKey

Step 3: Enable CMK on the Storage Account

Now, you point the storage account to the specific key version in your Key Vault.

# Get the Key Vault Key ID (URI)
KEY_URI=$(az keyvault key show \
    --vault-name <your-key-vault-name> \
    --name <your-key-name> \
    --query key.kid \
    --output tsv)

# Assign the key to the storage account
az storage account update \
    --name <your-storage-account-name> \
    --resource-group <your-resource-group> \
    --encryption-key-name <your-key-name> \
    --encryption-key-vault <your-key-vault-uri> \
    --encryption-key-source Microsoft.KeyVault

Operational Best Practices

Managing Customer-Managed Keys is not a "set it and forget it" task. It requires a rigorous operational framework to ensure that keys remain available and that access is audited.

Key Rotation Strategies

You should rotate your keys periodically. Rotation limits the amount of data encrypted with a single key version, which reduces the impact if a specific key is ever compromised. You can rotate keys manually or automate the process.

• Manual Rotation: Involves creating a new key version in Key Vault and updating the storage account to point to the new version.
• Automatic Rotation: Azure Key Vault supports automated rotation for certain key types. By configuring an automated rotation policy, you reduce the risk of human error during the rotation process.

Monitoring and Auditing

You must monitor the interaction between Azure Storage and Key Vault. If the storage account loses access to the key—due to network issues or accidental permission changes—the data will become inaccessible.

• Diagnostic Logs: Enable diagnostic logs for both your Storage Account and your Key Vault. In Log Analytics, you can create alerts for KeyVaultGet or KeyVaultUnwrap failures.
• Alerting: Set up alerts for any unauthorized attempts to modify Key Vault policies or the storage account encryption settings.

Network Isolation

If you are using CMK, you should also consider using Private Links to connect your storage account to your Key Vault. This ensures that the traffic between the storage service and the Key Vault remains on the Microsoft backbone network and does not traverse the public internet, significantly reducing the attack surface.

Callout: The "Key Version" Distinction

When configuring CMK, you have two choices: use a specific key version (e.g., https://vault.vault.azure.net/keys/mykey/12345) or use the key base URI (e.g., https://vault.vault.azure.net/keys/mykey/).

If you use the specific version, you must manually update the storage account every time you rotate the key. If you use the base URI, Azure Storage will automatically use the latest version of the key. Most enterprises prefer using the base URI to automate rotation, provided they have strict controls over key versions in the vault.

Common Pitfalls and Troubleshooting

Even with careful planning, issues can arise. Understanding these common failure points will save you hours of downtime.

1. The "Inaccessible Key" Scenario

The most common issue is the storage account losing access to the Key Vault. This can happen if:

• The Key Vault access policy is modified.
• The managed identity is deleted.
• The key itself is deleted or disabled.

If this happens, you will receive "KeyVaultAuthenticationError" or "KeyVaultKeyNotFound" errors when attempting to access your data. To fix this, verify that the managed identity still exists and that it still has the required permissions on the Key Vault.

2. Network Connectivity Issues

If you have configured firewall rules on your Key Vault (e.g., "Allow access from specific virtual networks"), you must ensure that the Azure Storage service has a path to communicate with the Key Vault. If you are using Private Endpoints, verify that the DNS resolution for the Key Vault is working correctly from within the storage account's network context.

3. Misconfigured Managed Identities

A common mistake is using the wrong type of managed identity. While both System-Assigned and User-Assigned identities work, they have different lifecycles. If you delete a storage account, a System-Assigned identity is deleted with it. If you use a User-Assigned identity, the identity persists even if the storage account is deleted. Ensure your team understands the implications of the identity type chosen.

Quick Reference: Comparison of Security Configurations

Advanced Management: Infrastructure as Code (IaC)

In a professional environment, you should never configure encryption settings manually through the portal. Using Infrastructure as Code (IaC) ensures consistency and repeatability. Below is an example of how you might define this configuration using Bicep, the native Azure IaC language.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    encryption: {
      keySource: 'Microsoft.KeyVault'
      keyVaultProperties: {
        keyName: 'mykey'
        keyVaultUri: 'https://myvault.vault.azure.net/'
      }
    }
  }
}

By defining the configuration in Bicep, you ensure that the storage account is created with the correct identity and encryption settings from the start. This prevents the "gap" period where data might be stored with platform-managed keys before you get around to enabling CMK.

Best Practices for Key Lifecycle Management

The security of your storage depends entirely on the security of your keys. Therefore, your key lifecycle management policy should be as robust as your data management policy.

1. Least Privilege: Only the storage account's managed identity should have access to the Key Vault. Never grant human users wrapKey or unwrapKey permissions unless absolutely necessary for troubleshooting.
2. Separation of Duties: The security team that manages the Key Vault should be separate from the cloud engineers who manage the storage accounts. This prevents a single individual from having the power to both encrypt data and gain access to it.
3. Regular Audits: Conduct quarterly audits of the Key Vault access logs to ensure that only expected principals are accessing the keys.
4. Disaster Recovery: If your organization requires high availability, consider using Key Vault's geo-replication features. If a region goes down, your storage account will need access to a replica of the key in the target region to decrypt the data.
5. Key Versioning: Maintain a history of key versions. This is crucial if you ever need to perform a "point-in-time" recovery of data, as you may need to use an older key version to decrypt a specific backup.

Addressing Common Questions (FAQ)

Q: Can I switch back to Service-Managed Keys after using CMK?

Yes, you can switch back to Service-Managed Keys at any time by updating the encryption settings on the storage account. The data will be re-encrypted (or effectively re-wrapped) using the platform-managed key.

Q: Does CMK affect performance?

There is a negligible latency overhead when the storage service calls the Key Vault to unwrap the DEK. For most applications, this is not noticeable. However, for extremely high-throughput, low-latency workloads, you should perform testing to ensure that the overhead is within acceptable limits.

Q: What happens if the Key Vault is deleted?

If you have Purge Protection enabled, you cannot delete the key for a certain period. If you delete the Key Vault itself, you will lose access to the keys. This is why it is critical to have robust backup and recovery procedures for your Key Vault instances.

Q: Can I use a key from a different subscription?

Yes, you can use a key from a Key Vault in a different subscription, provided that the storage account's managed identity has been granted the necessary permissions on that vault. This is a common pattern in organizations that centralize their security keys in a dedicated "Security" subscription.

Conclusion and Key Takeaways

Implementing and managing Customer-Managed Keys is a significant step forward in securing your Azure environment. It provides the control, visibility, and compliance capabilities that modern enterprises demand. While it introduces additional complexity and requires careful operational discipline, the ability to maintain absolute authority over your data’s encryption lifecycle is a powerful security feature.

To successfully manage CMK in Azure Storage, remember these core principles:

1. Data Sovereignty: CMK puts you in control. You define the rotation, the access, and the lifecycle of the keys that protect your most sensitive information.
2. Architecture Matters: Always use System-Assigned or User-Assigned Managed Identities to bridge the gap between your storage account and your Key Vault. Never rely on shared secrets or connection strings.
3. Safety First: Enable "Soft Delete" and "Purge Protection" on your Key Vaults. These features are your primary defense against catastrophic data loss caused by accidental key deletion.
4. Automation: Use Infrastructure as Code (IaC) to deploy and configure your storage and encryption settings. Manual configuration is prone to error and makes auditing difficult.
5. Proactive Monitoring: Treat your Key Vault as a critical production service. Monitor every request, alert on every failure, and ensure that your network configuration allows for seamless communication between the storage service and the vault.
6. Lifecycle Discipline: Establish a clear policy for key rotation and versioning. Understand the difference between rotating keys for compliance versus rotating keys for incident response.
7. Testing: Never perform changes to encryption settings in production without testing the entire workflow—including data access and key revocation—in a sandbox environment first.

By following these practices, you can effectively leverage Customer-Managed Keys to meet your organization's security and compliance requirements while maintaining the performance and reliability of your Azure Storage infrastructure. The transition from platform-managed security to customer-managed security is a journey of maturity, and with the right approach, it significantly strengthens the security posture of your entire cloud ecosystem.