Top 10 security best practices for securing data in Amazon S3
Table of Contents
Introduction
Top 10 Security best-practices
Block Public Access
Disallow wildcards “*” in Bucket policies
Disallow “Any authenticated AWS user” in Bucket ACLs
Implement least privilege access to Buckets
Enable Server Access Logs
Enable encryption at-rest
Enable encryption in-transit
Enable S3 Object Lock
Enable Object Versioning
Enable Multi-factor Authentication Delete
Conclusion
Introduction
AWS S3 is one of the most widely used services in the (ever increasing) family of services that AWS provides. The ability for a storage bucket to act not only as storage but also serve static websites right from the bucket itself is an amazing additional feature. However, having many features also invites the possibility of having misconfigured settings for the S3 bucket that can lead to our data stored in these buckets being at risk.
There are various pieces of documentation that refer to the best practices and security settings one must employ to keep S3 secure. However, this article has been written from the perspective of an attacker as well as a defender of cloud resources to give a better idea of what misconfigurations to look out for and what settings would make your S3, and the data that it holds, secure.
In this article, we will look at the top 10 actions to take for your S3 buckets to enhance their security. You can follow along with a test bucket within your AWS account.
Top 10 Security best-practices
Here is the list of the top 10 things to do to enhance the security of your S3 buckets:
Block Public Access
The public access block is a configuration for an S3 bucket to control access to the bucket and the objects in the bucket. By blocking public access, we safeguard our data from unauthorised entities. Unless you want the objects within your bucket to be visible to the world as part of your business requirements (CDN, image hosting etc.), you would want to ensure public access is blocked. There are search engines available (like grayhatwarfare) that hunt and curate openly accessible buckets and their object information for anyone to download.
Blocking public access can be enabled by following the given steps:
Log in to AWS console
Navigate to the S3 details page
Navigate to the relevant bucket’s details page
Click on the “Permissions” tab
5. Scroll to the “Block public access (settings)” section and click on the “Edit” button
Select the “Block all public access” option and click on the “Save changes” button. Optionally, one can choose to use the other options as needed
7. Alternatively, the following AWS CLI command can be used to block all public access to the bucket
Bucket policies are used to define fine-grained permissions for S3 buckets. They can be used to define which principles - IAM Users, roles, etc. can access the bucket, what operations - GetObject, GetBucket, etc. they can perform, and which bucket the actions can be performed are defined by the resource block. Using wildcards (“*”) in the policies is a bad security practice as it means all principal/actions are included, depending on which section the wildcard was used in. Thus, it is a good idea to add the right principals and “allowed” actions for those principals explicitly instead of using wildcards.
S3 bucket policies can be very extensive and thus it is not feasible to give all variations. So here is a sample bad policy that uses a wildcard for the principal and actions it can perform. The next policy shown has specific resources and a list of allowed actions on them, which is the recommended way of creating policies.
Bad Policy
Good Policy
The bucket policy can be updated by following the given steps:
Log in to the AWS console
Navigate to the S3 details page
Navigate to the relevant bucket’s details page
Click on the “Permissions” tab
Scroll to the “Bucket Policy” section and click on the “Edit” button
6. Add the policy in the given text area and click on the “Save changes” button
Alternatively, the following AWS CLI command can be used to add a bucket policy
Disallow “Any authenticated AWS user” in Bucket ACLs
Bucket ACLs is another way that can be used to permit different principals to perform actions on the S3 bucket and its objects. The “Any authenticated AWS user” option implies any global user that has an AWS account and does not mean only an authenticated user in the account in which the bucket was created. This is clearly not a secure configuration to allow anybody with an AWS account to list and read contents from our S3 buckets.
The bucket policy can be updated by following the given steps:
Log in to AWS console
Navigate to the S3 details page
Navigate to the relevant bucket’s details page
Click on the “Permissions” tab
5. Scroll to the “Access control list (ACL)” section and click on the “Edit” button
Ensure that the “List” action for objects and “Read” action for Bucket ACL is unchecked and then click on the “Save changes” button
Alternatively, the following AWS CLI command can be used to update the Bucket ACL
aws s3api put-bucket-acl —bucket —acl public-read
Note: This command can be used to update the Object ACL as well but it needs to be done recursively for each object. The command is as follows: