Understanding Key Deletion in AWS KMS

Introduction

AWS KMS is a pivotal component in managing encryption keys for our AWS services and applications. However, there comes a time when we might need to delete these keys. This post aims to demystify the key deletion process in AWS KMS, highlighting best practices.

Generated Keys: The Waiting Game

Generated keys in AWS KMS, those we create within the service, come with a significant feature: they have no expiration date. However, when we decide to delete one, we can't do so immediately. AWS imposes a mandatory waiting period of 7 to 30 days. Why? This grace period is a safety net, allowing us to reconsider the deletion or recover from an accidental deletion attempt.

During this waiting period, the key is in limbo; it cannot be used for encryption or decryption tasks. If we change our mind, AWS allows us to cancel the deletion process. Alternatively, if we merely wish to disable the key temporarily, we can do so instantly and then re-enable it when necessary.

What Happens at the End of the Waiting Period?

Once the waiting period concludes, the key and all its associated data are permanently deleted.

Imported Keys: Flexibility with a Catch

Imported keys, or keys we generate outside of AWS and import into KMS, offer a bit more flexibility:

• We can set these keys to expire after a certain period.
• Deleting the key material on demand is possible, effectively rendering the key unusable.
• AWS retains the key's metadata, so we can re-import the key material later.
• Like generated keys, we can disable and schedule imported keys for deletion, after which everything is deleted.

It's crucial to note that AWS-managed keys or AWS-owned keys do not have a deletion option.

Multi-Region Key Deletion: A Delicate Balance

Dealing with multi-region keys adds another layer of complexity:

Deleting Replica Keys

• Replica keys are less critical and can be deleted with relative ease. Should we need to recreate a replica, we can do so from the primary key (assuming it still exists).
• Deleting replica keys also requires scheduling a waiting period of 7 to 30 days.

Deleting Primary Keys

• A primary key cannot be deleted until all its replicas are removed.
• To delete a primary key while retaining its replicas, we must first promote another key to primary status and then proceed with deleting the original primary key.
• Similar to replicas, the deletion of primary keys must be scheduled, following a 7 to 30-day period after all replicas are deleted. Therefore, we need a minimum of 14 days to delete a primary key along with its replicas: 7 days to delete replicas and then 7 days to delete the primary key.

Best Practices for Monitoring, Logging, and Notifications

The deletion of KMS keys is a critical operation that demands close monitoring and logging to ensure the security and compliance of your AWS resources.

CloudWatch Alarm for KMS Key Deletion

Utilize AWS CloudTrail, CloudWatch Logs, and CloudWatch Alarms in tandem with Amazon SNS to set up notifications. This setup is crucial for being alerted when someone attempts to use a key that is pending deletion in any cryptographic operation, such as encryption or decryption.

Notifications for Key Deletion or Disabling

To keep tabs on keys being deleted or disabled, integrating AWS CloudTrail with Amazon EventBridge is the way to go. This combination allows us to receive timely notifications about key status changes, ensuring you're always in the loop.

Conclusion

Understanding the nuances of key deletion in AWS KMS is essential for maintaining the security and integrity of our data encryption practices. By adhering to AWS protocols and employing best practices for monitoring, logging, and notifications, we can confidently navigate the complexities of key management.