Configuring AWS S3: Don’t be the next bucket blunder

null

Companies are packing up their priceless data and moving to the cloud in surging numbers, all with their own hopes and dreams for making the most of the new neighbourhood’s amenities. Hackers are right behind them, casing their cloud joint, hot on the trail of whatever data loot they can grab.

Because the nature of cloud computing and storage upends traditional principles of networks and hosts, it undermines security practices that use these principles as a proxy to protect data access. In public clouds, networks and hosts are no longer the most adequate control options available for resources and data.

Amazon Web Services (AWS) S3 buckets are the destination for much of the data moving to the cloud. Given how important this sensitive data is, one would expect enterprises to pay close attention to their S3 security posture. The responsible party was a services provider for big name insurance companies. Unfortunately, many news stories highlight how many S3 buckets have been mistakenly misconfigured and left open to public access. It’s one of the most common security weaknesses in the great migration to the cloud, leaving gigabytes of data for hackers to grab.

The latest cautionary tale is every CISO’s nightmare: human error caused a bucket to be left open to the public during an upgrade migration, exposing sensitive personal and medical data for thousands of insurance policyholders. Another incident involving Los Angeles County’s 211 service, which provides referrals for health and human services issues such as abuse and suicidal distress, exposed millions of records that included case notes and employee access credentials. For an organisation that guarantees confidentiality as a central premise of its interactions, such a public breach of trust causes untold damage.

When investigating why cloud teams are making what seems to be an obvious configuration mistake, two primary reasons surfaced:

1.    Too many options leads to easy mistakes

S3 is the oldest AWS service and was available before EC2 or Identity and Access Management (IAM). Some access controls capabilities were built specifically for S3 before IAM existed. As it stands, there are five different ways to configure and manage access to S3 buckets.

  • S3 Bucket Policies
  • IAM Policies
  • Access Control Lists
  • Query string authentication/ static Web hosting
  • API access to change the S3 policies

More ways to configure may provide more flexibility, but having multiple options also increases confusion and the chances of making a mistake. Adding to the complexity, there are two separate policies — one for buckets and one for the objects within the bucket.

2.    A “user” in AWS is different from a “user” in a traditional datacentre

Amazon allows great flexibility in making sure data sharing is simple and users can easily access data across accounts or from the Internet. For traditional enterprises the concept of a “user” typically means a member of the enterprise. In AWS the definition of user is different. On an AWS account, the “Everyone” group includes all users (literally anyone on the internet) and “AWS Authenticated User” means any user with an AWS account. From a data protection perspective, that’s just as bad because anyone on the Internet can open an AWS account.

If they aren’t careful, the customer moving from traditional enterprise can easily misread the meaning of these access groups and open S3 buckets to “Everyone” or “AWS authenticated User” — essentially opening their buckets to world.

S3 Security Checklist

If you are in AWS, and using S3, here is a checklist of things you should configure to ensure your critical data is secure.

Audit for open buckets regularly: On regular intervals check for buckets that are open to the world. Malicious users can exploit these open buckets to find objects with misconfigured ACL permissions, and can then access these compromised objects.

Encrypt the data: Enable server-side encryption on AWS; it will then encrypt the data at rest (i.e. it will encrypt when objects are written and decrypt when data is read). Ideally, you should enable client side encryption as well.

Encrypt the data in transit: SSL in transport helps secure data in transit when it is accessed from S3 buckets. Enable Secure Transport in AWS to prevent man-in-the-middle attacks.

Enable bucket versioning: Ensure that your AWS S3 buckets have the versioning enabled. This will help preserve and recover changed and deleted S3 objects, which can help with ransomware attacks and accidents.

Enable MFA delete: Defaults settings allow a user to delete an "S3 Bucket" even if he/she does not login using MFA. It is highly recommended that only users authenticated using MFA have the permission to delete buckets. Using MFA to protect against accidental or intentional deletion of objects in S3 buckets adds an extra layer of security.

Enable logging: If the S3 bucket has the Server Access Logging feature enabled, you will be able to track every request made to access the bucket. This will allow you to monitor activity, detect anomalies, and protect against unauthorised access.

Monitor all S3 policy changes: AWS CloudTrail provides logs for all changes to S3 policy. The auditing of policies and checking for public buckets helps, but instead of waiting for regular audits, monitor any change to the policy of existing buckets in real time.

Track all applications accessing S3: In one attack vector, hackers create an S3 bucket in their account and send data from your account to their bucket. This reveals a limitation of network-centric security in the cloud: traffic needs to be permitted to S3, which is classified as an essential service. To prevent that scenario, you should implement IDS capabilities at the application layer and track all the applications in your environment that are accessing S3. The system should alert you if a new application or user starts accessing your S3 buckets.

Limit access to S3 buckets: Ensure that your AWS S3 buckets are configured to allow access only to specific IP addresses and authorised accounts in order to protect against unauthorised access.

Close buckets in real time:  Even a few moments of public exposure of an S3 bucket can be risky as it can result in leakage. S3 supports tags, which allows users to label buckets. Using these tags, administrators can label buckets that need to be public with a tag called “Public”. CloudTrail will alert when policy changes on a bucket and it becomes public but does not have the right tag. Users can use Lambda functions to change the permissions in real time in order to correct policies and remediate anomalous or malicious activity.

Cloud-centric security is an imperative for any organisation with digital operations or data in the cloud, and that security starts with proper configuration, monitoring, and control over access. Much has been said about the flexibility and scalability benefits of cloud compute, storage, and services — but any benefit can become a liability when oversight, control, and expertise are lacking. Don’t be another “misconfigured S3 bucket” headline, or worse, the victim of a data theft that mangles your business operations and reputation.

Cloud-centric security is an imperative for any organisation with digital operations or data in the cloud, and that security starts with proper configuration, monitoring, and control over access. Much has been said about the flexibility and scalability benefits of cloud compute, storage, and services — but any benefit can become a liability when oversight, control, and expertise are lacking. Don’t be another “misconfigured S3 bucket” headline, or worse, the victim of a data theft that mangles your business operations and reputation.

Sanjay Kalra, co-founder and CPO, Lacework
Image Credit: Gil C / Shutterstock