Microsoft Cloud for Sovereignty - Part 3 - Azure Key Vault Managed HSM

Sovereign cloud series - Microsoft Cloud for Sovereignty - Part 3
This blog will give you an overview about Azure Key Vault Managed HSM, one of the several key management solutions in Azure. This information can be found at Microsoft Learn.

What is Azure Key Vault Managed HSM
Azure Key Vault Managed HSM (Hardware Security Module) is a fully managed, highly available, single-tenant, standards-compliant cloud service that enables you to safeguard cryptographic keys for your cloud applications, using FIPS 140-2 Level 3 validated HSMs.

Why use Azure Key Vault Managed HSM

• Fully managed, highly available, single-tenant HSM as a service
  
  • Fully managed: HSM provisioning, configuration, patching, and maintenance is handled by the service;
    
  • Highly available: Each HSM cluster consists of multiple HSM partitions. If the hardware fails, member partitions for your HSM cluster will be automatically migrated to healthy nodes.
    
  • Single-tenant: Each Managed HSM instance is dedicated to a single customer and consists of a cluster of multiple HSM partitions. Each HSM cluster uses a separate customer-specific security domain that cryptographically isolates each customer's HSM cluster.
    
• Access control, enhanced data protection & compliance
  
  • Centralized key management: Manage critical, high-value keys across your organization in one place. With granular per key permissions, control access to each key on the 'least privileged access' principle.
    
  • Isolated access control: Managed HSM "local RBAC" access control model allows designated HSM cluster administrators to have complete control over the HSMs that even management group, subscription, or resource group administrators cannot override.
    
  • Private endpoints: Use private endpoints to securely and privately connect to Managed HSM from your application running in a virtual network.
    
  • FIPS 140-2 Level 3 validated HSMs: Protect your data and meet compliance requirements with FIPS (Federal Information Protection Standard) 140-2 Level 3 validated HSMs. Managed HSMs use Marvell LiquidSecurity HSM adapters.
    
  • Monitor and audit: fully integrated with Azure monitor. Get complete logs of all activity via Azure Monitor. Use Azure Log Analytics for analytics and alerts.
    
  • Data residency: Managed HSM doesn't store/process customer data outside the region the customer deploys the HSM instance in.
• Integrated with Azure and Microsoft PaaS/SaaS services
  
  • Generate (or import using BYOK) keys and use them to encrypt your data at rest in Azure services such as Azure Storage, Azure SQL, Azure Information Protection, and Customer Key for Microsoft 365. For a more complete list of Azure services which work with Managed HSM, see Data Encryption Models.
    
• Uses same API and management interfaces as Key Vault
  
  • Easily migrate your existing applications that use a vault (a multi-tenant) to use Managed HSMs.
    
  • Use same application development and deployment patterns for all your applications irrespective of key management solution in use: multi-tenant vaults or single-tenant Managed HSMs.
    
• Import keys from your on-premises HSMs
  
  • Generate HSM-protected keys in your on-premises HSM and import them securely into Managed HSM.
    

Deepdive into Azure Key Vault Managed HSM
If you would like to learn more about the HSM in-depth, click the following links:

• admistrative security controls that are in place in Azure Key Vault Managed HSM;
  
• Key sovereignty, availability, performance, and scalability in Managed HSM;
  
• Security domain in Managed HSM;
  
• Local RBAC built-in roles for Managed HSM;
  
• Managed HSM soft-delete.
  

Deployment
Deployment can be done via AzureCLI, PowerShell, ARM or link. For more information, click here.

Risks of using Azure Key Vault Managed HSM
It's crucial to understand that the primary, or master, key is crucial while utilising an HSM. All of the data that is encrypted with this key is lost, unusable and inaccessable. Even the Cloud Provider (in this case, Microsoft) cannot help you in restoring your data.

Limits of the Azure Key Vault Managed HSM
Some limitations out of the field:

• HSM resource currently cannot create certificates. For this you still need to use Azure KeyVault, which can result in changing Sovereign cloud policy set initiative;
  
• One team is responsible for the lifecycle of HSM-keys and exchanging them to internal teams. Self-service offering, meaning that teams can create keys themselves, is limited, meaning that they have full access over all keys. The best practice advice, from a security perspective is to leave this responsibility of Key Management to one Team only.
• Azure Confidential VMs are not presently compatible with Automated key rotation. You have to manually turn off the Azure Confidential VM and then replace the HSM key in order for it to function.

Best practices for securing Azure Key Vault Managed HSM
Below, you will find the best practices for securing your Azure Key Vault Managed HSM key management system. For a full list of security recommendations, see the Azure Managed HSM security baseline.

• Control access to your managed HSM
  • Create a Microsoft Entra security group for the HSM Administrators (instead of assigning the Administrator role to individuals) to prevent "administration lockout" if an individual account is deleted;
  • Lock down access to your management groups, subscriptions, resource groups, and managed HSMs. Use Azure role-based access control (Azure RBAC) to control access to your management groups, subscriptions, and resource groups.
  • Create per-key role assignments by using Managed HSM local RBAC.
  • To maintain separation of duties, avoid assigning multiple roles to the same principals.
  • Use the least-privilege access principle to assign roles.
  • Create a custom role definition by using a precise set of permissions.
• Create backups
  • Be sure that you create regular backups of your managed HSM. You can create backups at the HSM level and for specific keys.
• Turn on logging via Azure Policy
  • Turn on logging for your HSM. You also can set up alerts.
• Turn on recovery options
  • Enable Soft-delete. This feature allows recovery of deleted HSMs and keys, if they where accidently removed. This is true as long as the retention time (between 7 and 90 days) is not reached.
  • Enable Purge protection. When purge protection is on, an HSM or key in the deleted state can't be purged until the retention period ends. Soft-deleted HSMs and keys can still be recovered, which ensures the retention policy will be in effect.