Azure Disk Encryption Process

Architectural Overview

All virtual machine disks are accessible by WebAPI off their underlying Storage volume (either through Storage Account Access or through Snapshot usage with Managed Disks).  In the case of Storage Accounts, a single factor of access exists for retrieval of disk Images from the internet (knowledge of URI and Storage Account key).  Different controls may be implemented to reduce the threat of data loss.  Core to these controls is the requirement for all data to be encrypted at REST. 

This is achieved through an implementation of vendor supported “Azure Disk Encryption”.

The term “Encryption at Rest” is often misrepresented when discussing Storage Accounts.  Microsoft’s implementation of “Encryption at Rest” is for when the storage volume is at rest… it isn’t the same as providing encryption of a Virtual Machine disk when the Virtual Machine is at rest.  For this reason, Disk Encryption is extremely important.

Azure Disk Encryption, as a process, utilises two distinct patterns during usage.

1. Secret Population

The disk encryption process creates unique secrets for unlocking each restricted drive.  This occurs during the initiation of the disk encryption.

1. Encryption Implementation

Virtual Machines are entitled to access specified Key Vaults for secret retrieval which allows disk decryption access files to be created and stored locally.  The represents BitLocker with Windows and  with Linux.

1.1.  Secret Population Process (Data Plane)

1.1.1.   Initiate

Disk Encryption is initiated by an RBAC authorised individual initiating the deployment of a particular VM Extension package for a targeted machine.  The Azure Management agent continually polls for extension

The Disk Encryption initiation request contains reference information that allows a Virtual Machine to identify a specific Key Vault for the storage of a unique secret.  This is effectively Windows-to-Go encryption… the key vault DOES NOT act as a virtual TPM chip.  Disk Encryption keys remain on attached virtual disk associated with the machine – akin to keeping keys on a usb key. 

1.1.2.   Authentication

During the initial key population process, the REST data access layer is utilised by the target host for submitting a unique secret for future storage.  Access to a nominated Key Vault is controlled through Azure Active Directory.

To allow Virtual Machines to authenticate and gain authorisation for the creation of new secrets, and object referred to as an Azure AD Application Registration must be created.  This element exists to allow processes (or people) to programmatically authenticate against Azure AD.  Azure AD Application Registrations provide no inherent rights or permissions… that comes from the Service Principal.

1.1.3.   Authorisation

The authenticated Service Principal must be granted “Wrap Key” and “Set Secret” permissions to a nominated key vault.

Key and Secret permissions are restricted to the principle of Least Privilege. 

The created Service Principle has no ability to query nor retrieve secrets or keys stored within the Key Vault.

After the Key Vault population (and disk encryption) process is completed, each machine will create a unique, wrapped, BitLocker Encryption Key within its nominated vault.

Azure Disk Encryption Implementation

The Azure BitLocker implementation uses “External Key” Key Protectors for providing access to AES 256 encrypted volumes.

This is achieved through the creation of a virtual USB key containing Bitlocker Encryption Key files.  This USB key remains attached with the provisioned Virtual Machine, providing drive unlock capability during the Operating System load phase.

Disk Encryption satisfies the requirement of Encryption at Rest from the perspective of Infrastructure as a Service while also providing a second control for data access from a Store Account perspective.

In the event that disk encryption keys are deleted from the virtual machines, Azure has the ability to restore the missing files due to an advanced key vault policy that entitles the provisioning service to access the vault contents.

From a security perspective, it’s preferable to maintain dedicated key vaults for encryption keys as a result of these advanced policies.

Access to the Key Vault is not required for day-to-day operations of an encrypted Virtual machine.  The Key Vault is used solely in the creation of the BitLocker Encryption files stored on the attached, virtual USB key.