If you are using S3 buckets to store data, you’ll want to make sure that your data is protected, both at rest and in transit.
In this post, we’ll walk you through how to check and implement data security measures for both types.
Types of AWS S3 Encryption
Understanding and implementing S3 encryption is the primary means of ensuring that your data remains secure while at rest. The two main options for S3 encryption are server-side encryption (SSE) and client-side encryption (CSE). CSE puts all of the control (and responsibility) in your hands, whereas SSE can be easily managed through the Amazon AWS console or command line interface (CLI). In this post, we’ll mostly focus on setting up SSE encryption.
Encrypting Existing Objects
When you encrypt an existing object using SSE, you're actually replacing the object with an encrypted duplicate of itself. Because you are replacing the object, you should consider setting up S3 versioning so you can revert the change if necessary.
To overwrite an object with an SSE-S3 encrypted copy of itself, use:
To overwrite an object with an SSE-KMS encrypted copy of itself, use:
To overwrite an object with an SSE-KMS encrypted copy of itself using a customer-managed key, use:
To overwrite all of the objects in an S3 bucket with encrypted copies of themselves, use:
When you have replaced any existing non-encrypted objects with encrypted versions, then you can move on to setting rules for new objects.
Setting Default Encryption
Here are the different ways you can enable default encryption with either SSE-S3 or SSE-KMS for all new objects created in an S3 bucket.
To enable default SSE-S3 encryption, edit the rules section of the bucket as follows:
To enable default SSE-KMS encryption, edit the rules section of the bucket as follows:
Once you have made these changes, your data should be encrypted at rest for both your existing and brand new S3 buckets.
Finding S3 Buckets Not Meeting Your Encryption Standard
Now that you've handled at rest encryption, here's how to monitor and implement encryption for your data while it's in transit. First, check the security rules associated with an S3 Bucket.
Updating S3 Buckets with Security Policies
If “aws:SecureTranport” isn't showing up under your inbound and outbound rules, you'll want to implement it to ensure that your data remains secure while in transit. Data in transit is vulnerable to interception via a “man-in-the-middle” attack. You should also consider implementing “s3-bucket-ssl-requests-only”, which enables ongoing detective controls.
To add or edit a bucket policy, first sign in to the AWS Management Console and open the S3 console. From the Buckets list, select the bucket you want to create or edit a policy for. Click Permissions and then Edit (under Bucket Policy). You should be able to see and edit a JSON file containing your bucket policy.
In this JSON, look for “aws:SecureTransport” and change the boolean value from “False” to “True”.
To make a bucket compliant with “s3-bucket-ssl-requests-only”, you'll need to make some more edits to the JSON file. Modify the file to include these lines:
This will ensure that your S3 bucket explicitly denies access to HTTP requests, the condition required by the “s3-bucket-ssl-requests-only” rule.
Blocking Public Access to Your S3 Buckets
By default, new buckets, access points, and objects are not accessible to the public. However, users can change bucket policies and permissions to enable public access. Amazon S3 offers its Block Public Access feature to ban other users from enabling public access
With Amazon S3 Block Public Access enabled, any changes to policies and permissions that would otherwise allow the public to access your data will be overridden. The four relevant options (stored in your S3 bucket’s file) are: “BlockPublicAcls”, “IgnorePublicAcls”, “BlockPublicPolicy”, and “RestrictPublicBuckets”.
When “BlockPublicAcls” is set to “TRUE” on an S3 bucket, PUT Bucket acl and PUT Object calls fail if the specified access control list (ACL) is public.
When “IgnorePublicAcls” is set to “TRUE” on an S3 bucket, Amazon S3 will ignore all public ACLs on a bucket and any objects it contains. This will block public access while permitting PUT Object calls that include a public ACL.
When “BlockPublicPolicy” is set to “TRUE” on an S3 bucket, Amazon S3 will block all attempts to attach a policy to a bucket that permits public access.
When “RestrictPublicBuckets” is set to “TRUE” on an S3 bucket with a public policy, only authorized users and AWS service principals will be able to access the bucket.
Automate Security Checks with Blink:
For quick checks like this, using a specific CLI tool or script might get the job done, but it can be hard to incorporate it into your regular security practice. With a free Blink account, you can schedule this specific check to run regularly.
Create your free Blink account and start automating this task today.