Describe encryption keys in Azure
Proper protection and management of encryption keys is essential for data security, especially in the public sector, where data may be especially sensitive and vulnerable. Government customers can use Azure Key Vault, which is a cloud service for securely storing and managing secrets, including encryption keys. Customers who require extra security for their sensitive customer data stored in Azure services can encrypt it using their own encryption keys they control in Azure Key Vault.
Use Azure Key Vault for encryption key management
The resource provider in the Key Vault service supports two resource types: vault and managed HSM.
- Vault supports software-protected and hardware security module (HSM)-protected secrets, keys, and certificates. Vaults provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. They can be either software-protected (standard tier) or HSM-protected (premium tier). To see a comparison between the standard and premium tiers, see the Azure Key Vault pricing page. Azure safeguards software-protected secrets, keys, and certificates, using industry-standard algorithms and key lengths. Customers who require more assurances can choose to safeguard their secrets, keys, and certificates in vaults protected by multi-tenant HSMs. The corresponding HSMs are validated according to the FIPS 140-2 standard and have an overall Security Level 2 rating.
- Managed HSM supports only HSM-protected cryptographic keys. It provides a single-tenant, fully managed, highly available, zone-resilient (where available) HSM as a service to store and manage your cryptographic keys. It's most suitable for applications and usage scenarios that handle high value keys. It also helps customers meet the most stringent security, compliance, and regulatory requirements. Managed HSM uses FIPS 140-2 Level 3 validated HSMs to protect your cryptographic keys. Each managed HSM pool is an isolated single-tenant instance with its own security domain. The customer controls this security domain, which is isolated cryptographically from instances belonging to other customers.
Azure Key Vault provides an abstraction over the underlying HSMs. It provides a REST API to enable service use from cloud applications and authentication through Microsoft Entra ID (Microsoft Entra ID). Microsoft Entra ID allows an organization to centralize and customize authentication, disaster recovery, high availability, and elasticity. Azure Key Vault supports cryptographic keys of various types, sizes, and curves, including RSA and Elliptic Curve keys. With managed HSMs, support is also available for AES symmetric keys.
Azure Key Vault supports bring your own key (BYOK) scenarios. Customers can import or generate encryption keys in HSMs, ensuring that keys never leave the HSM protection boundary. Keys generated inside the Azure Key Vault HSMs aren’t exportable – there can be no clear-text version of the key outside the HSMs. The underlying HSM enforces this binding. BYOK functionality is available with both key vaults and managed HSMs. Methods for transferring HSM-protected keys to Azure Key Vault vary depending on the underlying HSM, as explained in the online documentation.
Azure Key Vault is designed, deployed, and operated such that Microsoft and its agents don't see or extract customer cryptographic keys.
A diagram in the center of the infographic is surrounded by six briefly described steps. At the top of the infographic, is an icon labeled “App” with an arrow beneath it pointing downwards to an “Azure Key Vault” labeled icon at the 12 o’clock position of a circular diagram. At the bottom of the diagram, in the six o’clock position, is a laptop icon. A path leads from the left side of the laptop icon in a clockwise direction to a key icon at the nine o’clock position. The path then leads to the “Azure Key Vault” labeled icon at the 12 o’clock position, and then back to the laptop icon at the bottom. In the middle of the diagram, is a building icon labeled “On your premises”. The surrounding step descriptions are as follows: 1. You generate key and keep the master. 2. Securely transfer your key to Microsoft’s HSMs. 3. HSM hardware keeps Microsoft from seeing your key. 4. Authorized app uses your key. 5. Microsoft replicates your key for scale/disaster recovery and keeps HSMs up to date. 6. Microsoft provides log of how your key is used.
Azure Key Vault provides a robust solution for encryption key lifecycle management. Upon creation, every key vault or managed HSM is automatically associated with the Microsoft Entra tenant that owns the subscription. To access encryption keys in Azure Key Vault HSMs (both in vault and managed HSMs), Microsoft Entra ID must authenticate all callers. Microsoft Entra ID enforces tenant isolation and implements robust measures to prevent access by unauthorized parties, including Microsoft insiders. As described in Microsoft Entra Data Security Considerations, tenant isolation involves two primary elements:
- Preventing data leakage and access across tenants. Users in Tenant A can't in any way obtain data belonging to Tenant B without explicit authorization by Tenant B.
- Resource access isolation across tenants. Operations performed by Tenant A can't in any way impact access to resources for Tenant B.
Access to Microsoft Entra ID by Microsoft personnel, contractors, and vendors is highly restricted. Whenever possible, human intervention is replaced with an automated, tool-based process, including routine functions such as deployment, debugging, diagnostic collection, and restarting services. Controls are in place to restrict insider access to production systems and customer data, including the Just-in-Time (JIT) privileged access management system.
Next, take a look at how data is protected throughout its lifecycle, starting with data in transit.