Establish S3 bucket security with proper access control

Create an S3 bucket

To start, you need an AWS administrator account. Log in with that account and go to the S3 console. This is where all the S3 GUI-based configurations take place. The first step is to select the Create Bucket link, which opens a new configuration page. Give the bucket a name and select the desired AWS Region.

A set of rules governs bucket naming conventions, including restrictions around character counts and types. Bucket names must be globally unique, so your first choices may not be available. Consider who will need to access the data in your S3 bucket and choose the most appropriate Region for it.

S3 buckets are set to deny all public access by default. When an S3 bucket blocks public access, this means it is only available inside your own Amazon environment.

In the past, cloud users could easily open the bucket to the world -- intentionally or not. AWS designed S3 security with the assumption that the administrator understood how S3 bucket access worked. AWS also assumed an IT team wouldn't just open all the access controls as it troubleshooted an issue in S3.

As a result, a number of high-profile incidents left sensitive data and user credentials exposed. This data could have been stolen, or the credentials could have been used to make changes within an organization's AWS environments.

AWS has since made it more difficult to open S3 buckets access accidentally or without understanding the risks. To ensure your data is secure when creating an S3 bucket, leave all the other settings as default and click Create Bucket.

Establish access control and permissions

In order to open access to your S3 bucket, apply an AWS Identity and Access Management (IAM) or bucket policy, or set up an access control list (ACL).

Each bucket has a policy, specifically a JSON document, that defines who can see and interact with the data in the bucket, as well as the rights those individuals have. Here's an example taken from AWS documentation:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "statement1",
         "Effect": "Allow",
         "Principal": {
            "AWS": "arn:aws:iam::AccountA-ID:user/Dave"
         },
         "Action": [
            "s3:GetBucketLocation",
            "s3:ListBucket"
         ],
         "Resource": [
            "arn:aws:s3:::examplebucket"
         ]
      },
      {
         "Sid": "statement2",
         "Effect": "Allow",
         "Principal": {
            "AWS": "arn:aws:iam::AccountA-ID:user/Dave"
         },
         "Action": [
             "s3:GetObject"
         ],
         "Resource": [
            "arn:aws:s3:::examplebucket/*"
         ]
      }
   ]
}

Sid is short for statement ID, and it describes the effect -- allow or deny -- and the principal that identifies the identity of the user or application to which the policy pertains.

These bucket policies might look a bit grizzly, but if you navigate to the Bucket Policy screen, you will see a policy generator near the bottom. This can be used to create these entries and copy and paste as needed.

Alternatively, navigate down the page to the Add account section of the page to create an ACL. Here the administrator can enter specific AWS accounts and apply the appropriate permissions.

An ACL details the users or groups that have access to the S3 bucket and specifies the rights and permissions granted to each of those individuals or groups. You will need the users' unique account identifiers to grant them access. Enter the account identifiers and click Update. This will open access to the designated accounts.

Even though we are opening the bucket to other internal accounts, it is still not publicly accessible. This is ideal for organizations that share large sensitive files.

Once you've added an account, you need to select the appropriate access settings. For example, if the S3 bucket is being used to distribute a large file, select the List and Read options if you want to allow the account to see and read the file but not change anything.

At this point, public access to the bucket is still denied. Only the AWS accounts specified in the ACL will be able to see or access the bucket. Account access will differ depending on what permissions were selected for that account.

To maintain security, do not change the public access without understanding the potential security implications.

Decide how you want users to access S3

S3 doesn't have a standard HTTP interface, but there are a handful of access options. The most straightforward one is the S3 GUI, which is built into the AWS website and free to use. Depending on a user's access rights, they can upload and download files as required through the standard S3 URL.

Other options include the use of File Transfer Protocol (FTP) clients or a Secure File Transfer Protocol (SFTP) server service. The AWS Transfer Family supports file transfers with FTP, SFTP and File Transfer Protocol over SSL.  

Experiment with S3 bucket access options until you understand the complexities and be careful with what you place in the bucket.

Avoid common S3 bucket security mistakes

Typical S3 security failures occur when cloud admins open public access but neglect to grant the appropriate rights. For example, if you were using S3 to host your documentation and how-to videos, there is no need to grant anything other than the Read rights for public access. Expanded access would allow people to upload and make changes in your bucket, which you obviously wouldn't want.

Most S3 usage is back-end hosting for files. Unless there is an absolutely compelling reason, the browse and write capabilities should not be allowed, since most of these documents and videos will be presented in a webpage -- i.e. serving the files through an HTML page.

It all depends on the predicted usage, but IT teams should tread with caution when making S3 access choices.