An organisation’s data can be protected from unauthorised access through encryption. Encryption involves encoding the data so that it can only be read by those having a key to decode it. The Azure platform offers many options to encrypt data while at rest in the form of virtual machines (VMs), storage accounts and databases. It also provides encryption options for data in transit using standard protocols such as TLS and HTTPS. This post provides details in particular for VM encryption.
Within Azure, encryption keys may be stored in a key vault which is a secure repository for protecting encryption keys, certificates, and application secrets. A key vault is not designed to operate as a password manager and is not intended to store user account passwords.
A key vault is a business-critical resource and should be protected from unauthorised access, both at the management plane of the key vault itself (e.g., deleting the vault) and at the data plane for access to the secured entities within. Both management and data planes use role-based access control (RBAC) to manage permissions to the key vault and its contents. It is also possible to use an access policy to define rights for accessing contents of a vault although this method is not granular to the individual item level. An access policy for keys allows an authorised user to access all keys in a vault. Using the RBAC permission model standardises the control of access to resources with a familiar interface and can be configured in the Azure portal as shown below or by using PowerShell or ARM templates.
Before RBAC at the data plane was supported, it was recommended to create a separate key vault for each requirement (e.g., production application 1, test application 1, …). Permissions can now be controlled at the item level although it may still be appropriate to create distinct key vaults for specific purposes (e.g., disk encryption, application 1, …).
Key vault administrator accounts should be protected through enforcement of multi-factor authentication (MFA) and conditional access policies. Further, Privileged Identity Management (PIM) should be implemented to limit the time that sensitive administrator accounts have active privileges and optionally require justification or approval before elevating eligible accounts.
Azure key vaults use the soft-delete feature to allow recovery of deleted vaults or objects within a configurable number of days (7-90). It is possible to purge deleted objects for permanent removal and this function is subject to additional privilege. Purge protection can be enabled to ensure that all deleted items are recoverable within a given time frame and cannot be removed until that time has expired.
A delete resource lock applied to a resource or resource group prevents accidental deletion and requires an extra administrative step to remove the lock before deletion.
Applying resource tags to key vaults helps to identify who is responsible for its administration.
All data stored in a key vault is encrypted while at rest.
All network traffic to and from a key vault is encrypted using the HTTPS protocol. However, the vault can be secured further by configuring an Azure Private Link. A private link creates an endpoint on an Azure virtual network (VNet) within an Azure subscription so that traffic is directed over the Microsoft backbone network rather than using public IP addresses.
Microsoft offers a 99.99% service level agreement (SLA) for availability of the key vault service. The contents of a key vault are replicated automatically to a paired geographical region. In the unlikely event of the loss of e.g. UK South, key vault data would be accessible from the UK West region.
Key vaults are important resources and hence must be monitored to ensure proper use. Each key vault can be configured with a diagnostic setting to forward event log and metric data to a Log Analytics workspace.
Alerts can be configured in Azure Monitor from data collected in a workspace to highlight administrative actions on the key vault e.g., deleting the vault. Log data can also benefit from Log Analytics workspaces that are enabled for Azure Security Center with Azure Defender enabled for advanced threat protection. If Azure Sentinel is enabled for the workspace then key vault log data can be combined with logs from other resources to understand potential malicious attacks.
Deploy Key Vault
The table below summarises the actions for consideration when deploying a key vault that can be used for storing encryption keys.
|1||Define a key vault strategy||Example: create a new key vault for each application/function per subscription per region per environment (test/production)|
|2||Create a new key vault||Key vaults can be created using the Azure portal, PowerShell or resource templates|
Configure the soft-delete retention period (e.g., 90 days for maximum protection)
Enable purge protection (default disabled)
Add a resource lock to the key vault to prevent accidental deletion
Add resource tags to identify owners of the key vault
|3||Define permissions||Assign the Key Vault Contributor role to an Azure AD group of administrators responsible for the management of the vault – this does not allow access to the contents of the vault|
Set the permission model to Azure RBAC rather than Vault Access Policy for more granular control of permission to objects
Assign the Key Vault Crypto Officer role to allows users to generate or import keys
Assign the Key Vault Reader role at the vault level and Key Vault Crypto user role at the object level to allow users to retrieve keys
|4||Configure monitoring||Create a diagnostic setting to send audit log events and metric data to a Log Analytics workspace, ideally configured with Azure Security Center (with Azure Defender enabled) and Azure Sentinel for threat detection monitoring of key vault log data|
|5||Integrate with Azure Private Link||Define the connectivity method for the key vault as private endpoint (default of public endpoint – all networks) and specify a VNet and subnet for all connectivity to remain within the Microsoft backbone network|
Virtual Machine Encryption
This section details options for encrypting VMs. Customers may wish to manage their own keys for encrypting VM Managed Disks at the storage layer. They may also choose to add another level of “end-to-end encryption” of the VM itself using Azure Disk Encryption (ADE) or the new Encryption at Host (EAH) feature. The flowchart below summarises the options based on customer requirements, each of which is explained in detail.
Azure VMs are subject to a level of encryption of data at rest by default. Data held in Managed Disks, Snapshots or Images is automatically encrypted by the Azure Storage service using a platform-managed key through Server-Side Encryption (SSE). Legacy unmanaged disks are not encrypted through SSE and should be converted to Managed Disks.
Data stored on Managed Disks is encrypted with an extremely strong cipher (256-bit AES) which meets the stringent FIPS 140-2 compliance standard.
VM data is encrypted by the Azure Storage service using a Data Encryption Key (DEK). The DEK itself is encrypted using a Key Encryption Key (KEK). It is the KEK that can be either a platform-managed key (PMK) or a customer-managed key (CMK).
It is good practice to rotate keys frequently by generating a new version of each. PMKs are automatically rotated by Microsoft but CMKs must be managed by the customer. CMKs are stored securely in a key vault and offer greater flexibility for a customer to manage key rotation.
Generating a new KEK (PMK or CMK) results in the re-encryption of the DEK and hence does not affect the encryption of the VM data itself.
Disk Encryption Sets
A Managed Disk used by a VM is encrypted by SSE with PMKs by default as shown in the example below.
Each disk can be configured to use SSE with CMKs by nominating a key vault and key.
The specification of a key vault and key is defined in a Disk Encryption Set (DES) which is an Azure resource that can be created through the Azure portal, PowerShell commands or ARM templates.
The disk encryption set can be created to support encryption-at-rest with a CMK. It also supports double-encryption using a CMK which is further encrypted with a PMK and offers even greater protection against the compromise of either key.
Once a disk is configured to use single or double encryption with CMKs, it cannot be changed. It is also not possible to move the disk to another resource group or subscription.
SSE encryption with CMK cannot be enabled on disks that are or have ever been encrypted with Azure Disk Encryption (ADE).
Creating a disk encryption set generates a system-assigned managed identity for that resource that must be granted access to the key in the key vault. This can be achieved by assigning the Key Vault Crypto Service Encryption User role to the managed identity of the disk encryption set at the scope of the key vault, resource group or subscription if using the RBAC permission method. If not using RBAC, a new access policy would be required to assign similar permissions.
Automatic Key Rotation
A disk encryption set specifies a specific version of a key. If a new version of a key is generated e.g. as part of a regular key rotation exercise, the disk encryption set must be reconfigured to use the latest version. A new feature allows automatic key rotation such that a disk encryption set will always use the most current version of the nominated key within one hour of it being rotated. It does require the key vault to have purge protection enabled.
Automatic key rotation can be enabled through the following Azure CLI command from a Cloud Shell Bash prompt in the Azure portal.
az disk-encryption-set update --name MyDiskEncryptionSet --resource-group MyResourceGroup --key-url MyKey --source-vault MyVault --auto-rotation true
The following command shows disk encryption set details with selected output below.
az disk-encryption-set show --name MyDiskEncryptionSet --resource-group MyResourceGroup
Deploy SSE with CMK
The table below summarises the actions for consideration when deploying SSE with CMK to encrypt VM Managed Disks.
|1||Create a key vault||The key vault must be in the same region and subscription as the disk encryption set and Managed Disks|
Multiple key vaults can be created to support VMs managed by different teams or to separate test and production environments
|2||Create a key||Choose a key type of RSA|
|3||Create a disk encryption set||Choose single or double encryption|
Select the key vault and key version
A system-managed identity will be created
Multiple disk encryption sets can be created to support different encryption types and key vaults
|4||Assign permissions||Assign the Key Vault Crypto Service Encryption User role to the managed identity of the disk encryption set at the scope of the key vault|
|5||Configure automatic key rotation||Run the Azure CLI command to update the disk encryption set|
|6||Configure each Managed Disk to use SSE with CMK||Choose the encryption type (single or double) and specify a disk encryption set of the same type|
|7||Define a schedule to generate a new version of each key||Manually create a new version of the key|
All disk encryption sets referencing the key will automatically use the new version
Azure Disk Encryption
A further level of encryption to protect VM data, potentially accessible through capture of Windows page files or Linux swap files, crash dumps or application logs, is Azure Disk Encryption (ADE).
ADE uses familiar technologies of BitLocker for Windows and dm-crypt for Linux to encrypt operating system and data disks at the volume level. When encrypting VM volumes with ADE, an encryption key must be stored in a key vault which is enabled for ADE volume encryption as shown below.
ADE is not supported on all VMs such as basic tier sizes and those using dynamic volumes, shared file systems and failover clusters. ADE also limits the ability to move encrypted VMs between Azure subscriptions and regions and they cannot be used to deploy new VMs from associated images or snapshots.
A VM encrypted with ADE and backed up by Azure Backup can only be restored as a single entity. This is achieved by restoring the disks to a storage account in the same region and generating a custom ARM template to create a new VM. Individual file and folder recovery or cross-region restore is not supported for ADE VMs. ADE is configured at the VM level for the operating system disk and/or data disks using a nominated key as shown below.
When the individual disks have been encrypted within the operating system (BitLocker or dm-crypt), the portal reports them as enabled for ADE.
It is not possible to configure ADE if disks are SSE encrypted with CMKs.
It is important to consider the limitations when identifying VM for the additional security provided by ADE. The new encryption at host feature may meet those encryption requirements and offer additional benefits over ADE.
The table below summarises the actions for consideration when deploying Azure Disk Encryption for a VM.
|1||Create a key vault||The key vault must be in the same region and subscription as the VM|
Multiple key vaults can be created to support VMs managed by different teams or to separate test and production environments
|2||Enable key vault for ADE||Update the access policy|
|3||Create a key||Choose a key type of RSA|
|4||Configure ADE for a VM||Choose to encrypt OS disks only or both OS and data disks|
Encryption At Host
Encryption at Host (EAH) is a new feature that offers an alternative to Azure Disk Encryption in providing end-to-end encryption of VM data. This includes temporary disks and operating system caches that are not encrypted at the storage layer with SSE.
EAH uses the underlying host server’s processing power to perform the encryption and does not impact the performance of the VM. ADE however invokes operating system encryption which does use the guest’s allocated CPU.
Although EAH is host-based, it is configured for individual VMs.
EAH and ADE are mutually exclusive. Only one end-to-end encryption method can be deployed. The table below compares the benefits and limitations of EAH and ADE.
|Scope of deployment||VM||VM|
|Performance impact||None||Additional CPU required for guest-level encryption|
|VMs supported||All latest generations |
Dv3, Dv2, Av2, Ev3, NC, NV, H
|Most generation 1 and 2 VMs |
No local temporary disk: Dv4, Dsv4, Ev4, Esv4
Less than 2GB of memory or less than 8GB for Linux VMs encrypting OS and data disks
|Supported operating systems||All – encryption is at the host level||Windows 8 and above |
Windows Server 2008 R2 and above
Most (but not all) later versions of Ubuntu, RHEL, CentOS, SLES
Custom Linux images not supported
|Server-side encryption||SSE with either PMK or CMK||SSE with PMK only|
|Azure Backup||Supported with all recovery options: |
Restore VM (Replace existing)
Restore VM (Create new)
Restore VM (Restore disks)
Restore to secondary region
|Only supported for: |
Restore VM (Restore disks)
No individual file/folder recovery
No cross-region recovery to e.g. UK West
Recovery involves deleting the VM and creating a new VM from a template using restored disks
|Azure Site Recovery (DR)||Supported for cross-site replication and failover |
EAH must be enabled on the restored VM
|Supported for cross-site replication and failover |
ASR must be configured to nominate a key vault encryption key at the target site
|Resource migration||Supported||Moving VMs between subscriptions or regions is not supported|
|VM scale sets||Supported||Encryption of OS drive in Linux scale set not supported|
At the time of writing (May 2021), the EAH feature is not yet available in the public Azure portal but can be enabled with this command:
Register-AzProviderFeature -FeatureName "EncryptionAtHost" -ProviderNamespace "Microsoft.Compute"
and then accessed by this link: https://aka.ms/diskencryptionupdates
Enabling EAH for an individual VM is a configuration setting while the VM is deallocated, as shown below.
The table below summarises the actions for consideration when deploying Encryption at Host for a VM.
|1||Enable EAH in the subscription||Register the EAH provider feature|
Access the portal through a feature-enabled link
|2||Enable EAH for a VM||The VM must be shut down and deallocated|
The EAH toggle is an additional option from the Disks blade of the VM