A few helpful tips on securing your S3 buckets are: Despite their popularity, data breaches are not uncommon with AWS S3 buckets. Indeed, some notable data breaches, such as the US voter records leak, which compromised the data of 198 million Americans, are attributable to misconfigured S3 access policies. The SEGA vulnerability that was recently discovered and patched, was based on similar S3 access issues. AWS users must know how to secure and protect their S3 buckets. This article provides some simple but effective tips that AWS users can implement to ensure that objects stored by them in S3 buckets remain safe.
How to Secure Your AWS S3 Buckets
We’ve divided the steps you can take to secure your S3 buckets into two sections. The first section outlines ways in which you can prevent a data breach by configuring access to the buckets. In the second section, we look at measures that help mitigate the impact of a potential data breach. Let’s understand the preventive steps you can take to secure your AWS S3 buckets.
Preventing data loss by managing access
Most AWS S3 data breaches are caused due to misconfigured policies that unintentionally grant public access. Therefore, properly configuring access policies is critical in preventing data branches. The level of access that others have to your S3 buckets will depend on what you’re using them for. Some use them to share information and data across large teams while others use them to store their personal information. While the former requires all team members to have some form of access to the bucket, the latter bucket should not allow public access at all. Luckily, AWS can be used to create granular access controls in the following ways:
1. Blocking public access
If you’re using S3 buckets primarily to store personal data or backup files on your devices, then it’s best to deny public access by default. This means that no one but you can access and edit the files. AWS S3 Block Public Access Settings allows you to block all 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
Consider using S3 Bucket Policies if you’d like others to have access to your buckets, but would like to control who can edit which objects and in what manner. These apply to all objects in the bucket and can be configured to restrict access in many different ways. For example, a bucket policy can be configured to allow access only from certain IP addresses: You can also use bucket policies to grant access if certain other specified conditions are met. For instance, you can reduce the chances of man-in-the-middle attacks by allowing access solely from HTTPS domains.
3. Managing roles using Identity and Access Management
So, for instance, you can grant only READ access to some users but for others, you can grant READ/WRITE access. Bucket policies, on the other hand, only specify what actions are permissible for a particular bucket. In other words, IAM deals with more macro permissions while bucket policies set more granular and fine-grained access rules. Using both IAM and bucket policies simultaneously is the optimal strategy. However, there are a few circumstances for which you’d specifically want to use IAM:
You deal with AWS services other than S3 and want to set permissions for all services at one go You have numerous S3 buckets with different permission requirements. It’s often easier to set a detailed IAM policy as opposed to setting up detailed bucket policies for each bucket.
While setting up your IAM policies, it’s advisable to follow the rule of least privilege. This means that you should start out by granting the minimum level of access and increasing permissions as required.
4. Defining object access using Access Controls Lists (ACLs)
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
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:
Final Thoughts on Securing AWS S3 Buckets
If you use AWS to store important data and files, then securing your S3 buckets should be a priority. Start by setting up access management policies and then put in place the mitigating mechanisms described above. You can add an additional layer of security to your AWS account by using multi-factor authentication (MFA). MFA usually requires users to authenticate themselves twice, once using their password and another time through a one-time password or authenticator app. Securing AWS S3 buckets doesn’t take a lot of effort but can be hugely beneficial in the long term. So why not do it now? Encrypting your data is a great way of ensuring that it doesn’t get completely exposed if a data breach occurs. You can learn more about how to manage access and permissions in AWS to keep your data secure. Please note that turning black public access will make objects in your bucket accessible to anyone with the correct URL.
Using bucket policies to define who can access objects in a bucket and in what manner. Identify and Access management to define roles for users in the larger AWS environment. Access Control Lists to manage access to individual objects within a bucket. Access Points to create scalable access policies for large datasets.
This guide on AWS S3 bucket security explains each of these methods in detail.
