Amazon Simple Storage Service (Amazon S3) is one of the well-known services for storing data in the cloud of Amazon Web Services (AWS). The service is secured in accordance with AWS default policies, however, accidentally exposing data stored in buckets is easy to happen if you start changing existing default configurations or ignoring alerts.

In the article below, Viet-AWS will take a few important steps to protect the data stored in the Amazon S3 service.

Step 1: Name the S3 bucket (Bucket Naming)

The first step in the security of Amazon S3 or often ignored by users is the naming of buckets.

On the Internet, you’ll easily find tools to scan and enumerate the names of publicly available buckets such as bucket-stream and S3Scanner. If you accidentally configure the public, the bucket of the organization will easily be “seen” by the above tools and the data in the bucket will likely leak.

Bucket names are resolved by DNS so bucket names can be found on DNS logs or when public. AWS will provide a link where users can connect to S3 Bucket, such as tenbucket.s3.amazonaws.com.

* Effective bucket naming

Viet-AWS’s advice, as well as from the AWS side, is that the name of the bucket name in Amazon S3 should be unique and limited to coincide with any other bucket. This bucket name is only recognizable to you but does not give a clue who this bucket belongs to/what organization it belongs to.

For example: When naming buckets that store highly secure data, you can name it data-1-abcdef. With ” data ” being the purpose of the data stored in the bucket,“1” to show that this datais only known to you or your team (which can be typed “2” with public data) and “abcdef” is a random phrase or number.

You should limit the use of AWS Account ID in bucket names because they are vulnerable to revealing business information and identities.

Step 2: Set up log tracking and monitoring for Amazon S3

Requests to S3 buckets at the bucket level such as creating or deleting buckets can be tracked by the AWS CloudTrail service. Therefore, we encourage enabling AWS CloudTrail services and placing CloudTrail logs in a separate account (not related by other services and for read-only permission such as AWSCloudTrailReadOnlyAccess) for safety.

Learn more about AWS CloudTrail Identity-Based Policy: AWS CloudTrail Identity-Based Policy Examples – AWS CloudTrail (amazon.com)

In addition to the actions at the bucket level above, we also encourages recording logs of actions inside buckets, e.g. PUT, GET, and DELETE actions, helping you track who or what accessed (or tried to access) your data.

2.1. Log Monitoring for Amazon Simple Storage Service

There are 02 main ways to monitor logs in Amazon S3, including CloudTrail object level logging and S3 server access logging. we recommend activating at least one of these methods, using CloudTrail is the easiest option.

CloudTrail logs record requests made to S3, IP addresses, request implementer, date stamp, and some other details.

S3 server access logs provide newline-delimited logs that can contain additional details to help you investigate. Read more S3 server access log format at: Amazon S3 server access log format – Amazon Simple Storage Service

2.2. Set up the accompanying alerts

Besides log monitoring, you should still set up some alarms with Amazon CloudWatch on Amazon CloudWatch metrics (Amazon CloudWatch request metrics for Amazon S3).

Read more: CloudWatch metrics configurations – Amazon Simple Storage Service.

For example, when the bucket is only used to store CloudTrail logs, there will be an alert every time the object is deleted (but PUT and GET requests to have a low threshold). This usually occurs when an attacker masks a trace in Amazon S3.

In addition, depending on the support plan of your organization’s AWS account, you can use AWS Trusted Advisor’s Amazon S3 bucket permissions check to check open access permission.

2.3. Using Amazon GuardDuty

Amazon GuardDuty is a smart threat detection service that you should act to help detect threats and abnormalities and has Amazon S3 protection.

This feature allows GuardDuty to monitor activities at the object level to identify potential security risks to data in S3 Buckets.

If you have activated the Amazon GuardDuty service, go to the control panel (in each region you have activated) and verify that you have Amazon S3 protection enabled.

An example of architecture using Amazon GuardDuty with Amazon S3:

2.4. Access Analyzer for S3

Access Analyzer for S3 informs you that S3 Buckets are configured to allow access by anyone on the internet or by other AWS accounts (both inside and outside the organization).

For example, access analyzer for S3 may show that a bucket has read or write permissions provided through bucket access control list (ACL),bucket policy, or access point policy. Access Analyzer for S3 works by activating the IAM Access Analyzer first.

Step 3: Encrypt data for Amazon S3

Encryption is considered an additional layer of security to control access to Amazon S3 data. Encryption will give deeper control over access to your bucket.

