Enabling IaaS Encryption-
What Encryption and Common Limitations Look Like (Part 3)
This is the final blog in a 3-part series detailing my investigations on the current state of enabling Infrastructure as a Service (IaaS) Encryption functionality. Details are accurate as of August 2018.
Throughout the series, I will explore the following articles:
- When to use Azure Virtual Machine (VM) Encryption and when to avoid it
- How to configure Azure VM Encryption including script walkthrough
- What Encryption looks like and what the common limitations look like
This article goes through some of the common tasks performed on VM’s and demonstrates their user experience
What VM Encryption looks like
After a VM has successfully run, a new volume will be available to the VMs named Bek Volume. This stores the system files for encrypting and decrypting bitlocker and must always be available to the VM. By default, the VM will assign it the next available drive letter, I have tested changing the letter and it appears to work.
To minimise the downtime associated with the encryption upgrade, bitlocker will not have finished encrypting by the time the server comes back online. This can be monitored using the following command from an admin command prompt:
Manage-bde –status
On my VMs it took between 1 and 2 hours to complete a 1TB data volume with minimal data activity.
key storage
Keys simply appear as unmanaged secrets in the specified Key Vault.
Each secret is tagged to allow for searching of the relevant VMs
Downloading the Virtual Disks (VHD)
If the VHD is downloaded and mounted it requires the bitlocker recovery key and not the standard decryption key. This means that unless the VM is in a bootable state it is not possible to recover data.
Running a virtual machine on-premise
Loading the VHD in a new VM is also blocked as it requires a virtual drive with the decryption keys on. This is the function of the BEK drive seen above. Without this data it is not possible to recover the drive as the recovery keys are not made available.
It may be possible to open the VM on-premises if, prior to the server being shut down for download the BEK keys in the BEK volume are copied and saved to a virtual floppy disk which is then used during the on-premises bootup process. This would be a limited time option if the Key Encryption Key (KEK) is used to rotate the bitlocker keys. I have not tested this process end to end so may also fail.
Disaster Recovery Experience
A similar thing happens when the new Disaster Recovery functionality is used, the sync happens and starts the VHD but because there is no integration with the key vault it is not possible to boot the VM. There is a feature request on the Microsoft UserVoice site so it may be possible to do this in the future.
Backup Experience
Configuring a backup is the same process as a non-encrypted VM. There is a significant divergence when attempting a restore. It is important that these differences are understood and practiced prior to an actual restore being required.
While a File Recovery Button still appears when clicking on it, you get the following message and no way to continue to the next screen.
When doing a virtual machine restore the process is the same until the final screen when the Restore Type is locked to Restore Disks. This requires additional PowerShell commands after the restore process has completed to recreate the virtual machine.
Details for creating the VM from the restored disks can be found here.
Conclusion
While the key processes of running an encrypted VM are available and supported, there are several processes which are currently limited if encryption is turned on. I would only recommend that encryption is turned on when there is a specific business requirement to do so. I do envision that this process will get easier as the Azure platform continues to develop so do check the official Microsoft documentation for any updates prior to making a decision.
