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 is still recommended practice 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.

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. A simplified encryption strategy flowchart is offered at the end of this blog for common recommended configurations.

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.

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

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.

Deploy EAH

The EAH feature 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.

Encryption Strategy

The following flowchart can be used to determine the most appropriate encryption mechanism for each Azure VM with supporting information given in the table below.