IBM Cloud™ Virtual Private Cloud -Block Storage Encryption Key Deletion
In parts one and two of my blog on IBM Cloud — Block Storage security I detailed the concepts of block volume encryption as well as encryption key rotation functionality. For a recap check out my blog post on Block Storage Encryption.
Both capabilities are critical components to securing data in the cloud however there is a third capability that is equally important when adopting a comprehensive security and compliance strategy, and that is customer root key deletion. In this installment I will provide an overview of encryption key deletion functionality and why it is an important tenant of a sound data security strategy.
What is Encryption Key deletion?
As is described in previous blogs, IBM Block Storage encryption keys are managed through one of two IBM Key Management Systems (KMS) available to customers. Both IBM Key Protect and Hyper Protect Crypto Services (HPCS) follow security guidelines documented in NIST SP 800–57 for the management of encryption key states. Customer root keys (CRKs) can therefore transition through different key states depending on customer requirements. In this blog we will focus on the delete use case which transitions a customer root key from Active to Destroyed and back again.
HPCS documentation defines the life cycle states of encryption keys in the following diagram.
As can be seen in the diagram an active customer root key can be deleted by the customer which will trigger an event placing the key into the destroyed state. In the event that the customer chooses to delete the root key, all encrypted block volume resources associated with that customer root key will become immediately inaccessible. Incidentally, this use case has been referred to as “key shredding” since the expectation is that the keys associated with block storage volumes will be “shred” thus restricting any further access to encrypted block volume data associated with those customer encryption key.
Notice, that the key deletion function deletes the encryption key associated with the block volume which prevents any further access to block volume data however this event does not alter nor destroy the block volume data itself. Block storage volumes will be placed into an unusable state such that the block volume cannot be attached to an instance nor data accessed in any way. Virtual machine instances with attached block storage boot volumes encrypted with the destroyed customer root key will be immediately stopped.
Likewise, encrypted secondary block storage volumes attached to a running virtual machine instance will be immediately detached to ensure sensitive data on the data volume is no longer accessible to the virtual machine instance. Of course, the later implies a virtual machine instances boot volume may remain active (using an active customer root key, or provider managed encryption), while the secondary volumes associated with the destroyed customer root key are detached.
To recap, the following actions occur when a customer root key is deleted
- If the boot volume is protected by a deleted customer root key, the associated virtual machine instance is stopped.
- If the boot volume and secondary volume(s) are protected by a deleted customer root key, the associated virtual machine is stopped, and the volume(s) detached.
- If only secondary volumes are protected by a deleted customer root key, the volume(s) are detached.
- Deleting of the customer root key sets the block storage volume into an unusable state.
- All events are logged and available in Activity Tracker
Restoring Deleted Keys
Referring back to the diagram above, you can see that a deleted root key can transition back from a destroyed state to Active state. This provides the ability to reinstate a purged root key thus enabling access to any block storage resources associated with that key. Restoring a previously deleted customer root key requires you as the customer to re-imported to the key to the KMS system which returns the key to an active state and re-establishes access the key. (Root keys that were KMS generated can’t be restored.) When restoring a customer root key, all block storage volumes associated with that key are returned to a usable state, and become available for attachment to virtual machine instances.
