Setting Up Smart S3 Bucket Policies 1

Amazon S3 (Simple Storage Service) is a powerful resource for applications that need storage on the internet. S3 is a scalable, reliable, and secure solution. The key to success is setting up smart S3 bucket policies that are beneficial to intended users but protected from prying eyes.

AWS S3 buckets, however, were in the 2021 headlines too many times for not good reasons. In February, Premier Diagnostics, a Utah COVID-19 testing service, leaked patient data records through two publicly available AWS S3 buckets that lacked any form of password protection or authentication. Over 200,000 images of ID scans were exposed. In May, Twilio, a large cloud communication platform as a service company, allowed a bad actor to gain read and write access to a misconfigured AWS S3 bucket. The hackers modified a copy of Twilio’s JavaScript SDK that they share with customers. And in early August, a misconfigured Amazon S3 bucket at SeniorAdvisor exposed details of over 3 million senior citizens, including individuals’ names, numbers, and email addresses.

S3 Bucket Basics

Hopefully you are already familiar with the Shared Responsibility Model. It means that AWS is responsible for protecting the infrastructure that runs Amazon S3. As an S3 user, your responsibility is to manage access to your data by assigning permissions and access levels.

AWS S3 bucket policies allow you to grant access to a bucket and the objects (files) it contains. Permissions apply to all objects in the selected bucket. They are critical in securing your S3 buckets against unauthorized access and attacks. As a bucket owner, you are the one who applies a policy to a bucket. Bucket policies are an Identity and Access Management (IAM) mechanism for controlling access to resources. You can add or update a bucket policy using the Amazon S3 console. You can also use the AWS Policy Generator to define a bucket policy for your buckets.

Best Practices for Bucket Policies to Secure AWS S3 Buckets

Bucket Naming

When you create a bucket, you choose a name and its AWS Region. Once created, you can’t change the name or Region. Names must be between 3 and 63 characters long, consist only of lowercase letters, numbers, dots, and hyphens, and begin and end with a letter or number. It’s best to use names that are relevant to you or your organization.

Private and Public Buckets

While some of your S3 buckets may need to be publicly accessible, most S3 buckets should have restricted access. That is, you should ensure that your S3 bucket is not public unless you explicitly need it to be. You should only grant permissions required to perform specific tasks. Least privilege access is fundamental to reducing your security risks. It’s best to use an IAM role to manage temporary credentials for applications or services that access S3. Using a role eliminates distributing long-term credentials (such as a user name and password or access keys). IAM roles supply temporary permissions for applications to make calls to AWS resources.

Encrypt Your Data

You should encrypt data at rest. For server-side encryption, S3 can encrypt your object before saving it and decrypt it when a user downloads the objects. From the client side, you can encrypt data before uploading data to S3. It’s also best to enforce encryption of data in transit using HTTPS (TLS) to block eavesdropping or network traffic manipulation.

Cross-Account Access

Allow cross-account access only when absolutely necessary. Use IAM roles to provide temporary credentials instead of distributing permanent access keys across accounts. Revoke all cross-account permissions when no longer required. Audit all cross-account relationships periodically.

Pre-Signed URLs/Origin Access Identities

When sharing objects with external users or services, generate pre-signed URLs with time-limited access to specific objects instead of making entire buckets public. Similarly, use origin access identities to allow access for CloudFront or applications instead of open bucket permissions.

Least Privilege

Employ least privilege principles when defining IAM policies for users, groups or roles. Only allow the specific permissions needed to perform required tasks to limit damage from compromised credentials.

Bucket Versioning

If you ever need to go back in time in relation to file changes, you should ensure that your S3 buckets have versioning enabled. It protects you from data loss from application issues or human error. When you enable versioning, S3 keeps multiple versions of each object in the bucket. When you upload an object with the same name, S3 stores a new version of the object. If you delete an object, S3 inserts a delete marker. As a side benefit, versioning helps with NIST, PCI-DSS and GDPR compliance. Note, versioning impacts S3 usage: S3 charges are based on storage, requests and data retrievals, data transfer, and data management.

Lifecycle Policies

You can customize your data retention approach and control storage costs by using object versioning with S3 Lifecycle. With S3 Lifecycle configuration rules, you can tell Amazon S3 to transition objects to less-expensive storage classes, or archive or delete them.

Monitoring

Audit logging is an important element of your organization’s data security. To detect suspicious behavior or spot security incidents, your organization should continuously monitor and audit user activities related to S3 buckets. You can enable CloudTrail data events for all your buckets or for a list of specific buckets. CloudTrail captures a subset of API calls, including calls from the S3 console and code calls to the S3 APIs.

Regular Audits

Periodically review S3 bucket permissions, update policies to revoke unnecessary access, and verify that configurations match security best practices. Regular audits are key to maintaining secure environments over time.