There are many encryption options in Amazon S3, however, the easiest way to activate is also the easiest to use, and also very secure is the default server-side encryption using AWS Key Management Service. The default encryption will be valid with all new and available buckets.

If you don’t use KMS default encryption, you must try to encrypt requests to objects in the bucket and have to set a bucket policy to reject uncoded requests.

* Note when configuring AWS KMS

1. When using the KMS key, pay attention to request quotas per second, if less than 5000 requests / second, do not worry too much. Upon reaching the threshold, AWS KMS returns the ThrottlingException error as follows:

You have exceeded the rate at which you may call KMS. Reduce the frequency of your calls.
(Service: AWSKMS; Status Code: 400; Error Code: ThrottlingException; Request ID: <ID>

2. Consider using different keys for data sensitivity levels, and each key’s access will have to be different.

For example, each KMS key will be used for different buckets in the same AWS account, the data and sensitivity level at each bucket are different.

3. Use the AWS Key Management Service Key (SSE-KMS) and select your own custom key to enabling default encryption:

Step 4: Access Control

4.1. Prevent access to Amazon S3 from outside (Public)

You can easily set up central controls to limit public access to S3 buckets regardless of whether they’re old or new buckets.

Buckets or “public” ACL objects only if members who are granted access are identified as users of the AllUsers group and the AuthenticatedUsers group.

If a request is made from Amazon S3 Access Point, Amazon S3 checks whether public access prohibition policies apply to Access Point and will reject this request if it applies.

There are many different configurations for block public access, we recommend activating the whole (Block all public access). However, it is still necessary to check the logs of the buckets to avoid blocking requests from valid sources.

4.2. Access Control List (ACLs), AWS Identity and Access Management (IAM), and Bucket Policy

ACLs are one of the basic ways to grant access to buckets. Resource-based ACL – in this case, S3 bucket – to manage access (as opposed to identity-based as users/roles such as AWS Identity and Management). With AWS IAM, IAM policy will impact bucket levels and object levels.

When you create a bucket or an object, Amazon S3 creates a default ACL, granting resource owners full control over the resource. You can also attach S3 ACLs to each object in the bucket to manage access to those objects

ACL template grants access to Amazon S3 bucket

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
     <ID>Owner-canonical-user-ID</ID>
     <DisplayName>display-name</DisplayName>
  </Owner>
<AccessControlList>
  <Grant>
     <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
     <ID>Owner-canonical-user-ID</ID>
     <DisplayName>display-name</DisplayName>
  </Grantee>
  <Permission>FULL_CONTROL</Permission>
</Grant>

  <Grant>
     <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
       <ID>user1-canonical-user-ID</ID>
       <DisplayName>display-name</DisplayName>
     </Grantee>
     <Permission>WRITE</Permission>
  </Grant>

  <Grant>
     <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
       <ID>user2-canonical-user-ID</ID>
       <DisplayName>display-name</DisplayName>
     </Grantee>
     <Permission>READ</Permission>
  </Grant>

  <Grant>
     <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
       <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI>
     </Grantee>
     <Permission>READ</Permission>
 </Grant>

  <Grant>
     <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
       <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>
     </Grantee>
     <Permission>WRITE</Permission>
  </Grant>

  </AccessControlList>
</AccessControlPolicy>

However, to be simple in setting up access, you can use other methods. Include bucket policy if you want to grant permissions to another account or use IAM policy (SSO) if you need to grant access in an account or organization.

Template of S3 Bucket Policy

{
  "Version": "2021-02-19",
  "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "AWS": ["arn:aws:iam::111122223333:user/Alice",
                 "arn:aws:iam::111122223333:root"]
       },
       "Action": "s3:*",
       "Resource": ["arn:aws:s3:::my_bucket",
                    "arn:aws:s3:::my_bucket/*"]
    }
  ]
}

This S3 Bucket Policy allows root account 111122223333 and IAM user Alice is allowed to perform actions on the S3 bucket (including internal data) named “my_bucket”.

Read more: Bucket policy examples – Amazon Simple Storage Service

Template of IAM Policy

{
  "Version": "2021-02-19",
  "Statement":[{
     "Effect": "Allow",
     "Action": "s3:*",
     "Resource": ["arn:aws:s3:::my_bucket",
                  "arn:aws:s3:::my_bucket/*"]
     }
  ]
}

