Why Do Amazon S3 Data Breaches Keep Happening?
3TB of data involving airport staff across Colombia and Peru was exposed to anyone on the internet. The report called out an “unsecured AWS server” as the source of the breach.
Digging a little deeper, we find that the data was stored in Amazon S3, not an unsecured AWS server.
Why does it matter?
Running a server takes a lot of work. There are updates to run regularly, resources to monitor, configurations to tweak, and threats to monitor for.
A server has a high operational cost.
They should be avoided whenever possible. Technologies like serverless, containers, or managed services are almost always a better choice for your solutions.
Amazon S3 is a managed service. This reduces the operational cost of managing your data and should made having a strong security posture easier.
Why Is It Always S3?
In Amazon S3, you create a bucket and you put objects inside that bucket. Think folders and files.
The shared responsibility model that runs the entire cloud dictates that you are responsible for the data you store in S3 and the configuration of S3 as a service.
This is where the challenge lies.
By default, an S3 bucket is only accessible to the user or system that created it. It’s locked down and you have to explicitly choose to provide access.
This access is typically provided through a service called IAM or Identity and Access Management. This is an immensely powerful service that allows you to create all sorts of different access scenarios.
Unfortunately, it can be tricky to wrap your head around this system and how to configure it to match your intentions.
Mistakes here are what leads to these types of data breaches.
If you’re wondering why it’s always Amazon S3 and not another CSPs offering, it’s simply a matter of scale. S3 is one of the most popular cloud services out there.
When using a system like IAM, you want to apply the principle of least privilege. This concept means that you only grant the permissions required to the people or systems required to complete specific tasks.
If you only need to write a file, you only get write access to that specific file.
Unfortunately, this principle seems to be in direct opposite of idea of “get it working ASAP.” 🤦
This leads to a lot of permissions being set to “anyone can do anything.”
Sadly, given the flexibility of the system, even when you try to set least privilege permissions, mistakes still happen.
This is when you should use a tool called that Access Analyzer for S3. This free tool helps ensure that what you’ve set as permissions matches what you want as permissions.
That’s a critical step to protecting your data and staying out of the headlines.