Enhancing Security for AWS S3 Bucket with HTTPS and KMS Requirements
Project Overview
As the owner of a bucket in Amazon S3, it is your responsibility to ensure that the bucket and its contents comply with the security guidelines and regulations of your organization. This lab will provide examples of best practices for preventing security issues in Amazon S3 and will teach you how to configure and test policies that control where the bucket can be accessed from, the access permissions for the bucket, and the encryption methods (both at rest and in transit) that must be used for compliance. Additionally, the lab will cover the type of encryption required for compliance.
OBJECTIVES
Upon completion of this Project, you will have learned how to use the AWS CLI to:
· Set up the bucket policy to allow only HTTPS connections.
· Set up the bucket policy to accept connections only through the VPC endpoint.
· Configure the bucket policy to accept object uploads that are encrypted with an accepted method and key.”
· Use the AWS Command Line Interface (AWS CLI) to verify that these requirements have been properly implemented.
LAB SCENARIO
To meet the requirements of this project, the following resources have been initially configured: an S3 bucket, a VPC with a public and private subnet, EC2 instances in each subnet with permissions to access the S3 bucket, and two AWS KMS keys. The public subnet has access to the internet via an internet gateway and the private subnet can access Amazon S3 through a VPC gateway endpoint.
Task 1: Connect EC2s to Session Manager and upload test objects.
· Use Session Manager to establish connections to both the public and private EC2 instances.
- Create and upload and list a test object to the s3 bucket from the public EC2 instance.
We have successfully created and upload the object01.txt in the S3 bucket from the public instance using a HTTP call API. Now, we do the same for the private instance.
- Create and upload and list a test object to the s3 bucket from the private EC2 instance.
By being able to view the contents of the bucket, it can be inferred that the connection to the bucket through the VPC endpoint is successful.
· Examine the current bucket policy settings for the lab bucket.
To view the current bucket policy, go to the Permissions tab and scroll down to the Bucket Policy section. You will see that the policy is currently empty, indicating that all permissions are now managed through the IAM policy for the identity that makes the API calls (in this case, the EC2 instances).
We will now begin setting up your bucket policy to impose specific requirements for accessing the bucket.
Task 2: Enforcing HTTPS connections
For this step, you will first test accessing the bucket using HTTP rather than HTTPS. Next, you will set up a bucket policy that allows access to the bucket only via HTTPS and verify that the policy is working correctly. In the previous task, you used the HTTPS endpoint to make API calls from the AWS CLI, which were sent over HTTPS on TCP port 443. However, if the endpoint also supports HTTP, you can make HTTP calls by selecting the appropriate protocol in your request.
- Accessing the bucket content through HTPP protocol
From the output above, we can see that we are able to view the contents of the bucket if we make HTTP call from the Private instance. At this point, HTTPS enforcement has not yet been configured.
- Configure a bucket policy to restrict access to the bucket using only HTTPS and verify it.
To secure your bucket, you will need to set up a bucket policy that denies any connections that do not use HTTPS. This policy should block all Amazon S3 actions to the bucket and its objects from any principal when HTTP is used as the protocol. To implement this requirement, you will need to find an appropriate IAM condition that allows you to achieve your goal.
Now let’s test if the HTTPS has been enforced.
We can now see that the content of the bucket is not displayed when we make a HTTP call from the private instance.
Task 3: Enforcing access to the bucket through the VPC endpoint
For this task, you will first update the bucket policy to only allow access to the S3 bucket through the private subnet and VPC gateway endpoint. After that, you will need to verify that the changes to the bucket policy are correct. Currently, the S3 bucket can be accessed from both public and private instances using different methods: the public instance accesses the bucket via the internet gateway, while the private instance accesses it directly through the AWS network without the use of internet or NAT gateways.
After updating the bucket policy, let’s check the following: s3:GetObject, s3:PutObject, s3:ListBucket for the public instance.
We now see that the public instance is restricted from listing, getting, or storing object in the S3 bucket.
On the other hand, the private instance can perform all the above tasks (List, Get, and put) as showed on the image bellow.
We have successfully enforce access to the S3 bucket through the private subnet and VPC gateway endpoint.
Task 4: Ensuring that object uploads are encrypted using your preferred method and AWS KMS key.
In this task, you will first test uploading objects to the bucket using different encryption options and keys. After that, we will need to update the bucket policy to enforce the use of KMS encryption and your preferred AWS KMS key for all uploads to the bucket. Finally, you will verify that the changes to the bucket policy are correctly applied.
For this project, two encryption keys named kms-green-key and kms-red-key were created. The default encryption is kms-green-key.Let’s create an object with the red key encryption.
In the object property on the Console Management, we can see the the encryption ARN matches the red key ID.
From these tests, you can determine that the bucket’s default encryption setting will only be used if no other encryption or key options are specified during uploads. However, it is possible to override these default settings during the upload process. As the bucket owner, you may want to ensure that all uploads use AWS KMS with your preferred key to address any potential compliance concerns.
- Finally, include a new rule in the bucket policy that blocks object uploads that are not performed using the “kms-green-key” key.
- Now let’s try to upload an object using the red encryption key.
We successfully restricted upload object with the red key.
- Now, we will attempt to upload an object while utilizing the green encryption key.
Uploading object with the green key is allowed.
Wrap Up
In conclusion, securing data stored in Amazon S3 is essential for any organization. This project aimed to provide you with the skills necessary to successfully enforce security best practices on your S3 bucket, such as controlling access locations, permissions, and encryption methods. By completing this lab, you will now be able to configure and test policies to ensure that your bucket is compliant with your organization’s security guidelines and regulations. Specifically, you will be able to configure the bucket policy to require HTTPS connections, restrict access to the bucket through a VPC endpoint, and only accept object uploads that use an accepted encryption method and key. You also have practiced on using AWS CLI for testing the policies. Remember, keeping your data secure is an ongoing process and it’s important to continue monitoring your bucket for any potential security breaches.
We’d love to hear your thoughts on this topic! Please leave a comment with your own experiences or ideas related to S3 security.
