Protecting AWS S3 Buckets

aws / cloud / amazon / s3 / encryption / tls / security
aws / cloud / amazon / s3 / encryption / tls / security

Managing Access to S3 Buckets

By default all Amazon resources (buckets, objects and related subresources) are private, only the resource owner (the AWS account that created it) can access the resource. To grant access to others the resource owner has to write access policy. As explained in the AWS Identity and Access Management article, these policies are either identity (or user) based or resource based.

Bucket (resource based) policy and user (identity based) policy are two of the access policy options available to grant permissions to S3 resources, they both use JSON based access policy language.

Bucket Policies

Bucket policies are limited to 20 KB in size and can be generated using the AWS Policy Generator. Here are some example policies;

This policy grants the s3:PutObject and s3:PutObjectAcl permissions to multiple AWS accounts and requires that any request for these operations include the public-read canned ACL

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddCannedAcl",
      "Effect":"Allow",
      "Principal": {"AWS": ["arn:aws:iam::111122223333:root","arn:aws:iam::444455556666:root"]},
      "Action":["s3:PutObject","s3:PutObjectAcl"],
      "Resource":["arn:aws:s3:::examplebucket/*"],
      "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}}
    }
  ]
}

This policy grants the s3:GetObject permission to any public anonymous users.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddPerm",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::examplebucket/*"]
    }
  ]
}

User Policies

Here is an example user policy that grants an IAM user the AWS account access to a bucket called examplebucket, and allow the user to add, update, and delete objects.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListAllMyBuckets"
         ],
         "Resource":"arn:aws:s3:::*"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket",
            "s3:GetBucketLocation"
         ],
         "Resource":"arn:aws:s3:::examplebucket"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:PutObjectAcl",
            "s3:GetObject",
            "s3:GetObjectAcl",
            "s3:DeleteObject"
         ],
         "Resource":"arn:aws:s3:::examplebucket/*"
      }
   ]
}

In addition to granting the s3:PutObject, s3:GetObject, and s3:DeleteObject permissions to the user, the policy also grants the s3:ListAllMyBuckets, s3:GetBucketLocation, and s3:ListBucket permissions. These are the additional permissions required by the console. Also, the s3:PutObjectAcl and the s3:GetObjectAcl actions are required to be able to copy, cut, and paste objects in the console.

There is a good Walkthrough on the AWS documentation pages on using user policies to control access to S3 buckets.

Access Control Lists (ACLs)

ACLs are one of the recourse based access policy options that can be used to manage access to S3 buckets and objects. They can be used to grant basic read/write permissions to other AWS accounts. ACLS are not as comprehensive as user or bucket policies, for example permissions can only be granted to other AWS accounts not users in the same AWS accounts. And it is not possible to explicitly deny permissions.

ACLs are suitable for specific scenarios. For example, if a bucket owner allows other AWS accounts to upload objects, permissions to these objects can only be managed using object ACL by the AWS account that owns the object.

Each bucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access. When a request is received against a resource, Amazon S3 checks the corresponding ACL to verify that the requester has the necessary access permissions.

When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource. This is shown in the following sample bucket ACL (the default object ACL has the same structure):

<?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>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xsi:type="Canonical User">
        <ID>*** Owner-Canonical-User-ID ***</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

To learn more about S3 ACLs visit the S3 ACL documentation pages

Encryption

Data can be protected while in-transit (moving to and from S3) and at rest (while stored on disks on Amazon S3 data centers).

Data in-transit can be protected by using SSL/TLS or by using client-side encryption. Data at-rest on S3 can be protected using the following options;

  • Server-Side Encryyption - Amazon S3 encrypts the objects before saving them on disks in data centres and decrypts them when they are downloaded. There are three mutually exclusive options for managing the encryption keys:
    • Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) - Each object is encrypted using AES-256 with a unique key and as an additional safeguard the key itself is encrypted with a master key that is regularly rotated. This is the most common option for Server-Side encryption with Amazon S3 buckets.
    • Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS) - Similar to SSE-S3, but with some additional benefits along with some additional charges. There are separate permissions for the use of an envelope key that provides added protection against unauthorized access of objects in S3. SSE-KMS also provides you with an audit trail of when the key was used and by whom. Additionally, the client has the option to create and manage encryption keys themselves, or use a default key that is unique to them, the service they’re using, and the region they’re working in
    • Server-Side Encryption with Customer-Provided Keys (SSE-C) - The client manages the encryption keys and Amazon S3 manages the encryption, as it writes to disks, and decryption, when the objects are accessed.
  • Client-Side Encryption - Data is encrypted on the client side and then uploaded to Amazon S3, in this case the client manages the encryption process, keys and related tools. The client can use a Client-Side Master key or an AWS KMS-Managed Customer Master key to encrypt the data. Refer to this document for more detailed information.
 
comments powered by Disqus