Azure VM Encryption

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.

Key Vault

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.

Access Control

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.

Resource Protection

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.

Monitoring

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.

No.TaskDetail
1Define a key vault strategyExample: create a new key vault for each application/function per subscription per region per environment (test/production)
2Create a new key vaultKey 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
3Define permissionsAssign 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
4Configure monitoringCreate 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
5Integrate with Azure Private LinkDefine 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.

Server-Side Encryption

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.

Customer-Managed Keys

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).

Managed Identity

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.

No.TaskDetail
1Create a key vaultThe 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
2Create a keyChoose a key type of RSA
3Create a disk encryption setChoose 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
4Assign permissionsAssign the Key Vault Crypto Service Encryption User role to the managed identity of the disk encryption set at the scope of the key vault
5Configure automatic key rotationRun the Azure CLI command to update the disk encryption set
6Configure each Managed Disk to use SSE with CMKChoose the encryption type (single or double) and specify a disk encryption set of the same type
7Define a schedule to generate a new version of each keyManually 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.

Deploy ADE

The table below summarises the actions for consideration when deploying Azure Disk Encryption for a VM.

No.TaskDetail
1Create a key vaultThe 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
2Enable key vault for ADEUpdate the access policy
3Create a keyChoose a key type of RSA
4Configure ADE for a VMChoose 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.

FeatureEAHADE
Scope of deploymentVMVM
Performance impactNoneAdditional CPU required for guest-level encryption
VMs supportedAll latest generations
Not supported:
Dv3, Dv2, Av2, Ev3, NC, NV, H
Most generation 1 and 2 VMs
Not supported:
Basic
A-series
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 systemsAll – encryption is at the host levelWindows 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 encryptionSSE with either PMK or CMKSSE with PMK only
Azure BackupSupported with all recovery options:
Restore VM (Replace existing)
Restore VM (Create new)
Restore VM (Restore disks)
Restore files
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 migrationSupportedMoving VMs between subscriptions or regions is not supported
VM scale setsSupportedEncryption of OS drive in Linux scale set not supported 

Deploy EAH

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.

No.TaskDetail
1Enable EAH in the subscriptionRegister the EAH provider feature
Access the portal through a feature-enabled link
2Enable EAH for a VMThe VM must be shut down and deallocated
The EAH toggle is an additional option from the Disks blade of the VM

About the author