If you have been following the latest news on AWS world, headlines like these aren't uncommon:
- "Company A exposes customers data after major S3 bucket breach"
- "Company B leaks the data of over 30.000 partners"
- "Company C exposes 2M users on misconfigured AWS storage"
Breaches related to S3 buckets are more common than it should be and, most of the time, puts companies in a bad situation, exposing their private information or, even worse, their customer's.
Corey Quinn, cloud economist at The Duckbill Group and active member of the community, even created the S3 Bucket Negligence Award, to "reward" individuals or companies that made it to the news after a major data breach.
Corey Quinn@quinnypigThis week's S3 Bucket Negligence Award goes to Facebook!
"Oh, it was one of their partners--" Stop talking immediately. They were the stewards of the data. They shared it with their partner. It is their responsibility, full stop.
upguard.com/breaches/faceb…19:25 PM - 03 Apr 2019
But, what all these cases have in common? They all happened due to the lack of proper security applied to bucket setup.
In this post, I will present the most common causes of S3 breaches and how to protect yourself against them.
By the end of this post, you will have a better knowledge about the tooling available and how to apply them to protect your data and don't become the next victim.
Familiarity with AWS and S3 is required to take the maximum out of this post.
This is by far the most common breach involving S3.
S3 buckets are, by default, created with all public access denied. It means that, unless special privileges are granted, one can't access the data. When a bucket is made publicly accessible, you give up restricting access to your data.
This has two major impacts: privacy and costs.
By having a public bucket, you no longer have control over who can or can't access your data. While it can be OK for public files, this can be a big issue for sensitive information.
Also, as described on S3 pricing model, the costs associated with a bucket are determined not only by the amount of storage used but also by the number of requests and data transfer, among others. So, with no caching mechanism in place, all requests are served directly by S3, and this can make your monthly bill pretty salty.