AWS is the top cloud provider worldwide, offering clients the same infrastructure Amazon uses for its e-commerce. S3, part of the AWS suite, is an object storage service for storing files, music, videos and more as objects.

However, S3 data breaches are not uncommon, such as the US voter records leak from a misconfigured S3 access policy or the recent SEGA vulnerability from similar access issues.

To keep S3 objects safe, AWS users need to secure their S3 buckets. This article offers simple tips to ensure the protection of objects stored in S3.

We have split the steps into two parts. The first part focuses on preventing data breaches through proper bucket access configuration. The second part covers measures to reduce the effects of a potential breach.

Let's examine the preventive steps to secure your AWS S3 buckets.

Preventing Data Loss through Access Management

Preventing data breaches from misconfigured access policies is crucial. The access others have to your S3 buckets depends on the use of the buckets. For example, if used to share data among teams, all members should have access while personal data buckets should not allow public access.

AWS provides granular access controls by:

1. Blocking public access

Denying public access is best for personal data or backup file storage in S3 buckets. Use AWS S3 Block Public Access Settings to block public access to objects stored in your buckets.

Using “Block all public access” overrides all other access permissions, such as Access Controls Lists (ACLs) and Access Points. If you do want to grant some form of access to others, you can choose between the four other options provided below.

Unless you’ve changed your global settings, all new buckets should block all public access by default.

2. Using S3 Bucket Policies to control bucket assess

Use S3 Bucket Policies for controlled access by others to your buckets. These policies apply to all objects in the bucket and can be set to limit access in various ways.

For example, a bucket policy can be configured to allow access only from certain IP addresses:

Bucket policies can also grant access based on specified conditions. For example, only allowing access from HTTPS domains reduces the risk of man-in-the-middle attacks.

3. Managing roles using Identity and Access Management

Use Identity and Access Management (IAM) in addition to S3 Bucket Policies to control access to your S3 buckets. IAM defines user permissions in the AWS environment while bucket policies set access rules for specific buckets.

Use IAM when dealing with AWS services other than S3 or having multiple S3 buckets with different access needs. Also, follow the principle of least privilege by granting minimum access first and increasing as needed when setting up IAM policies.

4. Defining object access using Access Controls Lists (ACLs)

Before discussing how ACLs can be used for S3 buckets, it’s important to note that Amazon recommends sticking to IAM and bucket policies for controlling access. This is perhaps because misconfigured ACLs have resulted in some of the more prominent S3 breaches.

With that disclaimer out of the way, let’s understand how ACLs are different from bucket policies. As we’ve mentioned previously, S3 bucket policies apply to all objects within a single bucket. Resultantly, it’s impossible to set differing permissions for different objects in an S3 bucket using bucket policies.

This is where ACLs come in handy. You can use one to set fine-grained permissions for each object within a bucket. So, while the rest of the bucket could be private, a specific object within it can be made public and vice versa. This is useful in situations where you may want certain objects within a bucket to have different access from other objects.

5. Using S3 Access Points

Amazon announced a new and efficient way of managing access to S3 buckets, known as Access Points. This new feature allows users to create unique access control policies for each access point in a bucket. As a result, managing access permissions across large S3 buckets, such as data lakes, is much easier with Access Points.

Instead of configuring a single lengthy policy for the entire bucket, users can control permissions using specific access points. This makes scaling permissions across large datasets a seamless process.

Access points can be used to grant access for an individual or a group and can be specific to a particular application or group of applications.

Users can use access points to ensure that all access to S3 resources happens only through a Virtual Private Cloud (VPC).

Tips to Mitigate the Impact of a Breach

At the end of the day, it’s a question of when and not if a data breach happens. Even if you’ve configured your access policies perfectly,  a malicious element on the web might be able to breach your S3 buckets. In such a situation, it’s important to minimize the potential harm of a data breach. Some useful ways of doing this are to encrypt the stored data and keep audit logs.

Encrypt data stored on S3 buckets

Encrypting the data you store on an S3 bucket helps ensure its security and sanctity in a situation where a hacker is able to gain access to your AWS dashboard. Resultantly, it prevents your data from being completely exposed in case a breach does happen.

You can encrypt your data in transit (during transmission to the AWS servers) and at rest (while stored in the AWS servers). For encryption at rest, you can choose between the following options:

• Client-Side Encryption – the user encrypts the data themselves before uploading it to the AWS server. The data is encrypted before it leaves your device. Hence, using client-side encryption ensures that data is encrypted during transit as well.
• Server-Side Encryption – AWS manages the encryption process. It encrypts user-uploaded data using standards such as AES-256 and decrypts it when needed. As the following image depicts, AWS offers two kinds of server-side encryption: SSE-S3, in which S3 creates and manages the keys, and SSE-KWS, in which the AWS KMS protects the encryption keys.

It’s important to enforce encryption during transit when using SSE. This is done by defining bucket policies that grant access only to requests using the HTTPS protocol, as discussed above.

Audit Logs

If a breach does happen, it’s important to identify and detect where it came from. This is where logging is useful. AWS lets you capture data on the different requests made to a particular bucket or object. Resultantly, potentially malicious access requests can be identified and blocked. Access requests can be logged in the following ways:

• Sever Logs – these logs contain details about the request, such as the requester and target bucket. Server logs are free to create. However, they are stored in a different S3 bucket, which will cost you money. The following images show how server logging can be configured.

• AWS CloudTrail – CloudTrail is a useful tool that allows for access tracking at the object level. It allows detailed activity, such as the origin of the request, to be viewed for each object in the bucket. That said, it is a paid service and will cost you in addition to the price of the S3 subscription.

In conclusion, securing your AWS S3 buckets is important for protecting your sensitive data. Use access policies, IAM, and ACLs to manage access and limit risks of data breaches. Consider adding MFA for extra security. Taking these steps will ensure your data is protected in the long run.