s3

In my previous post in this series about how to secure AWS S3 resources, I talked about the importance of securing your AWS S3 resources by making sure the proper permissions were set up for your buckets as well as the objects you place in those buckets.

In this post, we will talk about the different ways to encrypt the objects in your S3 buckets. Encrypting your S3 data is very important so attackers cannot steal your data. Let’s get into the meat of this post, shall we?

Check out our video tutorial related to this post:

Server-Side Encryption Options

Server-side encryption only encrypts data once it has reached the server and before it is stored on disk for uploads. It will decrypt the data on the server before returning it to the user for retrievals. Thus the data will be traveling over the internet unencrypted unless, of course, you are using TLS/SSL/HTTPS connections.

Using Standard AWS S3 AES-256 Encryption

Always selecting the default AWS S3 AES-256 encryption is the easiest way to get S3 server-side encryption. The key for this encryption method is managed by AWS S3 and is not configurable. You can find more information about this default encryption method here. The main gist is that when you create a new bucket, you can set the option to always encrypt all objects in that bucket using this method. Below you will find a screenshot of where the option is when creating a new S3 bucket:

Using KMS Managed Key Encryption

As you can see in the screenshot above, there is another encryption option using KMS Managed Keys. This is a great option if you want to control the rotation of your keys or delete them to render your data useless in case of a breach. You can also use different encryption keys for your development and production data if desired. HOWEVER, there is one major caveat that many smaller companies may really want to know about before using that option.

If you choose the KMS Managed key option, every object put into the bucket or read from the bucket will incur a lookup of that KMS key. Pricing for using KMS keys can be found here. If you add or request files in your S3 bucket many times each day, this cost can add up quickly. Just keep that in mind when choosing your encryption option for your bucket.

Using Customer Managed Key Encryption

AWS S3 now allows customers to provide their own encryption key(s) to encrypt and decrypt their S3 objects. There are a few ways of using customer-managed keys to encrypt your data:

• Using an AWS SDK for your project’s programming language such as AWS Java SDK or AWS .NET SDK
• You can also use the AWS REST API if you are using a different language than one of those listed above, or if you need direct access to the HTTP REST API

Client-Side Encryption

There is also the option to encrypt your data before sending it over to AWS S3 and decrypt it after receiving data from AWS S3. Adding Client-Side encryption in addition to server-side encryption enhances security. This also adds processing time and additional load on the client as it needs to do extra work.

There are numerous SDKs for different languages that support client-side encryption for S3 objects.

You can use either a Customer Master Key that is stored in AWS KMS, or you can use an encryption key that is stored within your application. You can find more information about AWS S3 client-side encryption here.

Do you or your company use Amazon Web Services (AWS) S3 to store data used for your applications? Then you’re going to want to make sure you secure and control access to that data. That way it’s not accessible by attackers! In this series of articles, I help explain how to secure your AWS S3 resources.

Check out our related YouTube video:

Controlling Access To S3

Setting Default Accessibility Options For Entire Account

The very first thing you’ll want to do is make the data accessible to only the people and processes that NEED access to it. In the majority of cases, this means making it inaccessible to everyone on the internet. You’ve probably seen stories of data in S3 being exposed to the whole internet due to faulty permissions (or no restrictions at all).

There may be reasons why you want your S3 bucket to be publicly accessible, such as when hosting a static website. So you need to verify which buckets should be kept openly accessible and which can be marked private. Marking a bucket as publicly inaccessible can break applications that need the public access. Be sure to note which ones are which before proceeding to the next step which will lock down all buckets in an account.

The first thing to do is set the account settings to block internet access to your S3 buckets by default. To do that, visit Block public access (account settings), and if Block all public access is set to Off, click Edit and then click to select all checkboxes and then click Save Changes. This will make all current buckets private and then make the default for future buckets to be private as well. This is a great default option if a majority of buckets in your account will be publicly inaccessible. If you have more buckets needing public access than not, the next section will be a better option.

Setting Accessibility Options When Creating a Bucket

When first creating a new AWS S3 bucket, on the Set Permissions screen during the setup configuration, you want to make sure to select the Block all public access option to disable all public access to objects in that S3 bucket. A screenshot of what this looks like is as follows:

This will block all access to the S3 bucket by default except for the account that created it. This means no services, applications, etc that need data from this bucket can see it now without using an AWS IAM policy or by utilizing AWS IAM roles.

Setting Accessibility Options For Specific Buckets

You can update settings for existing buckets if you have already created S3 buckets you need to secure. First, visit the list of S3 buckets you have created by visiting the AWS S3 Console and selecting the bucket to update. Once the selected bucket is opened, visit the Permissions Tab as shown in the screenshot below. Then click on Block Public Access. Now, click on the Edit button on the right-hand side of the screen.

Make sure Block all public access is checked and click Save on the right side of your screen.

This sets your S3 bucket to be inaccessible from any process, application, and user that does not have explicit permissions. This could have broken some applications or processes that may have been able to see those resources before. DON’T FRET! All you need to do now is set up an IAM policy specifying the exact actions and resources you wish to allow access to. Then attach it to an AWS IAM Role, and grant each process and application access using that role. Check out Assume an IAM Role via AWS CLI on how to do this via the CLI. Another good read is Creating a Role to Delegate Permissions to an IAM User.

You can also create an IAM policy for specific IAM users. Do this by also creating an IAM Group, attaching the IAM policy, and assigning the specified users to that group.

Conclusion

You should now be able to manage access to your S3 buckets to only allow access to authorized users and processes. Part 2 of this blog series goes over different encryption options for your S3 resources to keep your data confidential. So go check that out as well!