acquires Cloud Conformity
Open menu

Secure Transport

Cloud Conformity allows you to automate the auditing process of this resolution page. Register for a 14 day evaluation and check your compliance level for free!

Start a Free Trial Product features
Knowledge Base Best practice rules for Amazon Web Services AWS S3 Best Practices Secure Transport
Last updated: 06 February 2017
Security
Risk level: Medium (should be achieved)
Rule ID: S3-017

Ensure that your AWS S3 buckets enforce encryption of data over the network (as it travels to and from Amazon S3) using Secure Sockets Layer (SSL)

This rule can help you with the following compliance standards:

This rule can help you work with the AWS Well-Architected Framework

This rule resolution is part of the Cloud Conformity Security & Compliance tool for AWS

When S3 buckets are not configured to strictly require SSL connections, the communication between the clients (users, applications) and these buckets is vulnerable to eavesdropping and man-in-the-middle (MITM) attacks. Cloud Conformity strongly recommends enforcing SSL-only access by denying all regular, unencrypted HTTP requests to your buckets when dealing with sensitive or private data.

Audit

To determine if your Amazon S3 buckets are protecting data in transit using SSL, perform the following:

Using AWS Console

01 Sign in to the AWS Management Console.

02 Navigate to S3 dashboard at https://console.aws.amazon.com/s3/.

03 Select the S3 bucket that you want to examine and click the Properties tab from the S3 dashboard top right menu:

Properties tab from the S3 dashboard top right menu

04 Inside the Properties tab, click Permissions to expand the bucket permissions configuration panel.

05 Now click Edit bucket policy to access the bucket policy currently in use. If the selected S3 bucket does not have an access policy defined yet, skip the next step and mark the Audit process as complete.

06 Inside the Bucket Policy Editor dialog box, verify the policy document for the following elements: "Condition": { "Bool": { "aws:SecureTransport": "true" } }, when the Effect element value is set to "Allow" or "Condition": { "Bool": { "aws:SecureTransport": "false" } } when the Effect value is "Deny". This S3 policy condition will allow only SSL (encrypted) access to the objects stored on the selected bucket. If this condition is not defined within your existing bucket policy, the selected S3 bucket does not protect its data while in-transit (i.e. as it travels to and from Amazon S3).

07 Repeat steps no. 3 - 6 to verify the access policy for other S3 buckets created within your AWS account.

Using AWS CLI

01 Run list-buckets command (OSX/Linux/UNIX) using custom query filters to list all S3 buckets available in your AWS account: 

aws s3api list-buckets
    --query 'Buckets[*].Name'

02 The command output should return the names of your S3 buckets, e.g: 

[
    "cc-media-repo",
    "cc-webapp-assets",
]

03 Run get-bucket-policy command (OSX/Linux/UNIX) to retrieve the bucket policy defined for selected bucket and copy its content to a JSON file named s3-access-policy.json (the command does not return an output): 

aws s3api get-bucket-policy
    --bucket cc-media-repo
    --query Policy
    --output text > s3-access-policy.json

04 The command should respond with one of the following:

  1. If the selected S3 bucket does not have an access policy currently in use the response should be an NoSuchBucketPolicy error, i.e: 
    An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist
  2. If the selected S3 bucket does have an access policy defined, the command will not produce an output in your terminal but it will copy the policy document to the s3-access-policy.json file. Open the policy document in your preferred editor and check it for the following elements: "Condition": { "Bool": { "aws:SecureTransport": "true" } }, if Effect is set to "Allow" or "Condition": { "Bool": { "aws:SecureTransport": "false" } }, if the Effect element value is "Deny". This policy condition will force S3 to serve content over HTTPS/SSL only and deny all regular (unencrypted) HTTP access. If this condition is not defined within your bucket policy, the selected S3 bucket does not secure its data in transit.

05 Repeat step no. 3 and 4 for each S3 bucket that you want to examine, available in your AWS account.

Remediation / Resolution

To enforce SSL-only access to your S3 buckets via access policies, perform the following actions:

Using AWS Console

01 Sign in to the AWS Management Console.

02 Navigate to S3 dashboard at https://console.aws.amazon.com/s3/.

03 Select the S3 bucket that you want to encrypt (see Audit section part I to identify the right S3 resource) and click the Properties tab from the dashboard top right menu:

Properties tab from the S3 dashboard top right menu

04 Inside the Properties tab, click Permissions to expand the bucket permissions settings panel.

05 Click the Edit bucket policy button to edit the bucket policy in use. If the selected bucket does not have an access policy defined yet, click Add bucket policy.

06 In the Bucket Policy Editor dialog box, perform one of the following actions based on your current configuration:

  1. If there is no access policy currently in use, paste the following policy document in the Bucket Policy Editor box, replace the bucket name, i.e. cc-media-repo, with the name of your own S3 bucket then click Save. This policy will restrict non-SSL S3 access to all your objects available in the selected S3 bucket: 
    {
  "Version": "2012-10-17",
  "Id": "S3SecureTransportPolicy",
  "Statement": [
    {
      "Sid": "ForceSSLOnlyAccess",
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": "s3:*",
      "Condition": {
        "Bool": { "aws:SecureTransport": false }
      },
      "Resource":"arn:aws:s3:::cc-media-repo/*"
    }
  ]
}
  2. If the selected bucket has already an access policy implemented, append the following policy statements (highlighted) to the existing ones available within the Bucket Policy Editor box, as shown in the following example: 
    {
  "Id": "S3BucketAccessPolicy",
  "Version": "2012-10-17",
  "Statement": [
    {

      ...

    },
    {
      "Sid": "ForceSSLOnlyAccess",
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": "s3:*",
      "Condition": {
        "Bool": { "aws:SecureTransport": false }
      },
      "Resource":"arn:aws:s3:::cc-media-repo/*"
    }
  ]
}

    Replace the bucket name, i.e. cc-media-repo, with the name of your own bucket then click the Save button to apply the permissions changes. This policy will restrict non-SSL access to all your S3 objects stored within the selected S3 bucket.

07 Repeat steps no. 3 - 6 to implement SSL-only access for other S3 buckets created in your AWS account.

Using AWS CLI

01 Define the access policy that will enforce SSL-only (encrypted) access to your S3 data. Paste the following policy document in a JSON file named ssl-only-access-policy.json, replace the bucket name, i.e. cc-media-repo, with the name of your bucket then save the file. If your bucket has already an access policy implemented, append only the highlighted block to the existing policy Statement element: 

{
  "Version": "2012-10-17",
  "Id": "S3SecureTransportPolicy",
  "Statement": [
    {
      "Sid": "ForceSSLOnlyAccess",
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": "s3:*",
      "Condition": {
        "Bool": { "aws:SecureTransport": false }
      },
      "Resource":"arn:aws:s3:::cc-media-repo/*"
    }
  ]
}

02 Run put-bucket-policy command (OSX/Linux/UNIX) to attach the access policy created at the previous step, i.e. ssl-only-access-policy.json, to the selected S3 bucket (the command does not produce an output): 

aws s3api put-bucket-policy
    --bucket cc-media-repo
    --policy file://ssl-only-access-policy.json

03 Repeat step no. 1 and 2 to enforce SSL-only access for other S3 buckets available in your AWS account.

References

Publication date Feb 6, 2017

Related S3 rules

Thanks!

A verification email has been sent to

Thanks!

A verification email has been sent to

Thanks!

A verification email has been sent to