When it comes to AWS security, S3 buckets are undeniably the most vulnerable aspect of it all. Misconfigured S3 buckets have resulted in large-scale data breaches involving major organizations and continue to compromise data security at a staggering pace. Some notable S3 bucket-related breaches in the past include FedEx, Verizon, Dow Jones, and even WWE. Such breaches were avoidable because AWS is designed to be highly-secure, if configured properly.
This article is the sequel to our AWS Security Logging Fundamentals — S3 Bucket Access Logging tutorial, aimed at offering quick, actionable tips to not only help prevent, but also monitor and remediate S3 bucket-related breaches. Let’s review these techniques and best practices, tailored by our in-house security specialists, to help secure your cloud infrastructure and give the much-needed security boost that S3 buckets deserve.
To receive the next posts in this series via email, subscribe here!
Traditionally, companies have migrated to AWS because of the simplicity it promises. However, without applying the principles of data governance, even the most sensitive data ends up on the cloud. To make matters worse, a large number of companies migrate to AWS too fast, without dedicated personnel handling their data security.
Most of the S3 bucket breaches we have seen in the past, involved companies choosing the “all users” option, basically configuring data to be accessed publicly. The chances of inexperienced users misconfiguring S3 buckets and changing access control are fairly easy. Such a change can open up your S3 buckets for public access, resulting in unauthorized access and data breach. S3 buckets are vulnerable to being misconfigured easily, which is why they are a big security concern.
Let’s dig into the following practical techniques you can employ to strengthen S3 bucket security:
Encryption is an essential step towards securing your data. S3 offers the following two options to protect your data at rest:
Depending on your security and compliance requirements, you can choose an option that suits your preference. If you are fine with AWS managing the encryption process, then opt for Server-Side Encryption. Otherwise, go with Client-Side Encryption if your data is sensitive and you’d like to encrypt it yourself.
Additionally, encryption could be categorized further based on key management requirements. Here’s a self-explanatory table describing this:
The following example describes how you can secure data in S3 buckets using SSE-S3:
Sit back and relax! Your file is now securely encrypted on AWS.
Access Control is the most important pillar to help strengthen data security. We’ve identified five ways in which you can control access to your S3 buckets and resources. Let’s review each of the access control methods to help you build an effective S3 security mechanism:
Identity and Access Management (IAM) directly enables fine-grained access controls. By applying the principle of least privilege, you can assign users with the minimum access and resources required to administer buckets or read/write data. This minimizes any chance of human-related errors, which is one of the top reasons for misconfigured S3 buckets that leads to data leakage.
As a rule of thumb, start with a minimal number of permissions necessary and then add permissions gradually as you need them. If you are looking to get started with IAM or accelerating your organization’s identity and data protection efforts, then you might find our tutorial on AWS Identity and Access Management (IAM) Fundamentals useful for further reading.
Bucket policies are similar to IAM user policies with the main difference being that bucket policies are attached to S3 resources directly. Bucket policies allow you to be flexible and manage bucket access with fine-grained permissions.
There are several situations in which you’d want to use bucket policies. Let’s review some of the common scenarios here.
When you are allowing access from a different AWS account or an internal AWS service (CloudTrail for example):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowExternalAccounts",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"arn:aws:iam::234567890234:root"
]
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::my-data-bucket/*"
]
}
]
}
Code language: JSON / JSON with Comments (json)
When you are allowing access from specific IP addresses or ranges:
{
"Id": "AllowByIP",
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::my-data-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"157.130.196.214/32",
]
}
}
}
]
}
Code language: JSON / JSON with Comments (json)
Or if you want to allow requests to the bucket when certain conditions are met, such as HTTPS, MFA, time restrictions, and more.
During re:Invent 2019 in Las Vegas, Amazon announced S3 Access Points, a feature to improve access control with mixed-use S3 buckets, resulting in easier management of bucket policies.
Before S3 Access Points, bucket policies were applied to all data inside of a bucket with varying permissions, making it difficult to manage. S3 Access Points offer a new way to manage data at scale.
How S3 Access Points Work?
S3 Access Points have unique hostnames with their own access policies that describe how data could be managed using that endpoint. Access point policies are similar to bucket policies, with the exception that they are only linked to the access point. S3 Access Points can also be restricted to a Virtual Private Cloud (VPC) which helps to firewall your S3 data within that private network. This means each access point has a unique DNS name, making it easier for you to address your buckets.
Before AWS IAM became popular, ACLs (Access Control Lists) were the traditional feature used to control access to S3. Misconfigured ACLs are one of the biggest reasons why S3 data leaks are so widespread.
ACLs can be applied either on the bucket or on the object level. Simply put, Bucket ACLs offer access control at a bucket level, whereas Object ACLs offer access control at an object level. By default, Bucket ACLs only allow access to the account owner, but it’s generally very easy to make your buckets accessible publicly, which is why AWS recommends against using these.
Amazon also offers a set of predefined grants and permissions known as canned ACLs to support S3. For example, to make a S3 bucket private, you can use the private
canned ACL. Similarly, to make a S3 bucket public, use the public-read
canned ACL which gives Read access to all users. And by using the log-delivery-write
canned ACL, the LogDelivery group is granted Read and Write access, which is also how S3 logging is enabled. For a complete list of all canned ACLs and their related predefined grants, refer to the canned ACL table in the link here.
Finally, Amazon offers a centralized way to restrict public access to your S3 resources. By using the Amazon S3 Block Public Access setting, you can override any bucket policies and object permissions set before. It should be noted that block public settings can only be used for buckets, AWS accounts, and access points. You can learn more about using Amazon S3 Block Public Access here.
By having a data protection strategy that focuses on maximizing resilience, your organization can enhance S3 security and reliability efforts. Let’s review five such strategies to empower your data security choices:
To learn more about Replication, please refer to the Replication section on the AWS Developer Guide.
Using SSL is a great way to secure communication to S3 buckets. By default, S3 Bucket data can be accessed by using either HTTP or HTTPs, which means that an attacker could theoretically MITM (Man in the Middle) your requests to S3.
Let’s understand this with an example. To enforce end-to-end encryption on all traffic to a bucket, you can apply a bucket policy containing an explicit deny condition as shown here:
{
"Id": "ExamplePolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Action": "*",
"Principal": "*",
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::awsexamplebucket",
"arn:aws:s3:::awsexamplebucket\/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
Code language: JSON / JSON with Comments (json)
All requests that do NOT use HTTPS will now be denied.
S3 bucket access logging is a feature to capture information on all requests made to a bucket, such as PUT, GET, and DELETE actions. This empowers your security team to identify attempts of malicious activity within your buckets.
Logging is a recommended security best practice that can help teams uphold compliance standards, identify unauthorized access to their data, or perform a data breach investigation. In our tutorial on S3 Bucket Access Logging, we’ve offered detailed step-by-step instructions on how to leverage S3 bucket access logging to maximize security.
S3 Object Locking makes it difficult to delete data from S3. Malicious actors have been known to cause damage to organizational data predominantly in two ways:
S3 Object Locking works on the latter by preventing deletion of an object or from being overwritten. It essentially makes the S3 object immutable by offering the following two ways to manage object retention: by specifying a retention period or by placing a legal hold until you release it.
S3 Object Lock also helps you comply with regulatory requirements that require WORM, or simply for compliance purposes that require setting up an additional layer of protection. To learn more about how S3 Object Lock can help you with regulatory requirements, click here.
Enabling Object Lock
To enable Object Lock when creating a bucket, please use the following steps:
2. After you input a bucket name and hit Next, you’ll see a checkbox under Object lock in Advanced settings as shown below:
3. Click on the checkbox and you’ll see a notification indicating that the Object Lock is enabled. You can now click Next and continue creating your bucket.
Note: Object Lock works only when versioning is enabled. This way retention periods and legal holds apply to individual object versions.
To learn more about applying Amazon S3 Object Locks, check out the official AWS documentation here.
Panther is a powerful, cloud-native SIEM designed to analyze both security logs and cloud resources for total visibility of your infrastructure and resources. Panther directly supports S3 access log analysis and comes pre-installed with common detections for S3 attacks.
By deploying Panther, you can gain real-time insights into your environment and identify every suspicious attempt. Moreover, Panther’s log analysis allows you to convert log data into meaningful insights without being overwhelmed by machine-generated data. Panther equips you with everything you need to stay a step ahead in the battle against data breaches.
To get started, request a personalized demo.
AWS promises high levels of security, when understood and configured properly. Unfortunately, the truth of the matter is that many organizations don’t have the necessary resources and skills needed to build and maintain highly-secured AWS environments. It’s far too easy to misconfigure S3 buckets and make your data publicly accessible — with hundreds of services and tools at its helm, the complexity of AWS makes it challenging to achieve total visibility.
We hope that by following the techniques and strategies described in this article, you’ll prevent S3 buckets from being misconfigured, protect your IT workloads, and prevent data breaches.