Understanding inbuilt AWS S3 security controls and methods - Part 1

Security is a key component and concept that you should focus on when it comes to data storage. Any misconfiguration in the security front of your sensitive data can bring a catastrophic impact on your business and its customers.

Since its inception in 2006, AWS S3 has been one of the prominent and go-to storage as a service and backup as a service for many software solutions across the world. Though lots of innovation happening around with AWS S3 service, we still see instances where a simple yet harmful misconfiguration in AWS S3 makes a way for large security breaches (https://www.zdnet.com/article/unsecured-aws-server-exposed-airport-employee-records-3tb-in-data/).

As stated in the Shared Responsibility Model documentation by AWS, Security and Compliance are shared responsibilities between AWS and the customer. AWS will inherently provide you with physical and environmental security for the services you consume. But when it comes to patch management, configuration management, and awareness and training, the responsibility is shared between both the customer and the Cloud Service Provider (CSP). Hence it's the same with AWS S3 service as AWS is responsible for maintaining the durability, availability, and physical security of data that resides in S3, its the customer’s responsibility to enable and configure the AWS S3 service (buckets and objects) with proper security controls and methods to ensure that the data resides on S3 are secure and cannot be accessed from unauthorized parties.

AWS has provided its customers with several security controls and methods to improve the security posture when using the AWS S3 service. This article series will go through all those in detail.

Before we go through the security controls and methods that AWS S3 offers, it’s really important to understand how resource ownership works in AWS S3. That will be the key focal point for part 1 of this article series.

These are a few points that you should grasp when it comes to principles of resource ownership by default.

• Buckets and objects are considered resources in AWS S3. By default, when a bucket is created or an object is uploaded to Amazon S3 the ownership of that bucket and the object will go to the AWS account.
• You can set up permissions to allow another AWS account to upload resources to a bucket created by your account. In such cases, by default, if that AWS account uploads an object resource to that bucket the ownership of that object resource will be with the AWS account which did the upload and not the AWS account that acts as the bucket owner. But this behaviour can be overridden by setting up the permissions in bucket configuration as shown below.

Go to Permissions Tab on your S3 Bucket configuration

Scroll down and select Object Ownership

Edit the Object Ownership setting

As you can see in the above figure, there are three settings that can be used to control the ownership of the objects uploaded to the bucket.

ACLs disabled

• Bucket owner enforced (recommended) — In this setting ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket. ACLs are no longer considered when assessing permissions to data in an S3 bucket. Bucket policies can be used to define access control. Activating this setting will apply it to all the existing and new objects as well. This setting was introduced in November 2021.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Only allow writes to my bucket with bucket owner full control",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::AccountA:role/AccountARole"
        ]
      },
      "Action": [
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::AccountB-Bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}

ACLs enabled

• Bucket owner preferred — This setting provides the bucket owner full control over new objects that other accounts write to the bucket with the bucket-owner-full-control canned ACL. If you activate this setting, you should ensure that you set up a bucket policy to grant a specific user or a role to upload objects into that bucket using the bucket-owner-full-control canned ACL. Refer to the sample bucket policy given below,
• Object writer (default) — The AWS account that uploads an object owns the object, has full control over it and can grant other users access to it through ACLs.

You can read more about these controls by visiting the AWS Documentation.

For the majority of the use cases, AWS recommends disabling ACLs by choosing the bucket owner-enforced setting and using your bucket policy to share data with users outside of your account as needed.

With a solid grasp on the resources and resource ownership in AWS S3, let’s deep dive into understanding security controls and methods provided by AWS S3 in the upcoming articles on this article series.

References

1 — https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html

2 — https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-owner-full-control-acl/

3 — https://aws.amazon.com/compliance/shared-responsibility-model/

Understanding inbuilt AWS S3 security controls and methods — Part 1

Understanding inbuilt AWS S3 security controls and methods — Part 2

Understanding inbuilt AWS S3 security controls and methods — Part 3

Understanding inbuilt AWS S3 security controls and methods — Part 4