Not everyone who encrypts data uses a key management solution. Since the days we started worrying about storage of personally identifiable information (PII) we’ve had different methods of protecting it. In a small environment, simple PGP (Pretty Good Privacy) keys were used to manually encrypt data and decrypt it. Storing keys for a few different partners that you routinely exchange data with was simple enough to do. But what about today when we’re storing sensitive data in databases, on storage volumes and in other people’s data centers, like Amazon Web Services. How do we manage numerous keys and make sure that those keys are properly maintained?
Amazon has a couple of ways to centrally manage encryption keys including the AWS Key Management Service or KMS. The KMS option from AWS gives some pretty simple mechanisms to centrally manage keys, but they also have a few drawbacks. If you’re trying to figure out what key management solution you should be using, consider these pros and cons.
The first topic to discuss is how the keys are used. The KMS solution makes it incredibly easy to do things like encrypt EC2 volumes, Lambda variable or S3 buckets. In fact you may be using KMS without even knowing it. If you’ve used Lambda or S3 encryption, the keys come from KMS.
So an obvious advantage to using KMS is that you might even being using it without knowing it. This qualifies as easy to use if you ask me. Chalk that up as a positive for KMS. Now, if you plan any client side encryption, you can still use KMS but you’ll need to use the SDK to have KMS encrypt the data before storing it. Client side encryption might include encrypting files before storing them on an EBS volume, or encrypting field level data into a database. While this would take more work than simply checking a box, it is still able to do it so no real downfalls here.
KMS allows you to use customer master keys (CMKs) created from withink KMS or you can import your own. If you choose to have KMS create the CMKs the keys can be rotated automatically by AWS on a yearly basis. This key rotation does not require you to decrypt and then re-encrypt the data that was encrypted by the key. Old keys are still available to decrypt the data and newly encrypted data will use new keys. If you are doing some client side encryption with KMS though, you may need to decrypt and re-encrypt during the key rotation process.
There are a couple of negatives about this key rotation, depending on your own perspective. KMS makes the rotation very easy but you don’t have much control over that rotation. AWS will rotate it for you on their own schedule (annually) but you can’t force that rotation. Also, if you import your own keys, you must manage this key rotation by yourself which negates the nice rotation service provided by AWS and even worse, you must decrypt and re-encrypt the data ciphered by those keys. So keep this in mind if you’re thinking about using your own keys.
Key Storage Types
The KMS solution available for use in AWS manages symmetric keys only. To review symmetric key specifics, it refers to using the same key to both encrypt and decrypt data. Cryptography techniques these days also use asymmetric keys such as X.509 certificates and PGP keys. These types of keys can’t be stored in the KMS managed service from AWS.
If you’re planning on using AWS for a bulk of your workloads you should also consider what services won’t work with any other encryption key management solutions. These are the AWS services that must use AWS KMS as the encryption key store:
- AWS Lightsail
- AWS EC2 SSM
- AWS CodeCommit
I would expect that as time moves forward the above services will allow for other key management solutions to be used but new services all seem to start with KMS first.
KMS, for the most part, should be a considered a highly available solution. When you setup your encryption keys, they are stored by region. So if you encrypt EC2 volumes in the US-East region, there will be a CMK stored in KMS for that region. If you switch to another region to encrypt EC2 volumes, a different key will be used. While this segmentation is great, it means that if there was a disaster that caused an outage to a large section of the East coast of the US, then these keys may be affected. This is a pretty extreme case and you might not care anyway, cause the workloads you have in that region were probably affected as well.
KMS keys are managed by AWS and as such are protected from an availability zone failure. This makes them pretty highly available since the loss of an entire data center won’t cause an outage for the service. Let’s face it, if you can’t access your encryption keys, the availability of your data may be irrelevant.
AWS KMS is a really easy way to centrally manage your keys. It comes with the audibility (through CloudTrail) that you’d need for an encryption key management solution. It has automatic key rotation which is a must for compliance purposes. It requires no setup to get started. If you’re looking for a more robust solution that can store asymmetric keys, or requires a Hardware Security Module, then KMS might not be for you. You’ll have to make your own decisions on whether or not KMS makes sense for your organization.