A Step-by-Step Guide to Secure and Protect AWS S3 Buckets

Amazon Web Services (AWS) Simple Storage Service (S3) provides an easy option for storing documents, data and other information in the cloud. Unfortunately, you’ve probably heard of at least one critical data leak that was due to an unsecured S3 bucket. If you haven’t, a simple Google search will return a troubling list of breaches ranging from small companies and large corporations to state and federal governments.

It isn’t complicated or difficult to protect AWS S3 buckets, which might actually be the reason why it’s often overlooked or neglected. A simple mistake can lead to a misconfigured bucket, which can leave your data exposed and vulnerable. In this article, we will walk you through the process of securing your S3 buckets step by step. We’ll also explain how to monitor your S3 buckets and AWS configuration to ensure that you don’t become another cautionary tale from the land of breached buckets.

The Making of A Secure S3 Bucket

Let’s take a look at the process of creating and managing an S3 bucket, as well as the security implications of each step.

Is S3 the Right Place For Your Data?

Before you create an S3 bucket, you should ask the following questions: Does the information that you plan to store in S3 need to be held in S3, and is it subject to any regulatory guidelines? Personal, medical and financial information requires extra scrutiny, so S3 might not be the right place for it.

Selecting an Appropriate Name

Your S3 bucket needs to have a unique and DNS-compliant name. Your name cannot already be in use, it must consist of lowercase letters, numbers, periods, and/or hyphens, and it must be between 3 and 63 characters long. You’ll want a name that is meaningful but doesn’t advertise the contents of your bucket to the world. Names like acme-paychecks-2020 or widgetco-resumes might invite unauthorized access attempts.

Access and Activity Logging

An essential part of securing your S3 bucket is knowing who has access to it and what they’re doing with that access. When you create a bucket, you have the option of enabling server access logging and CloudTrail activity logging. (Thankfully, you can also enable these options on existing buckets.) AWS will store these logs in another S3 bucket, so the target bucket for these logs should be very secure.

Server access logs are free to create, though you will have to pay for the S3 storage space. These logs contain information about the requester, the target bucket, the response and other details about the request. Access logs also include information about requests that return error responses.

Activity or object-level logging integrates with AWS CloudTrail and will therefore cost you. These logs include detailed information at an object level, including the origin of the requests and the type of actions performed. You can view and analyze the logs in CloudTrail, and they are available for continuous writing to S3.

Encryption

When you’re creating a new bucket, you can also select an encryption option. Encrypting your data is always advisable. You can encrypt your information on the client-side before you upload it to S3, or you can use server-side encryption. AWS offers AES-256 with Amazon S3-Managed keys and AWS-KMS with KMS-Managed keys. It is possible to encrypt an existing bucket, but that involves a complex sequence of events including creating, transferring, deleting, and recreating buckets. It’s far easier to enable encryption when you create the bucket, and you can learn more about that process here.

Bucket Permissions

New buckets are private by default and only accessible to the owner and those who have been explicitly granted access. You can grant public access when creating a bucket by actively unchecking options on the Set Permissions screen. If you want to secure your buckets, it’s best to keep all of the options checked.

Access Control Lists

If you decide to grant public access to your bucket for some reason, you can control access to your objects with an Access Control List (ACL). This way, you can specify the access level for each item when it is uploaded. If you upload an object with public access and open policies, then anyone who has the HTTP link to the object can access it.

S3 Bucket Policies

AWS Identity and Access Management (IAM) is the core security and entitlement management system within the AWS ecosystem. When provisioning access to your S3 buckets, using the principle of least privilege will help prevent mistakes. By default, only the bucket’s creator has access to its contents. You can add additional permissions by attaching an IAM policy. Best practices dictate that you should use roles to grant specific access to a clearly defined collection of resources.

Opening a bucket and navigating to the permissions tab will give you the option to add a bucket policy. There is a link at the bottom of that page that will take you to the AWS Policy Generator, or you can enter a policy directly into the policy editor. You can see an example of a targeted, role-based IAM policy below. To create a policy like this, you’ll need two Amazon Resource Names (ARNs):

1 - The ARN for the bucket, which is available on the bucket policy page:

2 - The ARN for the role, which you can retrieve from the IAM role:

Here is the example policy using both ARNs:

{
  "Id": "Policy1601261057471",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1601261055507",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::acme-department120-documentation",
      "Principal": {
        "AWS": [
          "arn:aws:iam::XXXXXXXXXXXXXX:role/Department120_TeamMember"
        ]
      }
    }
  ]
}

This policy will allow anyone or any resource that uses the role to add and retrieve objects from this specific bucket. It does not allow them to delete items (which requires the s3:DeleteObject action).

Protect AWS S3 Buckets With Auditing and Monitoring

Now that you have a secure and well-managed bucket, the final step is to ensure that the bucket remains secure. If you enabled Access and Activity Logging when you created the bucket, you can review these logs periodically to identify failed access attempts and potentially malicious activity.

Reviewing logs can be tedious, however, and tedious activities typically don’t receive the attention that they deserve. A better and safer alternative is to partner with a third-party provider that is capable of monitoring your S3 activity automatically and responding to suspicious activity, vulnerabilities, and security threats.

Prisma Cloud for AWS by Palo Alto Networks simplifies the process of monitoring and protecting your S3 buckets as well as your other resources in the AWS ecosystem. You can find out more about Prisma Cloud for AWS in this datasheet.