MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.2k stars 21.35k forks source link

Secops: Disk Encryption KEK/Secret Expiry #23332

Closed maneeshbhat21 closed 5 years ago

maneeshbhat21 commented 5 years ago

Hi team, The documentation is pretty nicely done.but just wanted to provide some feedback ,not sure if am unable to find the info here or if it available somewere else..From security point of view,we define the security matrix in our organization and based on the facts about the ADE on server the article doesnot anywere mention about the expiry of the keys or secrets that we want to keep according to our standards and what are the recommended from MS.Also,Would have good to provide info about the issues that will arise due to expiry of KEK when a VM wrapped with it and what things organization would need to do to take care of those..


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

MarileeTurscak-MSFT commented 5 years ago

@maneeshbhat21 Thanks for your feedback! We will investigate and update as appropriate.

shashishailaj commented 5 years ago

@maneeshbhat21 We have checked this internally and assigned to the author to get this reviewed by Program managers on how best we can update this article with the information requested.

@mestew Could you please have a look into the recommendations as suggested above and have this reviewed by any of the PMs . Thank you.

mestew commented 5 years ago

@shashishailaj & @maneeshbhat21 I am checking on this.

maneeshbhat21 commented 5 years ago

Thank you...

Jaykul commented 5 years ago

I was assuming it automatically rotates the KeyEncryptionKey and tracks the versions, and the only question is how often it does that -- is that not the case?

mestew commented 5 years ago

@maneeshbhat21 & @Jaykul I do have some information about key rotation:

Using standard commands is the recommended way to rotate keys and secrets. Some information on the versioning of objects is available here: https://docs.microsoft.com/en-us/azure/key-vault/about-keys-secrets-and-certificates#objects-identifiers-and-versioning

If a “key encryption key” is being used, think of it as a secondary key that is used to wrap and unwrap the underlying symmetric key used for disk encryption. Once that underlying key has been wrapped with a key encryption key, the same key encryption key will be needed again later to unwrap it. When starting a VM, the host has a reference to the key encryption key (if used) and the symmetric key. It will attempt to retrieve the symmetric key either directly, or by using the key encryption key to unwrap it. If these suddenly change and cause the key retrieval process to fail or to return a different key, the right key needed to unlock the encrypted disk will not be presented to the VM, and the VM will not boot.

If standard commands are not used to change and rotate these keys, you run the risk of changing the metadata needed by the Azure platform to retrieve the right key needed to unlock the encrypted disk. This retrieval is done when the VM is deallocated and restarted, or if the VM needs to be transferred to a new host as part of platform service healing. If the keys were changed outside of the VM before one of these events occurred, when it attempts to start the VM back up, it won’t be able to find or retrieve or unwrap the right key, and it will not be able to automatically unlock the encrypted disk.

If you use standard supported commands to provide the new keys, the extension is expected to be able to do the work of rotating into the new keys in the proper order. Test out KEK rotation (generating a new version of the key) on non-production machines first, of course, to make sure you've got the process down.

please-close