June 27th, 2017
Don’t be a Data Leak!
By Alex Graves

UpGuard, a company specializing in cyber security assessments, recently uncovered a data leak involving voter records for 198 million Americans totaling 1.1 TB of data. It was the largest voter leak in US history. Does this mean we should be wary of AWS and cloud products? No! It’s not a problem with AWS or S3; it’s a matter of implementing the controls that AWS provides. The shared responsibility model means we, as users, must take the necessary precautions to secure our information. Here are a few methods of securing S3 buckets and auditing AWS access that will prevent your data from becoming the next big data breach.

  1. A simple change to the S3 bucket policy will prevent any user from accessing sensitive documents. AWS gives users the ability to make buckets public or private. A private bucket will allow only authenticated entities access to its objects. These entities can be EC2 instances or services within AWS, or they can be on-premises machines. At a bare minimum, your bucket policy should be set up to allow only authorized AWS users from your account to access objects within the bucket.

  2. Enable CloudTrail from day one. CloudTrail will record every API call that’s executed in your AWS account. There is a wealth of information in these types of access logs. You’ll be able to determine who performed an action, when it occurred, and what the result was. CloudTrail logs are indispensable for security audits.

  3. Use pre-signed URLs to access S3 buckets. Often, the need arises to authenticate individuals outside of AWS to use S3. These users would include customers of your service or legacy applications that run on-prem. In these cases, it’s not too difficult to engineer the application to create a pre-signed URL that redirects the user to the appropriate S3 bucket. If you couldn’t re-engineer the application to do this, you could set up an API, using API Gateway of course, that exposes a Lambda function which generates the URL for the customer.

  4. Use a VPC Endpoint and reach your S3 via the AWS backbone. If you are concerned about applications in AWS reaching across the public internet when interacting with an S3 bucket, then I suggest you think about using a VPC Endpoint. This will allow you to create a bucket policy that only allows PUTS, LISTS, or DELETES that originate from within your VPC. The bucket policy will look as follows:

This bucket policy will deny any API call to my_secure_bucket that doesn’t originate from vpce-1a2b3c4d.

As cloud architects and developers, it is our responsibility to secure what we put in the cloud, no matter what provider we use. In the modern world of agile development and speedy, data driven decisions, it is sometimes inconvenient to employ the extra steps necessary for proper security. Security is job 0 at AWS and it should be priority 0 for AWS users as well.

If you are interested in learning more about AWS security products and tools, join us for our upcoming AWS Security Seminar, August 3 at inContact in Sandy, Utah.