3 big Amazon S3 vulnerabilities you may be missing

When there’s a data breach involving Amazon Web Services (AWS), more often than not it involves the Amazon S3 object storage service. The service is incredibly popular. Introduced way back in 2006 when few knew what the cloud was, S3 is highly scalable, reliable, and easy to use. But getting the security of S3 right—and making sure it stays that way—continues to confound many AWS customers.

As you’d expect with a popular cloud service that’s been around for almost a decade and a half, S3 has undergone numerous changes as more and more features are added. Over time, the added S3 functionality has also resulted in more complex layers of security that must be factored into your cloud security posture management (CSPM).

Before we dig deep into the layers of S3 security in our upcoming Cloud Security Masterclass (register here), we thought we’d take a quick look at three common ways AWS customers put S3 data at risk without realizing it.

Vulnerability #1: List permissions on Compute Resources

When an attacker gains access to your cloud environment, the first thing they want to do is get some visibility to see if there’s anything worth stealing. Fortunately for them, AWS customers often use list permissions on their EC2 instances or containers, which—depending on what list permissions are there—can give the attacker the ability to see what other AWS resources are in the account and IAM roles they may assume to access them.

There are few reasons to ever list permissions on EC2 instances, and you should enforce policy that forbids it.

Vulnerability #2: An over-reliance on IAM to prevent data theft

The AWS Identity and Access Management (IAM) service should be considered a security-critical resource for every AWS environment, and you should pay careful attention to your IAM configurations and receive notifications whenever they’re changed.

That said, even if you have your IAM resource configurations configured securely by employing the principle of least privilege, there are ways malicious actors can circumvent these protections to steal data from S3. Getting IAM right doesn’t mean you can ignore your S3 bucket configurations.

Instead of solely relying on IAM to be properly configured, use S3 bucket policies to constrain access at the bucket itself.

Vulnerability #3: Non-public S3 buckets that contain public objects

The first thing people usually think of when it comes to S3 security is whether or not public access is blocked or allowed for a given S3 bucket. You might assume that if you’re hosting sensitive information in an S3 bucket that you’d make sure public access is turned off, but many AWS customers make this mistake.

Corey Quinn, host of the “Screaming in the Cloud” podcast and “Last Week in AWS” email newsletter, regularly hands out S3 Bucket Negligence Awards. AWS has even added an alert on their console to let you know if a bucket allows for public access.

While there are legitimate reasons to allow public access to an S3 bucket (many websites are hosted in S3), most S3 buckets should not allow public access, and this setting is a good place to start. However, it is possible to have public objects in a non-public S3 bucket. AWS shows you how to do it here.

But this action is often done in error, exposing sensitive data in an S3 bucket that is otherwise secure, leaving you with a false sense of security for all of the data you store there.

Getting a Handle on Your Amazon S3 Security

Amazon S3 is incredibly flexible and easy-to-use, but S3 security is more complex and requires a deeper understanding of the layers of S3 security options and the full context of your unique cloud use case to get it right.