AWS KMS is a multi-tenant solution for secure generation, storage, and usage of secrets. KMS keys are used to encrypt data across many AWS services, offering centralised management.
Use CloudHSM where you need keys to be stored in a single tenant environment.
- CMKs are used to encrypt and decrypt data keys. An account can make use of multiple master keys to divide access controls. Once created, these never leave the KMS service:
- Customer-managed CMKs can be managed entirely by the customer.
- AWS-managed CMKs are maintained by integrated AWS services, but are visible to the customer.
- AWS-owned CMKs aren't visible to the customer and are managed by and for integrated AWS services.
- Data keys are more granular keys that are used to encrypt data.
- Aliases provide meaningful names that map to CMK key IDs. They're required when creating CMKs from the console.
- Key policies allow controlling IAM users' and roles' access to CMKs.
- Custom key stores allow storing CMKs in CloudHSM clusters.
A CMK is created with a single backing key, which contains the key material used to encrypt all derived data keys. As the key is rotated additional backing keys will be be added under the CMK's existing identity.
CMKs can be either asymmetric or symmetric and may be generated for use both within KMS and outside of it. In the latter case, symmetric KMS keys will be encrypted with another symmetric CMK, and asymmetric key pairs' private keys will be encrypted with a symmetric CMK.
Customer-managed CMKs are enabled by default after creation and can be enabled and disabled by the customer. This is not possible for AWS-managed CMKs.
When generating data keys two forms of the key are returned:
- A cleartext representation of the key that should be used to encrypt data, then be erased from memory.
- An ciphertext representation of the key encrypted by the CMK.
Keys are stored with 99.999999999% durability in HSMs. Once generated, CMKs remain in KMS.
CMKs can be rotated automatically (annually), with old copies of the keys being retained such that data encrypted with the previous key material may still be decrypted.
Creating a new CMK to use in place of an existing CMK allows you to perform manual rotation on your own schedule.
Note that CMKs' backing keys are not rotated whilst they're disabled.
- In EBS, enabling volume encryption will allow you to select a CMK which will be used to encrypt a new data key. The data key is used to encrypt the volume, and its ID is stored in the EBS volume metadata. Snapshots of the volume will be encrypted with the same data key.
- CloudTrail stores a history of all KMS events for up to 90 days by default.