SYS 360 Lab 5 2: Protecting Data in Your Application - JadenGil/Jaden-Tech-Journal GitHub Wiki

Creating a symmetric Key:

NOTE FROM LAB: Symmetric keys never leave AWS KMS unencrypted. The key that you create will be a 256-bit secret key.

NOTE FROM LAB: Key administrators are users or roles that will manage access to the encryption key. You are currently logged in to the console with the voclabs role. This user role is displayed in the upper-right corner of the console, to the left of the AWS Region.

NOTE FROM LAB: Key users are the users or roles that can use the key to encrypt and decrypt data.

Deliverable 1:

Storing an encrypted object in an S3 bucket:

NOTE: In the Default encryption section of the image bucket, you will notice that the setting is currently enabled. New objects stored in the bucket are automatically encrypted when this setting is enabled. This setting is enabled by default.

When uploading the image to the bucket the Server-side encryption settings should be the following:

Deliverable 2:

https://github.com/user-attachments/assets/b928a883-9ad5-43a3-a64b-c9fa04d2c0e4

Clock.png is now listed as an object in the bucket.

This diagram explains what happened when we uploaded the file to Amazon S3:

Attempting public access to the encrypted object:

Deliverable 3:

NOTE FROM LAB: The S3 object URL is one method to provide public internet access to an S3 object. However, by default, when you create an S3 bucket, public access to objects is not allowed. The default Block all public access security setting is applied to this bucket and all objects stored in it.

The public access settings of the S3 Bucket should look like this:

The object ownership settings should look like this:

We then want to go back to objects and select the clock png and make it public using ACL in the actions menu:

On the next page just select "Make Public" at the bottom of the page.

With those changes made we can go back to the tab that gave us an "invalid argument" and refresh. We will still see "invalid argument" but the error will be different:

ANALYSIS FROM LAB: Access to the object is now granted to the public internet (through the object URL); however, because the image is encrypted, you are still not able to view it.

This is a good thing, because it demonstrates an important reason that you might choose to encrypt data. In cases where access to data might be accidentally granted to someone who should not have access, the person won't be able to read the data unless they also have access to the encryption key. The encryption key is needed to decrypt the data and make it human readable again.

The error message indicates that Requests specifying Server Side Encryption with AWS KMS managed keys require AWS Signature Version 4. Signature Version 4 is the process to add authentication information to AWS requests.

Attempting signed access to the encrypted object:

When we open the image stored in the bucket and examine the URL it will look similar to this:

https://c46588a730572l1728517t1w501832962033-imagebucket-gmnhbh84muj.s3.us-east-1.amazonaws.com/clock.png?response-content-disposition=inline&X-Amz-...&X-Amz-...&X-Amz-...&X-Amz-...&X-Amz-...&X-Amz-...&X-Amz-...

The ... In that example would contain credential information

This diagram explains what happened when we requested to open the stored encrypted object.

Deliverable 4:

https://github.com/user-attachments/assets/56cfcb26-5d54-445e-9cd6-13d3a90e8934

Monitoring AWS KMS activity by using CloudTrail:

Using the search bar we can navigate over to CloudTrail:

NOTE FROM LAB: CloudTrail provides an audit log of API calls that are made in the AWS account. The event history provides access to events from the last 90 days of account activity.

EVENT RECORD ANALYSIS FROM LAB: This event was generated when you requested to upload the clock.png file to Amazon S3. Your action prompted AWS KMS to generate a new data key. If you go to the AWS KMS console and look at the key ID of the AWS KMS key that you created in task 1, you will find that it matches the keyId in the event record. Notice also that the event specifies the ARN of the object that Amazon S3 planned to encrypt with the data key, after it received the data key from AWS KMS. The event details also list the identity (principleId) of the user or role who made the request.

Deliverable 5:

DECRYPT EVENT RECORD ANALYSIS FROM LAB: This event was generated when you successfully opened the clock.png file from the Amazon S3 console. Notice that the record again details who made the request, which AWS KMS key provided the unencrypted data key back to Amazon S3, and which S3 object was decrypted with the plaintext data key.

CloudTrail logs all AWS KMS API activity. By evaluating these log entries, you might be able to determine the past usage of a particular AWS KMS key. If you want to be able to analyze events that occurred more than 90 days ago, you can create a CloudTrail trail.

Encrypting the root volume of an existing EC2 instance:

This diagram explains the steps you need to follow to encrypt an unencrypted volume:

We now want to navigate to EC2 (can be done through the search bar) go to instances and select the ID for the only available instance and navigate to the "Storage" tab.

In the "Block devices" section of the storage tab we can see that the storage volume is unencrypted:

https://github.com/user-attachments/assets/7a423bbb-703f-4c1f-89ee-19d8438c54b7

NOTE FROM LAB: You can encrypt a volume attached to an EC2 instance when you first create the instance. You can also encrypt a volume that is attached to an existing EC2 instance, including to the root volume, but it requires a few more steps. You will complete those steps in this task.

Now, back in instances we want to select "Labinstance" and stop it:

Then we want to go back to the storage tab and under block devices select the volume ID (do this again on the page it opens after selecting it the first time)

We will want to take note of the availability zone for later:

Then select "Actions" and "Create snapshot":

Enter the following information and select "Create snapshot":

Then under "Elastic Block Store" in the navigation pane select "Snapshots":

We want to wait till the snapshot status says "Completed" and we will also notice that the snapshot is not encrypted.

We now want to select the snapshot select "Actions" and "Create volume from snapshot":

The volume settings should be the following:

And then we can select "Create volume".

Under elastic block storage select "Volumes" and we will see that there are now 2 volumes:

Take a look at the volumes and see which one is "in-use" we will want to rename that volume to "Old unencrypted root volume":

Then select that volume, select "Actions" and then select "Detach volume":

Change the other volume name to New encrypted root volume select it and then go to "actions" and select "attach volume":

The attach volume settings should look like the following:

Then select "attach volume"

Deliverable 6:

https://github.com/user-attachments/assets/3df24a16-6dcc-4c84-bf29-fff59fc282c3

Disabling the encryption key and observing the effects:

We now want to go back to KMS and navigate to Customer managed keys if not already there.

Then we will select our key go to "Actions" and select "Disable":

(It will make you confirm that you want to disable the key)

With the key disabled navigate to EC2 again go to instances and select Labinstance and start the instance again:

Hit the refresh button located on the page and you will notice the instance is still stopped:

We will now navigate back to S3 go to "buckets" select the image bucket and select the clock png and open it. We will once again get an error but this time it is due to KMS being disabled:

Now we will go back to CloudTrail and examine the event history and select the "DisableKey" event link:

Examining the event details will show us that we disabled the AWS KMS key a few minutes ago.

Then we will go back to event history and select the "StartInstances" link:

This will show us our request to start the instance was successful but the instance never got to the Running state.

Going back to the event history we now want to select the "CreateGrant" link:

We will see our Decryption operation as well as the operation error code.

Deliverable 7:

Now we can finally return to KMS and re-enable our key:

Then we can go back into our EC2 instances and start Labinstance with no errors again: