With a number of recent high-profile leaks of personal data on Amazon Web Services (AWS) S3 service, it seems like a good time to review the security mechanisms that govern storage and sharing of data from AWS. If your organization uses S3 for storage of PHI, PII, or other sensitive data, you should be aware that failure to properly secure and restrict access and log this information can carry hefty fines and even jail time. Leaking users’ personal data can also be detrimental to your business model. (Photo Credit: Flickr)
Require encryption for storage at rest
Encryption is your first line of defense when securing data anywhere. But how can you make sure that you always encrypt in S3? Fortunately, AWS bucket policies can enforce encryption by refusing write to the bucket if the data object lacks an encryption header.
Here’s a sample of such a policy provided by AWS:
Server-side-encryption ensures the security of your data should the physical drives ever be compromised. Using key-access policies and encrypting data with AWS managed keys, you can restrict access to the contents of data while allowing its movement, backup, or destruction.
Restrict access through IAM roles
Of course, if you encrypt with only managed keys and allow anyone to access the data and the keys, it’s still vulnerable. Odds are good that’s not what you want. The IAM service allows you to create user roles that can access the contents of stored objects, and bucket policies that limit which of those roles can access which objects.
This is particularly useful if you are sharing your customer data with other companies. Rather than simply leave the data open to everyone and hope that nobody can guess your cleverly-crafted url at https://my-super-duper-secret-data.s3.amazonaws.com/ (hint: not a real bucket), you can allow the access to that data only to specific user roles in specific AWS accounts, as detailed at the AWS Security Blog.
1. The IAM role’s user policy and the IAM users’ policy in the bucket account both grant access to “s3:*”
2. The bucket policy denies access to anyone if their user:id does not equal that of the role, and the policy defines what the role is allowed to do with the bucket.
3. The bucket policy allows access to the role from the other account.
4. The IAM user and role can access the bucket without the Deny in the bucket policy. The role can access both buckets because the Deny is only for principals whose user:id does not equal that of the role.
Understanding bucket access controls
There are three different mechanisms that control access to objects in S3: S3 bucket policies, IAM policies and S3 ACLs. It’s important to understand how these different mechanisms work together. In another post on the AWS security blog, there is an in-depth discussion of these mechanisms and their interactions, which we will not rehash here. However, there is a useful graphic from that post that illustrates how multiple policies interact to produce an “allow” or “deny” result when evaluated. (Photo Credit: AWS Security Blog)
Understanding how these mechanisms interact, and using them wisely can help make sure your data governance policies don’t become headline news.
Simple policy enforcement can prevent costly and embarrassing breaches of customer data. Don’t be caught with your data pants down, leaving unencrypted buckets open to the public. Enforce encryption of data with bucket policies, use role-based access controls to restrict your data, and understand how the different access controls interact to permit or deny access to your objects, and you won’t end up as another example link posted in the first paragraph of a blog post about data security.
Can't get enough of the Cloud? Join in the conversation and check out our other blog posts on AWS S3 here.