First you have to understand the different URLs that you can use for different types of resources
|Resource type||Key protection methods||Data-plane endpoint base URL|
HSM-protected (with Premium SKU)
When you provision Key Vault Standard or Premium, you will use the same *.vault.azure.net address but when you deploy an Azure Managed HSM the URL will change to *.managedhsm.azure.net.
I won’t be writing from Azure Dedicated HSM as it’s not suitable for most needs inside Azure and M365.
What is FIPS?
There is three different FIPS-levels and they are based on The Federal Information Security Management Act (FISMA), which was created by the National Institute of Standards and Technology (NIST) and approved by the Secretary of Commerce, established FIPS as standards and directives for federal computer systems. When there are no existing industry standards or solutions that satisfy a particular regulatory demand, these standards and guidelines are created. Despite the fact that FIPS were created for use by the federal government, many businesses willingly utilize them.
|Key type and destination||Compliance|
|Software-protected keys in vaults (Premium & Standard SKUs)||FIPS 140-2 Level 1|
|HSM-protected keys in vaults (Premium SKU)||FIPS 140-2 Level 2|
|HSM-protected keys in Managed HSM||FIPS 140-2 Level 3|
Let’s me collaborate a bit on these. Software protected are the ones you generate inside Key vault and the type is not including HSM in their name
And the ones having HSM are HSM-protected keys
So what is the difference between HSM-protected keys and Managed HSM?
HSM-protected keys (also referred to as HSM-keys) are processed in an HSM (Hardware Security Module) and always remain HSM protection boundary. Key Vault Premium uses HSM-keys in shared HSM backend infrastructure.
And Managed HSM uses FIPS 140-2 Level 3 validated HSM modules to protect your keys. Each HSM pool is an isolated single-tenant instance with its own security domain providing complete cryptographic isolation from all other HSMs sharing the same hardware infrastructure.
What is Root of trust?
It’s a source that can always be relied upon. RoT methods often incorporate a hardened hardware module since cryptographic security depends on keys to encrypt and decrypt data and carry out operations like creating digital signatures and verifying signatures. The hardware security module (HSM), which produces and preserves keys and carries out cryptographic operations within its safe environment, serves as a prime example.
What about the Root of trust for Key Vaults?
|Key vault Standard||Key vault Premium||Managed HSM|
|Compliance||FIPS 140-2 level 1||FIPS 140-2 level 2||FIPS 140-2 level 3|
|Methods||Encryption at Rest||Encryption at Rest||Encryption at Rest|
|Key protection||Software||Software or HSM||HSM|
|Key types||RSA: “Software-protected” RSA key EC: “Software-protected” Elliptic Curve key||EC-HSM: Elliptic Curve key RSA-HSM: RSA key||EC-HSM: Elliptic Curve key RSA-HSM: RSA key oct-HSM: Symmetric key|
|Root of trust||Microsoft||Microsoft||Customer|
Different key types
HSM-protected keys (Premium or Managed HSM)
|Key type||Vaults (Premium SKU only)||Managed HSMs|
|EC-HSM: Elliptic Curve key||Supported (P-256, P-384, P-521, P-256K)||Supported (P-256, P-256K, P-384, P-521)|
|RSA-HSM: RSA key||Supported (2048-bit, 3072-bit, 4096-bit)||Supported (2048-bit, 3072-bit, 4096-bit)|
|oct-HSM: Symmetric key||Not supported||Supported (128-bit, 192-bit, 256-bit)|
|Key type||Vaults||Managed HSMs|
|RSA: “Software-protected” RSA key||Supported (2048-bit, 3072-bit, 4096-bit)||Not supported|
|EC: “Software-protected” Elliptic Curve key||Supported (P-256, P-384, P-521, P-256K)||Not supported|
Automated Key rotation
Automated key rotation in Key Vault allows users to configure Key Vault to automatically generate a new key version at a specified frequency. You can use rotation policy to configure rotation for each individual key. Our recommendation is to rotate encryption keys at least every two years to meet cryptographic best practices.
This feature enables end-to-end zero-touch rotation for encryption at rest for Azure services with customer-managed key (CMK) stored in Azure Key Vault. Please refer to specific Azure service documentation to see if the service covers end-to-end rotation.
Key Vault key rotation feature requires key management permissions. You can assign a “Key Vault Administrator” role to manage rotation policy and on-demand rotation.
For more information on how to use RBAC permission model and assign Azure roles, see: Use an Azure RBAC to control access to keys, certificates and secrets
Let’s explore the options
You have two different access policy permission models.
Vault Access policy
You have to add “Get Rotation Policy” right.
Go to Access policies and add “Get Rotation Policy”
Go back to keys and you will see the same options for adding Key Rotation.
Set key rotation policy
You have a Key Vault and will generate a new key and rotation policy to it.
And you will be displayed with the following error.
Go to Access control and add role assignment.
Add Key Vault Administrator
Here you can add Users, Groups, Service principals or even Managed identities.
I will choose users for demonstration purposes. You can check your rights from the same pane.
Inside the policy
Now you can enable key rotation. In my example I chose expiration time to 1 year and rotation time for 355 days as there has to be lower than 358 days.
Accessing Keys with Managed Identities
With Managed Identities it’s easy to access your resources directly from the service or server or with User assigned identities.
What are managed identities?
Microsoft trusted services
But there is also Microsoft trusted services than can access your Key Vault if you will allow them to. Here’s a list of trusted services that are allowed to access a key vault if the Allow trusted services option is enabled.
How to add them to Key Vault?
Create a system-managed identity for Storage Account
You have options to create a System-managed identity for the account. If the storage account cannot access Key vault, it cannot create the Managed identity automatically and you have to use PowerShell or CLI.
When you connect to a Key vault the System-Managed identity will be automatically created.
$storageAccount = Set-AzStorageAccount -ResourceGroupName <resource_group> `
-Name <storage-account> `
az storage account update \
--name <storage-account> \
--resource-group <resource_group> \
Assigning a role
Like previously stated, services have Managed identities and you can access other services with them.
In my example I have a storage account which will access the Key Vault.
And the permissions should be Key Vault Crypto User
|Key Vault Administrator||Perform all data plane operations on a key vault and all objects in it, including certificates, keys, and secrets. Cannot manage key vault resources or manage role assignments. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||00482a5a-887f-4fb3-b363-3b7fe8e74483|
|Key Vault Certificates Officer||Perform any action on the certificates of a key vault, except manage permissions. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||a4417e6f-fecd-4de8-b567-7b0420556985|
|Key Vault Crypto Officer||Perform any action on the keys of a key vault, except manage permissions. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||14b46e9e-c2b7-41b4-b07b-48a6ebf60603|
|Key Vault Crypto Service Encryption User||Read metadata of keys and perform wrap/unwrap operations. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||e147488a-f6f5-4113-8e2d-b22465e65bf6|
|Key Vault Crypto User||Perform cryptographic operations using keys. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||12338af0-0e69-4776-bea7-57ae8d297424|
|Key Vault Reader||Read metadata of key vaults and its certificates, keys, and secrets. Cannot read sensitive values such as secret contents or key material. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||21090545-7ca7-4776-b22c-e363652d74d2|
|Key Vault Secrets Officer||Perform any action on the secrets of a key vault, except manage permissions. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||b86a8fe4-44ce-4948-aee5-eccb2c155cd7|
|Key Vault Secrets User||Read secret contents. Only works for key vaults that use the ‘Azure role-based access control’ permission model.||4633458b-17de-408a-b874-0445c86b69e6|
I previously create a HSM protected Key with a length of 3072 bits
Open your Storage account which you gave access to Key Vault and choose Customer-managed keys.
Choose the Select from key vault and System-assigned. You can also choose User-assigned but then you have to create an User identity.
Under Key vault selection you can choose Key vault or Managed HSM if you have one but I will choose they key I just created.
You also have an option to use multi-tenant application under Advanced settings
To configure the storage account with an Azure Key Vault from a different Azure Active Directory tenant, use a multi-tenant application registration.
And finally you can see the generated Key inside the storage account.
Key vault is a super powerful service to store all keys, certificates and secrets. And you can securely access it using Private endpoints and allow Microsoft trusted services to access it when needed.
Auto-rotation is also an excellent feature that came to Key vault. It will allow a zero-touch implementation for your encryption needs.