The purpose of this lab is understand how to create, use, and manage keys on AWS.
- Create an S3 encryption key
- Create an S3 bucket with CloudTrail logging functions
- Encrypt data stored in an S3 bucket using an encryption key
- Monitor encryption key usage
- Manage encryption keys for users and roles
Create an encryption key
Before I start creating the encryption key, I need to know the default region that my account is connect to, in my case it is N. Virginia. Whilst I could change it to a closer region such as Sydney and reduce data latency, as this is not a business based account, I am not too concerned about latency.
Key creation is found in IAM: Encryption keys. I am using my admin account (not my root one), in order to have authorization to access Encryption keys.
When creating my key, I need to choose a filter. This is where the knowledge of my default region comes into play. An interesting piece of information to note from QwikLabs, is that ‘Identity and Access Management functions are generally global, however KMS keys must be managed in each region’. This provides an explanation as to why the knowledge of my account’s region is important.
Once I have sorted the region, I can create the key. However, now I need to give it a name and a description. I have chosen to stick with the alias and description written in the lab.
The lab manual explains that ‘it is a good practice to describe what services the encryption key will be associated with in the description’. It is for this reason that the description states KMS key for S3 data, as that is the intention of the lab.
Next, I need to define the Key Administrative Permission. These are, as the lab script says, ‘users or roles that will manage access to the encryption key’.
Finally, after organizing Key Usage permissions, I previewed the Key Policy, and finished the creation of the key.
The preview of the Key Policy is written in JSON format. This is the format that nearly all of the adjustable code for AWS is written. I can see User Permission and Key Administrator statements within in the code. These correlate to the previous steps that I made during the key’s creation.
As the key’s ID is incredibly important, I copied into a text file to store as back-up on my computer.
Create an S3 bucket, add CloudTrail to it, and encrypt the data in the bucket
These are the next two steps following the key’s creation.
First I needed to access CloudTrails through the AWS console.Then I created a new trail specific to the region, and with a specific S3 bucket.
QwikLabs offers the suggestion to use a unique name starting with testbucket, in order for easy location later.
Encrypt data in an S3 bucket.
This is where the encryption key comes into play. The intention here is to use the recently made encryption key to encrypt a file in our bucket created for CloudLogs.
Encryption options are accessed from the bucket. I select the file that I want to upload and then in ‘Set Details’, I select ‘Set Server side encryption’. I then use an AWS Key Management Service Master Key and select my created key
If I then click on the properties of the file and access the server side encryption, I can make a note of the last modified timestamp. This is part of the lab script, as a exercise in understanding that the ‘server side setting is set to the encryption key’.
Monitor and manage KMS key usage
The QwikLab script directs me back into the test bucket that I created. As this bucket is connected to CloudTrail, I can access a CloudTrail folder through my bucket’s AWSLogs. Within the CloudTrail folder should be a log file that as the script explains, ‘is in JSON format and contains each API that has been logged by CloudTrail.’ Within this script, I can find the word encryption, which will correspond to the encrypted file uploaded earlier.
Manage encryption Keys
Back in the IAM services, I can access the encryption keys and alter key descriptions, add or remove key administrators, adjust the access settings to key, and have the key annually rotated.
Having now learned about keys and how to use them, I can understand how they would be useful, even important in business documentation security. An idea for further expansion on this concept would be to play around with the access functions for key management, and look at how it affects different users that have access to that bucket, but different clearances.