To deploy good encryption practices, you must have control over your encryption keys. In AWS, this is all done through the AWS Key Management Service (KMS) feature, which allows you to create, control, and manage customer master keys (CMKs). In this demo, we will spotlight the three types of CMKs that are used in AWS KMS, including: 

For a visual guide to learning about AWS managed keys, customer managed keys, and custom key stores in relation to CMKs, watch the full demo. 

Read more about AWS-managed CMKs vs. customer-managed CMKs. 

We are logged into the KMS console within AWS. The thing you notice over here on the left is that there are basically three options that we have. An AWS managed key is created for each of the services where KMS-enabled encryption is provided. So, you see, here, just working through some things, we have one for S3 and one for EBS. These are AWS managed keys. That means that if you try to look at them, you don’t really get a lot to look at. You get a read-only version of what the policy actually says. Then, you also get to look at the cryptographic configuration. Again, these are managed by AWS and we don’t get to define things. We don’t get to extend the policy. We don’t get to change any of the key rotation parameters, or anything like that. But they are presented to you, here, because they are KMS keys that are unique to your account. 

Under customer managed keys, you can see that the customer master keys that we’ve actually defined. I used this key in some of the other videos that we’ve done in this series. If we look at this, you see we get quite a bit more to work with. We actually get to edit our policy. We get to define different deny or allow decisions based on different criteria. Again, we get to see the same cryptographic configurations. These parameters are not changeable after you initially set up a key. We get to define some tags so that we can categorize and organize our keys. We get to enable or disable key rotation. We’ll talk about this in just a second, but there it is. We also get to define some aliases. We could create my-awesome-key. We get to create our own aliases, as well. That is a helpful feature if the annual key rotation does not work in your situation and you need to rotate your keys on something different than that, then your applications could call the key by the alias and you just create new keys using the same alias. That would achieve the same effect. So, a customer master key, a CMK, is the more powerful option. 

Finally, the last option that we have is that we can get our key stores from an AWS CloudHSM service that we might be using. Those are our three options. 

Now, one of the important things to keep in mind when we’re talking about these keys is that these keys, within KMS, are used to protect the data key that is actually used to encrypt the content. For instance, with every file that is written to S3, a unique data key is used to encrypt that file when it is submitted to S3. That data key is then encrypted by these KMS keys, which provides an important capability. We can actually deny access to KMS keys as a form of access control, so that even though the user might be able to see the file, they might not be able to download the unencrypted version of it. That is an important capability as you think about your encryption strategies. Another use case for KMS keys is in both RDS and EBS, so your Relational Database Service as well as your Elastic Block Store. In those cases, RDS is really just backed up by an EBS volume. Whenever you create an RDS instance and you can use a KMS key to encrypt both the EBS volumes as well as RDS data stores. In that case, you are encrypting the volume key that is actually used by EBS to actually encrypt and decrypt the data, itself. Again, KMS keys in all the use cases protect the encryption key that is actually used to encrypt the data.