I have some follow-ups to my previous post on disk encryption in Azure, after I attended BRK3277 – Protect your data using Azure’s encryption capabilities and key management. I learned some interesting tidbits about how this works – the presenter is the owner of the functionality within Microsoft, so I’d consider his information to be authoritative. There’s broad capabilities within the Azure cloud to protect your data at rest and it’s definitely worth reviewing the talk if you’re interested.
Three points that came up that were of interest to me:
- When you run the command to enable disk encryption capabilities in Azure, you grant the platform (Azure hardware – ish) read-access – “read” secret and “unwrap” key to the Key Vault keys – this is interesting to me, as the whole point is to have very granular access to your secrets. My takeaway was that you should at a minimum separate your disk encryption keys into their own Key Vault, and if you have additional secrets that the platform reads (such as rights to read secrets at deployment) they likely should be isolated as well.
- The Azure Active Directory Service Principal configured when setting up Azure VM Encryption is used to write the keys into the Key Vault – the VM creates the Bitlocker Key; the VM Encryption Extension grabs the key and uses the Service Principal to write the key into Key Vault. Therefore, the AAD Principal never reads the keys. The permissions required for that are for Keys”WrapKey” and for Secrets, “Set”.
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultname -ResourceGroupName $resourcegroupname -EnabledForDiskEncryption
- When you back up a VM in Azure, the data is not encrypted-at-rest. This changes, of course, if the VM disk is encrypted. An encrypted backup presents a new problem – how do you deal with the data that is encrypted, if the keys are deleted or rotated? This question came up, and, as I understand it, the keys are extracted in an encrypted format from the Azure Key Vault, encrypted using the HSM root key, so they are virtually useless without the HSM. All actions in the Azure Key Vault are audited and logged, so you can monitor this carefully. This is discussed around 1:17:30 in the video. It’s still not sufficiently transparent, in my opinion.
The only action that Key Vault will let you take, through the backup API, is to export an encrypted key, which is encrypted by the HSM root key. This means that even though the backup service is keeping a copy of your key, it is encrypted by the HSM.
At the end of the session, one attendee happened to have a list of questions which conveniently overlapped with mine, so I had a few additional questions answered. That portion may be especially interesting to security people.