IAM policy grants the IAM (user, group, or role) that it is tied to permission to enforce actions on the S3 bucket (including internal data) named “my_bucket”.

IAM policy can limit access to each bucket and object prefix, can refer to the actions, resources and conditions of S3 in the following link:  https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html

4.3. MFA Delete

Multi-factor authentication (MFA) Delete is a feature that adds an authentication layer to protect data and bucket from accidental deletion (versioning state of the bucket and permanent deletion of object version)

There are some notes when activating, only the root account (bucket owner) can enable the MFA Delete feature. In addition, to use MFA for versioning in the S3 bucket, you can only configure via AWS Command Line Interface (AWS CLI) or API (this API is used to configure versioning for buckets)

Amazon S3 stores the MFA Delete configuration in the same subresource versioning and is saved in bucket’s versioning status.

<VersioningConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">

  <Status>VersioningState</Status>

  <MfaDelete>MfaDeleteState</MfaDelete> 

</VersioningConfiguration>

Command to enable the MFA Delete for bucket versioning with AWS CLI:

$ aws s3api put-bucket-versioning --profile my-root-profile --bucket my-bucket-name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::00000000:mfa/root-account-mfa-device 123456”

4.4. Access Points

Access points are network endpoints attached to buckets that are used to perform operations on S3 objects, such as GetObject and PutObject.

The access point is used to share data between accounts, instead of using bucket policy in section 4.3 above. Note that the access point only acts on objects in buckets.

Viet-AWS encourages the use of Access Point for the following jobs:

• Manage shared large amounts of data

Using Access Point, you can split a large bucket policy into separate, discrete access point policies for each application that needs to access a shared data set.

This makes it simpler to focus on building the right access policy for an app, while not having to worry about disrupting any other apps that are in this data set.

• Restrict access to VPC

S3 Access Point can limit all access to S3 storage from VPC.

You can create a Service Control Policy and require all access points to be restricted to your VPC, helping to secure your data on private networks.

• Limit access to specific ID accounts

With S3 Access Points, VPC Endpoint policies can be specified, allowing access only to Access points (buckets) that are owned by specific ACCOUNT IDs.

This simplifies the creation of access policies that allow access to buckets in the same account and denies any access to any other Amazon S3 service through the Endpoint VPC.

• Provide unique names

S3 Access points enable naming of access that is unique in an account and AWS region; for example, each region/account will have 01 “TEST” access point.

Step 5: Safety for Amazon S3

5.1. Bucket versioning

From a security perspective, we recommend enabling versioning for buckets because it’s safe against tampering with or accidentally deleting encrypted data or data.

Permissions for S3 are separated between actions on objects and object versions. For example, the DeleteObject action differs from DeleteObjectVersion. This means that with the DeleteObject permission, the object can only be deleted at the current point, but not the version of the object.

5.2. S3 Object Lock

‎S3 Object Lock is an option you can enable to prevent objects from being deleted or overwritten for a fixed period of time. This is like a write-once-read-many (WORM) model and has been evaluated by various regulations to protect your data. ‎

‎This feature is recommended to protect data for a certain period of time.‎

5.3. Amazon Macie

‎Amazon Macie is a fully managed data security and data privacy service that uses machine learning techniques and sample reconciliation to detect and protect your sensitive data in AWS.‎

‎Amazon Macie automatically detects sensitive data at scale and reduces the cost of protecting your data. Macie automatically provisions Amazon S3 buckets, including a list of un-encrypted buckets, publicly accessible buckets, and buckets shared with AWS accounts outside of accounts you have defined in AWS Organizations. ‎

‎Macie then applies machine learning and sample reconciliation techniques to the buckets selected to identify and alert you to sensitive data, such as personally identifying information (PII). Macie alerts or search results can be searched or filtered in the AWS Management Console and sent to Amazon EventBridge, formerly known as Amazon CloudWatch Events, for easy integration with existing processes or event management systems, or used in combination with AWS services, like AWS Step Functions to perform automated remediation actions. ‎

Read more about Amazon Macie: https://docs.aws.amazon.com/macie/

Conclusion

‎The above are the best methods with annotations and advice from Viet-AWS team for the security of the Amazon Simple Storage Service (Amazon S3).

Reference

Security Best Practices for Amazon S3 – Amazon Simple Storage Service

How to secure Amazon S3: latest best practices (securingthe.cloud)