New Amazon S3 Encryption & Security Features

Back in 2006, when I announced S3, I wrote ” Further, each block is protected by an ACL (Access Control List) allowing the developer to keep the data private, share it for reading, or share it for reading and writing, as desired.”

Starting from that initial model, with private buckets and ACLs to grant access, we have added support for bucket policies, server access logging, versioning, API logging, cross-region replication, and multiple client-side and server-side encryption options, all with the goal of giving you the tools you need to keep your data safe while allowing you to share it with customers and partners as needed. We also brought the power of Artificial Intelligence and machine learning in to play, with the launch of Amazon Macie, a tool that helps you to discover, classify, and secure content at scale.

Today we are adding five new encryption and security features to S3:

Default Encryption – You can now mandate that all objects in a bucket must be stored in encrypted form without having to construct a bucket policy that rejects objects that are not encrypted.

Permission Checks – The S3 Console now displays a prominent indicator next to each S3 bucket that is publicly accessible.

Cross-Region Replication ACL Overwrite – When you replicate objects across AWS accounts, you can now specify that the object gets a new ACL that gives full access to the destination account.

Cross-Region Replication with KMS – You can now replicate objects that are encrypted with keys that are managed by AWS Key Management Service (AWS KMS).

Detailed Inventory Report – The S3 Inventory report now includes the encryption status of each object. The report itself can also be encrypted.

Let’s take a look at each one…

Default Encryption
You have three server-side encryption options for your S3 objects: SSE-S3 with keys that are managed by S3, SSE-KMS with keys that are managed by AWS KMS, and SSE-C with keys that you manage. Some of our customers, particularly those who need to meet compliance requirements that dictate the use of encryption at rest, have used bucket policies to ensure that every newly stored object is encrypted. While this helps them to meet their requirements, simply rejecting the storage of unencrypted objects is an imperfect solution.

You can now mandate that all objects in a bucket must be stored in encrypted form by installing a bucket encryption configuration. If an unencrypted object is presented to S3 and the configuration indicates that encryption must be used, the object will be encrypted using encryption option specified for the bucket (the PUT request can also specify a different option).

Here’s how to enable this feature using the S3 Console when you create a new bucket. Enter the name of the bucket as usual and click on Next. Then scroll down and click on Default encryption:

Select the desired option and click on Save (if you select AWS-KMS you also get to designate a KMS key):

You can also make this change via a call to the PUT Bucket Encryption function. It must specify an SSE algorithm (either SSE-S3 or SSE-KMS) and can optionally reference a KMS key.

Keep the following in mind when you implement this feature:

SigV4 – Access to the bucket policy via the S3 REST API must be signed with SigV4 and made over an SSL connection.

Updating Bucket Policies – You should examine and then carefully modify existing bucket policies that currently reject unencrypted objects.

High-Volume Use – If you are using SSE-KMS and are uploading many hundreds or thousands of objects per second, you may bump in to the KMS Limit on the Encrypt and Decrypt operations. Simply file a Support Case and ask for a higher limit:

Cross-Region Replication – Unencrypted objects will be encrypted according to the configuration of the destination bucket. Encrypted objects will remain as such.

Permission Checks
The combination of bucket policies, bucket ACLs, and Object ACLs give you very fine-grained control over access to your buckets and the objects within them. With the goal of making sure that your policies and ACLs combine to create the desired effect, we recently launched a set of Managed Config Rules to Secure Your S3 Buckets. As I mentioned in the post, these rules make use of some of our work to put Automated Formal Reasoning to use.

We are now using the same underlying technology to help you see the impact of changes to your bucket policies and ACLs as soon as you make them. You will know right away if you open up a bucket for public access, allowing you to make changes with confidence.

Here’s what it looks like on the main page of the S3 Console (I’ve sorted by the Access column for convenience):

The Public indicator is also displayed when you look inside a single bucket:

You can also see which Permission elements (ACL, Bucket Policy, or both) are enabling the public access:

Cross-Region Replication ACL Overwrite
Our customers often use S3’s Cross-Region Replication to copy their mission-critical objects and data to a destination bucket in a separate AWS account. In addition to copying the object, the replication process copies the object ACL and any tags associated with the object.

We’re making this feature even more useful by allowing you to enable replacement of the ACL as it is in transit so that it grants full access to the owner of the destination bucket. With this change, ownership of the source and the destination data is split across AWS accounts, allowing you to maintain separate and distinct stacks of ownership for the original objects and their replicas.

To enable this feature when you are setting up replication, choose a destination bucket in a different account and Region by specifying the Account ID and Bucket name, and clicking on Save:

Then click on Change object ownership…:

We’ve also made it easier for you to set up the key policy for the destination bucket in the destination account. Simply log in to the account and find the bucket, then click on Management and Replication, then choose Receive objects… from the More menu:

Enter the source Account ID, enable versioning, inspect the policies, apply them, and click on Done:

Cross-Region Replication with KMS
Replicating objects that have been encrypted using SSE-KMS across regions poses an interesting challenge that we are addressing today. Because the KMS keys are specific to a particular region, simply replicating the encrypted object would not work.

You can now choose the destination key when you set up cross-region replication. During the replication process, encrypted objects are replicated to the destination over an SSL connection. At the destination, the data key is encrypted with the KMS master key you specified in the replication configuration. The object remains in its original, encrypted form throughout; only the envelope containing the keys is actually changed.

Here’s how you enable this feature when you set up a replication rule:

As I mentioned earlier, you may need to request an increase in your KMS limits before you start to make heavy use of this feature.

Detailed Inventory Report
Last but not least, you can now request that the daily or weekly S3 inventory reports include information on the encryption status of each object:

As you can see, you can also request SSE-S3 or SSE-KMS encryption for the report.

Now Available
All of these features are available now and you can start using them today! There is no charge for the features, but you will be charged the usual rates for calls to KMS, S3 storage, S3 requests, and inter-region data transfer.

— Jeff;