Data in AWS S3 buckets? Keep it from leaking

Originally posted at: https://technicalinitiative.com/2020/03/03/securing-data-in-s3-on-aws/

Amazon Web Services (AWS) has been instrumental in pioneering the migration of traditional workloads and data centers to the cloud. The ease of use and deployment have been key to their initial and continued adoption.

Unfortunately, this ease of use can allow nearly any somewhat technical user to deploy solutions without implementing ideal security configurations.

Let’s start by talking about AWS Simple Storage Service (S3) which is one of the most popular ways to store content on AWS. Users simply create “buckets” and allow access to the appropriate parties. Unfortunately, many of the large, high-profile hacks where terabytes of data or millions of users had their account information exposed, were results of “leaky” S3 buckets.

Why is this happening?

AWS provides a lot of tools including encryption, Access Control Lists (ACLs), and AWS took the right step by setting S3 buckets to “private” by default. Adding access to these S3 buckets is where this all begins to breaks down.

It’s almost too easy to add “too” much access, especially if things need to get implemented quickly. Sure, you can add individual, authenticated users access to the bucket(s), but what if you need to add 1000 or more users? We’ve seen buckets simply set to “public” to save time during configuration. Doing something like this now allows anyone, anywhere to access that bucket. Remember, the principle of least privilege should always be in effect.

Yes, ACLs exist along with Policies and Identity and Access Management (IAM) to help control access to the buckets, but too often, we’re seeing them misunderstood, misinterpreted, and/or misapplied leading to data exposure. For example, a very strict ACL could provide a false sense of security if the Policy that’s applied to the bucket is misconfigured!

Wait, doesn’t AWS have tools to prevent this sort of thing?

Yes, and more have been added as AWS has continued to grow and high-profile hacks have given them, and the company that left the data exposed, some bad press. Again, this wasn’t AWS’ “fault” per se, but when some AWS administrator leaves an S3 bucket wide open with Social Security numbers available for hackers, that’s not the kind of marketing AWS needs.

So we have buckets set to “private” by default, which is a great first step. After that, administrators really need to understand the interplay between ACLs and Policies before trying to allow access to more than one individual. ACLs exist along with Policies to help control access to the buckets, but too often, we’re seeing them misunderstood, misinterpreted, and/or misapplied leading to data exposure. For example, a very strict ACL could provide a false sense of security if the Policy that’s applied to the bucket is misconfigured!

It may sound draconian to keep everything “private” unless absolutely necessary, but there are simply too many cases where sensitive data has been exposed due to simple misconfigurations.

In 2017, Amazon introduced Macie, a security service that uses Machine Learning (ML) to help discover, classify and protect sensitive data in AWS. Alerts will be populated in your dashboard to let you know if your data is at risk. Additionally, there are functions like AWS’ CloudTrail and CloudWatch to log and analyze changes and transactions within your buckets.

Who else can help?

To give AWS some credit, they do provide a lot of training and warnings so please take the time to read and learn how to properly configure your S3 buckets. Having said that, if you’ve been roped into the AWS administrator role without much training, you will want to look for some additional help from AWS-certified resources or other services companies that can provide cloud-focused cyber security.

Additionally, you can enlist the help of Cloud Access Security Brokers (CASBs) that specialize in monitoring and securing your cloud environment can help you secure your AWS environment and monitor other “shadow IT” cloud applications that aren’t sanctioned for use in your company (for ex. Dropbox, Bittorrent, NNTP, etc.).

Bonus – There are numerous tools used by “greyhat” (and I’m sure malicious ones as well) hackers to identify “leaky” S3 buckets or even list the files within!