Key Management Service (KMS)
S3 Encryption Mechanisms
SAA-C02- Exam Prep
This section of the Solution Architect Associate learning path introduces you to the core encryption concepts and services relevant to the SAA-C02 exam. We overview the AWS encryption options and how to select and apply AWS encryption services to meet relevant situations and scenarios.
Want more? Try a lab playground or do a Lab Challenge!
- Learn the fundamentals of Amazon's Key Management Service (KMS), including permissions, key policies, and key management
- Learn the fundamentals of CloudHSM, how it's implemented, and how to use it as a Custom Key Store in KMS
- Learn how to implement server-side encryption
We've now gone through the key encryption services that could make an appearance on the exam. So now I just want to take a look at some of the differences between these services and features to make sure you can comfortably answer any questions that appear relating to this topic. Now, encryption isn't always the favorite topic in the exam for people, but once you have grasped the essentials, you will find that the rest will soon fall into place.
So let's focus on the KMS service first, which is by far the most common encryption service that's mentioned. And you'll see more questions on KMS than CloudHSM that's for sure. So starting with KMS, the Key Management Service. From the name alone, it should be clear that this is used for some sort of encryption. Now, the Key Management Service is a managed service used to store and generate encryption keys that can be used by other AWS services and applications to encrypt your data.
Now, you've probably heard me mention a number of times through this entire learning path, about how KMS is integrated in one way or another for offering a way to encrypt data or logs. For example, KMS can be used with EBS for encrypting its volumes, or it can be used with RDS databases for encryption, or it can be used in conjunction with CloudTrail to encrypt log files. And again, where it's used a lot is with S3. And you'll probably see something about S3 and encryption on the exam.
Now, it's important to understand that the KMS service is for encryption at rest. So if a question relates to encryption in-transit, then you'll need to use a supporting service that uses SSL or similar to perform that in-transit encryption. Now the main key type in KMS is the same CMK, the Customer Master Key and these keys can only be used in a single region. So if any questions ask about moving encrypted data between regions using KMS, then be wary, as each CMK is regional. You can't copy it from one region to another. Now the CMK can either be AWS managed or customer managed, either way, it remains in the KMS service at all times, but it can be used to generate data encryption keys and these data encryption keys can leave the KMS service to help you encrypt other data. So key policies are used to define who can use and access a particular key within KMS, and every key must have a key policy. Now, the policies themselves define which users can administer the key and which can use the key for encryption.
Our curious question time again. What is the difference between Customer Master Key, the CMK, and data key in the context of the Key Management Service? So this tests your ability and understanding to differentiate between the different keys used within KMS. So let's take a look. A, a Customer Master Key is maintained in KMS while data keys are stored and maintained in IAM. Well, that's incorrect. All keys are created by KMS and they're not stored in any other services by default, especially not IAM. B, the Customer Master Key is used to protect data keys and data keys are used to encrypt and decrypt data objects. Now that is correct, because CMKs create data encryption keys and these data encryption keys are used to then encrypt additional data. So at this point, I'd be thinking B. C, the Customer Master Key can be restored if lost while data keys cannot be restored. That is incorrect. CMKs cannot be restored. D, the Customer Master Key is used to encrypt application data while data keys are used to protect AWS resources, like volumes and S3 objects. Again, that is incorrect. It's the data encryption keys that are used to protect application data. It's CMK that generates those data encryption keys. So the answer here is B.
Now, let's look at one final question regarding KMS. Now, you need to encrypt an Amazon EBS volume that you've just created, but you are uncertain as to which key you should use to do this. Which of the following statements gives the correct solution to this problem? So let's take a look. A, you can only use an AWS managed Customer Master Key. Well, if you remember back to our storage course, when you encrypt an EBS volume, you can either select the default encryption or you can select KMS and select one of your CMKs, so that is incorrect. You can only use a Customer Master Key. Again, incorrect, because you can use the default encryption which is an AWS managed key. C, none of these statements are correct. EBS uses encryption outside of KMS entirely. Again, that is incorrect. So it has to be D. You can either use a customer managed or an AWS managed Customer Master Key. That is correct. You have the choice if you want to use the default encryption, which would be an AWS managed key or a CMK that you have created from within KMS, which would be a customer managed CMK.
Now, quickly I just want to highlight the other encryption option service that we covered, and that was the CloudHSM service. So this encryption service offers a physical single tenant, tamper-resistant hardware appliance that is used to protect and safeguard cryptographic material and encryption keys. Now, sometimes this is required to meet certain stringent compliance requirements as it gives you more control around your keys and the key data than that of KMS. You can also combine KMS and CloudHSM by creating a custom key store in KMS and this is then backed by CloudHSM. So if you need to use KMS, but require the security and compliance of maintaining your own key material outside of KMS, then you can create a custom key store, which would be backed by your CloudHSM cluster.
So let's look at a very quick question covering CloudHSM. The question reads, can you use the AWS CloudHSM service without a VPC? So here you need to know some of the configuration elements of CloudHSM and the key thing here, is that you must have your CloudHSM cluster provisioned within a VPC. So let's look at our answers. Well, A says, yes, as long as the HSM and your infrastructure are within the same region. Well, no, because it needs to be in a VPC. B, yes, as long as AWS has been informed. Again, the answer is no, it needs to be in a VPC. C, yes, you don't need a VPC. Well, we know the answer to that already. And then D, no, CloudHSM must be provisioned inside of VPC. So the answer here is D.
Okay, the last part of the encryption summary I want to talk about is S3 encryption. This will more than likely come up in the exam, so it's a good idea to understand what options are available. Be sure to understand that S3 offers both server-side and client-side encryption options. So server-side encryption options include the default encryption with S3, which is SSE-S3, whereby S3 manages the encryption keys for you. You simply just need to tell S3 you want your object encrypted and S3 will handle everything else. However, if you want to encrypt your data with a specific CMK, you can use SSE-KMS. And as we know, this is the Key Management Service. So you can create your own CMK in KMS and then use this key to encrypt your object data.
Now, the last service-side encryption option allows you to supply your own encryption key that sits outside of KMS using the SSE-C option. So the client-side encryption options include CSE-KMS. Here you can use an AWS SDK to request data encryption keys from KMS to allow the end client to perform the encryption before the object is uploaded to S3 and you also have a client-side encryption option using customer managed keys too, with CSE-C. Now, the main encryption options that you're most likely to see in the exam, include SSE-S3 and SSE-KMS.
Okay, before we finish up, let's just review a question on S3 encryption options. So the question is, a user has enabled service-side encryption with SSE-S3 for an object. The user downloads the encrypted object from S3. How can the user decrypt it? So this is where you need to understand the different encryption and decryption options for each of those mechanisms. So, A, the user must provide a KMS data key. Well, the encryption option being used here if the default encryption, so we're not actually using KMS. So A is incorrect. B, the user needs to decrypt the object using their own account credentials. That doesn't really make any sense in regards to S3 encryption, so we can rule that out. C, S3 provides an object key to decrypt the object. Now, an object key isn't actually a thing when we're talking about the encryption here, so we can rule the answer out as well. And then D, S3 manages encryption and decryption automatically. So yes, that's correct. With SSE-S3, which is the default encryption, S3 will manage the encryption and decryption automatically without you having to provide any additional details.
Then one final question. A company security team requires that all S3 object data should be encrypted at rest using customer created encryption keys that are stored in AWS. So again, you need to understand the differences between each of these encryption options. So we're looking for a mechanism that handles customer created keys that are stored in AWS. So straight away, we should be thinking of the Key Management Service and a customer created CMK. So the option that springs to mind here is SSE-KMS. So if we look through each of these answers, we can rule out pretty much all of the other encryption mechanisms, because they don't offer that ability. So A is incorrect, as that's using SSE-S3, which doesn't use customer created keys. B is the correct answer, as that's used in KMS and you can use a customer created key with that. C is incorrect, because that's using a customer managed key that isn't managed and stored in AWS. D, client-side encryption won't work, because we need the encryption keys to be stored in AWS, and also E that uses Lambda functions is also incorrect.
Okay, you've made it through the last part of this section. Congratulations, that's another one down. So just remember that KMS is integrated into many different AWS services to provide a secure method of creating and managing encryption keys to protect your data, whereas CloudHSM enables you to easily generate and use your own encryption keys with greater control over the underlying key material. And S3 encryption options to focus on include, SSE-S3 and SSE-KMS, but it would serve you well to have an understanding of all the options available to you.
Okay, when you're ready, on to the next section.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.