Why Protegrity Our unique data security technologies are built for today's data-driven businesses. Learn More
Data Discovery Uncover where sensitive data resides
Data Management Control every corner of the enterprise
Data Protectors Protection beyond platforms
Professional Services Security experts for every need
Security Gateways Data security that goes with the data
Vaultless Tokenization Go beyond encryption
Contact Us
Posted on: December 19, 2017

Practical Amazon S3 Encryption and Beyond

With the recent news about data breaches from Amazon S3 buckets, largely resulting from customer mis-configuring their environment, we thought it would be a good time to talk about S3 security and data encryption. S3 offers many security features and Amazon is getting better at explaining how these features work, but there is much unstated. If you've spent any time rummaging around AWS documents, you already know answers to many simple questions are not there. So here we'll take a look at the basics around S3 bucket encryption and how best to use it.

Built in Security with AWS

Amazon S3

Amazon offers what is called 'Server Side Encryption' for S3, or if you are looking at an S3 bucket in the AWS console, it will be called 'Default encryption' under the properties sheet. You can enable encryption simply by toggling a button in the UI and telling AWS how you would like the key to be managed. One option is AES-256 keys managed per bucket, and the other option is allow KMS -- the AWS Key Management Service -- handle key management for you. Or you can enable these settings via an API call as well.

Server side encryption works much like Transparent Disk Encryption your already familiar with. If S3 receives a valid request to write a file, and the user is authorized to access that bucket, then as the file is written into S3 the data is encrypted. Conversely, if S3 receives a valid read request, and the user is allowed read access to that bucket, the requested object is decrypted and passed to the user. The key will either be provided by the S3 service or the KMS service. Keep in mind that with TDE style encryption, any user who has specific access rights to a file will be provided unencrypted objects upon request.

So, what threats does this help you address?

  1. When replicating S3 buckets across regions, the service provides 'least privilege', meaning if either the source or destination bucket has encryption enabled but the other did not, contents are encrypted.
  2. If you have a compliance obligation that mandates data at rest encryption, then you're covered as content is encrypted.
  3. And the biggest advantage is if an S3 bucket is encrypted with KMS, and you accidentally make the bucket public, the files are protected. The reason for this is even if the bucket is public and the request for files is valid, the KMS service does not provide the key for decryption and the request fails.

Moving Beyond AWS Security

For most AWS users, this is incredibly compelling as there is no charge for default encryption, does not create a lot of latency and provides some basic protections. That said, there are very good reasons to supplement what AWS -- or any cloud vendor -- provides for storage encryption. For example:

  1. When moving files from on-premise system to the cloud, or between clouds, you'll want to encrypt files before you move them. Storage security like S3 applies to the data stored within the service, not when it is extracted or copied. You can use TLS to help protect transfers to and between cloud vendors are secure, but network encryption does not ensure that the destination security settings are appropriate!
  2. If you wish to use different keys for different files. Technically speaking AWS encrypts each file, but the keys are provided per bucket, so in a practical sense it's bucket encryption as all objects are encrypted with the same key. Multiple keys provide some degree of segregation of data access and control.
  3. If you don't trust the cloud provider not to hand over keys under warrant or subpoena. As is the case with S3, as the cloud vendor holds the keys and the encryption algorithm, it is possible for this to occur.
  4. Within the EU's General Data Protection Regulation (GDPR) is a section granting users the right to be forgotten. Some companies are looking at 'crypto-shredding' -- essentially leave the data encrypted and destroy the key -- as a means to enable this capability. If you maintain control over the encryption of the data and the keys, you can ensure that content you wish disposed of is not read.

All said, AWS security in general -- and S3 security specifically -- is really good out of the box. Recently reported S3 'breaches' arise either from a simple mistake in access settings or a misunderstanding of how S3 security works, NOT security deficiencies in the Amazon infrastructure. If you couple the proper type of data encryption with IAM policies for user access, and bucket policies to tie network access to only known locations, your data is secure. For additional protection for scenarios like secure data movement between clouds and GDPR compliance, the AWS ecosystem has third party capabilities to supplement this security.

Adrian Lane is an analyst and CTO at Securosis, a security research and advisory firm. He brings over 22 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and software development. Having worked at Ingres, Oracle, and Unisys, he has extensive experience in the vendor community, but brings a pragmatic perspective to selecting and deploying technologies having worked on “the other side” as CIO in the finance vertical. He can be reached at alane (at) securosis (dot) com.

Topic(s): AWS , cloud security , encryption