Amazon Web Services (AWS) isn’t the novelty it was a decade ago. Resource-intensive, computer-heavy work today flows upward from giant enterprises 24/7 to the nebulous cloud where its processed by virtual servers, stored in digital containers, and eventually returned in a manner that supports the bottom line of tens of thousands of businesses.
AWS is Indispensable to BusinessAWS is an indispensable part of business strategy for companies worldwide that make use of its infrastructure, platform, and software services. For example, giant pharmaceuticals slice into the time it takes to complete clinical trials on billion-dollar drugs by spinning up instance after instance on the AWS platform. Financial services organizations―including NASDAQ―host solutions on AWS that keep data secure and available while maintaining compliance with stringent industry regulations. Hundreds of other organizations store and share data through AWS, allowing not only insiders to collaborate safely on projects, but also business partners, vendors, and contractors.
AWS Security is a Shared ResponsibilitySecurity is no longer the barrier to adoption it once was with the cloud; gone is the hesitancy of sending business-critical data off to the cloud to have it handled by third parties. Yet that doesn’t relieve organizations from the responsibility of putting controls around their information and limiting access to it. Amazon may keep its data centers safe and the physical servers hosting millions and millions of virtual servers secure from hackers, but the onus on protecting data rests squarely on the AWS user’s shoulders. This is the essence of Amazon’s Shared Responsibility Model where it protects the infrastructure running its services while the customer is responsible for secure configurations of Elastic Compute Cloud EC2, for example, Amazon’s infrastructure as a service offering.
This guide provides a brief introduction to securing Amazon Web Services installations, looking specifically at Amazon Simple Storage Service (S3), Elastic Compute Cloud (EC2), Identity and Access Management (IAM), and its Relational Database Service (RDS), the risks associated with each, and security best practices that should be followed to ensure the integrity of business data moving through each service.
Simple S3 Access Configuration Mistake
Amazon Simple Storage Service, better known as S3, is one of the most popular abstracted AWS services, providing users with almost infinite storage and collaboration capabilities. For all of its convenience and efficiency, it’s also one place where a whole lot of good can be undone by one simple mistake.
Massive S3 leaks have resulted in uncomfortable headlines for many companies, including some of the world’s largest businesses, such as telecommunications giant Verizon and global management and consulting firm Accenture.
A Verizon partner failed to properly secure an S3 bucket and leaked personal information belonging to tens of millions of customers, while Accenture suffered what could have been a catastrophic leak of private encryption keys that could have been used to unlock private data for customers around the world.
Avoid Access Configuration MistakesSimple mistakes, such as changing the default access configuration for an S3 bucket from private to public, were behind many of the leaks and forced organizations to re-evaluate the security of these installations and how to move forward. The scope of the risk posed by each leak is immeasurable. In each case, it’s difficult to tell whether any of the data had been accessed or downloaded before the researchers stumbled upon it. Unless logging and other tracking had been turned on, it’s nearly impossible to tell whether the exposed data had fallen into a malicious party’s hands. Another commonality is that in many cases, a third party was responsible for the exposure. Data had been shared with a vendor, business partner, or contractor who needed a particular data set for a project and uploaded it to Amazon S3 without proper security controls in place, largely for the sake of convenience and sharing among colleagues.
Amazon recommends that administrators provision access based on the principle of least privilege. AWS makes four routes available to users for access provisioning:
Route #1 Identity and Access Management Policies (IAM)Because of its ability to centrally manage access, IAM provides administrators with the strongest controls. It’s advised to specify permissions in a policy, attach the policy to a group, and place users into groups to provide them with permissions. Policies should never directly apply to users because this would conflate management as the Amazon Web Services environment grows relative to its organization. In addition, use AWS managed policies rather than creating new ones. Many AWS managed policies exist that are intended to provide organizational roles with access according to the principle of least privilege.
Illustration 1 Unscalable way to apply permissions at the user level
Illustration 2 Advised way to specify permissions at the group level
Route #2 Bucket Access Control Lists (ACL) for S3 BucketsACLs grant the Amazon S3 Log Delivery group write-access to the bucket. To have Amazon S3 deliver access logs to a user’s bucket, an admin will need to grant write permission on the bucket to the Log Delivery group. The only way to grant necessary permissions to the Log Delivery group is via a bucket ACL.
Route #3 Bucket PoliciesA bucket policy is applied to a bucket rather than a user or group, unlike an identity and access management policy. A bucket policy can be used to provide bucket access for another AWS account; IAM policies do not allow for cross-account access.
Route #4 Objects Access Control List (AC)Objects ACL for objects stored in a S3 bucket may also grant cross-account access to objects rather than buckets. Object ACLs should be used if access permissions need to vary between objects in a bucket in situations where cross-account access is required.
Avoid Control Configuration MistakesAdmins may also struggle with S3 controls known as Everyone and Authenticated User groups, which are quite similar despite their disparate names. Many newsworthy data leaks can be traced back to misconfigurations here, so it’s advisable to proceed with caution. The confusion arises because the Authenticated User includes anyone authenticated to any AWS account, and not just an organizational AWS bucket. In other words, there is little difference between the “Everyone” and the “Authenticated Users” group because anyone can sign up for a free AWS account.
If an S3 bucket is accessible to “Authenticated Users,” all that someone needs to do is sign into their personal account and AWS will provide access to the S3 bucket objects. Alternatively, S3 buckets configured to grant access to the “Everyone” and the “Authenticated Users” groups can easily be accessed by an attacker via the AWS command line interface.
Illustration 3 Authenticated User groups and Everyone groups are similar
The ABCs of EC2 Security
Another popular AWS service is Amazon Elastic Compute Cloud (EC2). EC2 is the web service that allows for users and organizations to spin up virtual servers called instances, which are configured through Amazon Machine Images (AMI) to run applications at scale. It’s a utility pricing-based model where a c