How to avoid S3 data leaks?

Not a week goes by without a frightening announcement that an organization has leaked confidential data from Amazon S3 accidentally. Most often, the root cause of a security breach is a misconfiguration of S3 access control.

Do you prefer listening to a podcast episode over reading a blog post? Here you go!

It may not have been AWS’s best decision to provide a service that allows you to both make data publicly available and store highly sensitive data. But it is what it is. Therefore, you should be very careful when configuring access control for your S3 buckets. The following rules make sure you do not make data available publicly.

Rule #1: Use IAM policies to grant access to your S3 bucket

Unfortunately, there are three different ways to control access to an S3 bucket. Use the following steps to decide which option to choose:

1. Use an IAM policy to grant access to your S3 bucket whenever the caller can authenticate as an IAM principal (user or role).
2. Use a bucket policy only in exceptional cases when using an IAM policy is not an option (e.g., to allow read access from the whole organization, …).
3. Never use bucket or object ACLs.

Believe me, when doing security reviews, I’ve seen too many misconfigured bucket policies and ACLs. Sticking to IAM policies simplifies access control a lot.

Rule #2: Enable Block Public Access

AWS announced Block Public Access in November 2018, a safety net to protect the data stored in your S3 buckets. There are four options available:

• Block public access to buckets and objects granted through new access control lists (ACLs)
• Block public access to buckets and objects granted through any access control lists (ACLs)
• Block public access to buckets and objects granted through new public bucket policies
• Block public and cross-account access to buckets and objects through any public bucket policies

Do none of your S3 buckets contain data that you want to share publicly? Lucky you!

Enable Block Public Access for all S3 buckets in your AWS account:

1. Open the AWS Management Console.
2. Go to the S3 service.
3. Select Block public access (account settings) from the sub-navigation.
4. Enable Block all public access.
5. Sleep well. 🛌

Alternatively, you can use the Terraform resource aws_s3_account_public_access_block to roll-out the configuration to your AWS accounts. Unfortunately, CloudFormation does still not allow you to do so. 😡

resource "aws_s3_account_public_access_block" "example" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

But what to do when you use S3 for both use cases: public and confidential data? In that scenario, you need to enable Block Public Access only for S3 buckets containing sensitive data.

By default, AWS enables all four options when you create a new S3 bucket via the AWS Management Console. However, you need to enable Block Public Access yourself when working with Terraform or CloudFormation.

Use the aws_s3_bucket_public_access_block resource when working with Terraform.

resource "aws_s3_bucket" "example" {
  bucket = "example"
}

resource "aws_s3_bucket_public_access_block" "example" {
  bucket = "${aws_s3_bucket.example.id}"

  block_public_acls   = true
  block_public_policy = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Alternatively, use the PublicAccessBlockConfiguration property of the AWS::S3::Bucket resource when working with CloudFormation.

MyBucket:
  Type: 'AWS::S3::Bucket'
  Properties:
    BucketName: 'example'
    PublicAccessBlockConfiguration: 
      BlockPublicAcls: true
      BlockPublicPolicy: true
      IgnorePublicAcls: true
      RestrictPublicBuckets: true

Don’t forget to enable Block Public Access for all existing and future buckets containing private data.

Rule #3: Separate public from private data

Do not mix public data and private data into the same S3 bucket. Doing so increases the risk of a misconfiguration dramatically. Also, make sure the name of your S3 bucket indicates whether it contains private or public data.

Rule #4: Monitor Trusted Advisor findings

I highly recommend asking a 3rd party to review your access control configuration regularly. You might want to task a professional to do so (hint: we are offering technical security reviews of IAM (including S3) and VPC networking). Another option is to ask the AWS Trusted Advisor for help.

The Trusted Advisor constantly scans your AWS account for typical weak points, not only of your security configuration, in an automated way. One of the many checks performed by the Trusted Advisor is called Amazon S3 Bucket Permissions which watches for public access granted by bucket policies or ACLs.

I highly recommend enabling Weekly Email Notification from the Trusted Advisor. That way, you’ll prevent missing a warning.

1. Open the AWS Management Console.
2. Go to the Trusted Advisor service.
3. Select Preferences from the sub-navigation.
4. Enable weekly email notifications.
5. Sleep a little bit better. 🛌

Summary

Take your time configuring the access permissions for your S3 bucket. Follow these three rules to avoid leaking data from S3:

1. Use IAM policies to control access to your data stored in S3. Avoid using bucket policies whenever possible. Do not even think about using a bucket or object ACLs.
2. Enable Block Public Access. If possible, do so for your AWS account to protect all buckets. If not, make sure to enable Block Public Access for all existing and future S3 buckets containing private data.
3. Do not mix private and public data within an S3 bucket. Also make sure, the bucket name includes the data classification.
4. Enable email notifications from Trusted Advisor to get notified of unintended changes to your bucket policies and bucket ACLs. Especially, watch out for the Amazon S3 Bucket Permissions check.

Are 3rd parties uploading data to your S3 bucket? Check for malware and viruses with bucketAV - Antivirus for Amazon S3.