AWS S3 buckets are by far one of the most used AWS services available on the market because they offer an easily-accessible, inexpensive service for data storage. They let organizations store, access, and retrieve data anywhere on the internet using a simple web-based interface. But with all of this ease, comes cybersecurity insecurity — mainly, negligently unprotected AWS S3 buckets that have been badly misconfigured, leading to data breaches.
There are many examples of high-profile S3 bucket breaches. For example, Expedia’s hotel reservation software provider exposed millions of hotel guest records in a data breach because they were storing sensitive guest data in an unsecured S3 bucket. And, there are many more stories like this.
Countless organizations make the mistake of leaving S3 buckets open. Administrators often assume that S3 buckets are inherently secure simply because they run on AWS. While AWS offer high-quality cloud security, here are a number of steps to take that can prevent breaches from occurring:
- Block public access to S3 buckets.
By default, all new buckets, objects, and access points are not set up for public access. Yet, users can modify policies and S3 permissions to allow public access — meaning sensitive data could potentially get accessed by any user via a URL. Unless the company explicitly requires anyone on the internet to read or write to an S3 bucket, ensure that all buckets are not public. To block public access, use the S3 Block Public Access settings to override S3 permissions and prevent accidental or intentional public exposure. These settings let administrators centralize account controls for maximum protection, regardless of how the resources are created.
- Identify bucket policies that allow wildcard IDs.
Next, an organization should identify S3 bucket policies that allow a wildcard identity, such as Principal “*” or allows a wildcard action “*” that effectively lets the user perform any action in S3. According to AWS, this may include one or more of the following:
- A set of Classless Inter-Domain Routings (CIDRs) using aws:SourceIp;
- An AWS user, principal, or service principal;
- aws:SourceArn;
- aws:SourceVpc;
- aws:SourceVpce;
- aws:SourceOwner;
- aws:SourceAccount;
- s3:x-amz-server-side-encryption-aws-kms-key-id;
- aws:userid, outside the pattern "AROLEID:*";
- s3:DataAccessPointArn.
Amazon provides instructions on how to make policies non-public. For an overview, check out this article. Similarly, take note of AWS S3 bucket access control lists (ACLs) that offer read, write, or full-access to “Everyone” or “Any authenticated AWS user.” To consider a bucket policy non-public, it must grant access to fixed values — or values that do not have a wildcard.
- Inspect implementations with tools.
It’s a good idea to use AWS Trusted Advisor to inspect S3 implementations to make sure the administrator has covered all of their bases. Trusted Advisor is an online tool that offers real-time guidance and support when provisioning resources on AWS. This service can increase security, optimize the infrastructure, and reduce operating costs, among other benefits to offer baseline support. AWS also offers real-time monitoring through the S3-bucket-public-read-prohibited and S3-bucket-public-write-prohibited managed AWS Config Rules.
- Enable multi-factor authentication delete.
Companies can also enhance security by making a bucket’s versioning configuration MFA Delete-enabled.
When security teams set a bucket for MFA Delete-enabled, a bucket owner must include the ‘x-amz-mfa’ request header in requests to permanently delete an object version or change the bucket’s versioning state. In addition, requests that include ‘x-amz-mfa’ are required to include HTTPS. A header’s value contains an authentication device’s serial number, authentication code, and a space. Failure to include this information in the request header will result in a failed request.
- Encrypt all data.
Security team should encrypt all data while in transit (i.e., traveling to and from S3) and while at rest and stored on disks in S3 data centers. Security pros can easily protect data in S3 using client-side encryption or by using Secure Socket Layer/Transport Layer Security (SSL/TLS).
- Use S3 object lock.
S3 Object Lock lets an administrator store objects using a write-once read-many (WORM) model. By using an Object Lock, security pros can prevent an object from being overwritten or deleted for a fixed time period or indefinitely.
- Enable versioning.
Versioning can help protect enterprise data from user actions and application failure. When bucket versioning is enabled, AWS can store all objects when receiving multiple write requests for the same object simultaneously.
- Use multi-region application.
AWS now offers Multi-Region Application Architecture that lets users create fault-tolerant applications with failover to backup regions. This service uses S3 Cross-Region replication and Amazon DynamoDB Global Tables to asynchronously replicate application data across a primary and secondary AWS region.
- Enforce least privilege access.
Organizations can also prevent unauthorized access to S3 by enforcing least privilege access and granting permissions to identities only when specific tasks need to be performed.
AWS offers several tools for implementing least privilege access including IAM user policies and Permissions Boundaries for IAM Entities, Amazon S3 bucket policies, Amazon S3 access control lists (ACLs), and Service Control Policies.
It’s also a good idea to keep a running tab over all the human and non-person identities that have access to your S3 data. Follow these nine recommendations, review this AWS security checklist, and seek assistance should an administrator require help with governing an AWS S3 bucket or S3 permissions.
Eric Kedrosky, chief information security officer, Sonrai Security
