AWS S3 buckets are the destination for much of the data moving to the cloud. This service, and similar services in other cloud providers such as Azure Storage Blobs, enable organizations of any size or industry to store large troves of data for websites, mobile applications, and whatever else the business requires.
Many recent news articles highlight how S3 buckets have been left open to public access. The cause? Misconfigurations and poor visibility—which are some of the most common security weaknesses.
Recent AWS S3 bucket data breaches
In the past year, there have been several data breach reports about Amazon S3 in particular. The cause of data breaches mostly came down to the misconfiguration of AWS S3 storage. In nearly all cases, S3 buckets had been mistakenly configured to allow "public" access. In effect, this meant that anyone with a link to the S3 server could access, view, or download its content. The most recent data breaches that occurred via S3 Buckets were:
AWS S3 data storage - shared responsibility model
Security is a shared responsibility between the cloud provider and the customer. AWS is responsible for the “security of the cloud,” whereas organizations are responsible for “security in the cloud.” This means that while AWS is responsible for the security of the infrastructure and the S3 service, the security of data in the S3 bucket is the responsibility of the organizations utilizing the S3 bucket services.
Understanding and internalizing the shared responsibility model is essential to avoid incorrect assumptions that can lead to breaches. Administrators often assume that S3 is inherently secure simply because it runs on AWS. Although most cloud storage services have built-in security features, the configuration of these and the protection of the stored data ultimately lies with the organizations.
AWS S3 bucket misconfigurations
S3 bucket misconfiguration is a big problem. AWS S3 buckets configurations are complex and can be misconfigured or left accessible to the public internet, leaving sensitive data vulnerable to a breach event. A misconfigured S3 bucket allowing public write access can be used to serve or control malware, damage a website hosted in S3, store any amount of data at your expense, and even encrypt files to demand a ransom.
The risk of overprivileged IAM roles
Data in Amazon S3 can be vulnerable without proper access policies. Misconfiguration, along with human and non-human identities with excessive high-risk permissions, enables a threat actor to steal sensitive data, often without an organization’s awareness. Recent breaches show that attackers are exploiting mismanaged IAM privileges to penetrate an organization’s cloud infrastructure to reach sensitive data. A classic example is the Capital One breach in which a hacker compromised a WAF service and utilized the EC2 host permissions to access the S3 bucket which resulted in the exposure of 30GB of sensitive PII data exposed, impacting more than 100M customers in the US and Canada. It's important to note that, unlike many other high-profile AWS breaches, the Capital One S3 buckets were not left externally exposed to the internet. To strengthen security posture against such risks, organizations need full visibility into the identities that have access to S3 resources, understanding of any associated risk, and remediation capabilities to mitigate risk quickly.
Threats and vulnerabilities
As data increasingly moves to the cloud, platforms like AWS S3 services become an attractive target for attackers. Unsecured buckets make it easy for threat actors to steal data and obstruct operations. Over time, storage can become contaminated with malware, ransomware, and other threats. Ensuring stored data is free from malware that can spread across cloud environments is essential yet often overlooked by organizations.
Data security and compliance is a never-ending task. Organizations with S3 resources need to comply with the applicable compliance and security policies. It is challenging to get a comprehensive picture of security and compliance risks by running checks against AWS S3 configuration best practices and compliance standards, including PCI-DSS, HIPAA, NIST-800-53, and more. What is needed is an automated compliance framework that allows an organization to ensure compliance requirements are being met globally, no matter where that data is stored, transmitted, or accessed.
Securing AWS S3 buckets
Protecting S3 buckets and AWS accounts is essential – a compromise of either one can spell disaster. Fortunately, there are several actionable steps that users can take to bolster the security of AWS S3 storage. The below checklist addresses a few foundational Amazon S3 security best practices to consider as organizations develop and implement their own security policies.
Maintaining AWS S3 access control
Bucket policies and access control lists (ACLs) are the foundation of Amazon S3 security. It is essential to know who has access to sensitive data and what they’re doing with that access. Configuration of these policies and lists determines the accessibility of objects within Amazon S3, and it is important to audit them regularly to properly secure and maintain the security of your Amazon S3 bucket.
Classifying and securing sensitive data
Identification and classification of sensitive data is a crucial aspect of compliance, governance, and security. Organizations need to have constant visibility of all Amazon S3 resources to assess their security posture and take action on potential areas of weakness. Notifications and alerts are necessary for unprotected sensitive data.
Identifying and remediating critical misconfigurations
It is important to monitor the configuration changes of S3 buckets, whether the changes are intentional or accidental. Also, it is necessary to discover and remediate known and unknown security risks and threats to keep cloud storage clean.
Defining the least privileged access
By limiting administrator access and aligning permission grants to the appropriate level of authority, organizations can minimize the risks of allowing too many users with administrator-level permissions. It is essential to:
Using encryption to secure AWS S3 Data
Enable server-side encryption on AWS to encrypt data at rest (i.e. when objects are written) and decrypt when data is read. SSL in transport helps secure data in transit when it is accessed from S3 buckets.
Enforcing consistent data protection policies
Ensure consistent data protection and internal policy compliance across the organization – including networks, clouds, and users.
Scanning storage for possible malicious objects
Ensure that every single file that is uploaded to S3 buckets is being scanned by a malware engine before or right after it is stored in the bucket. This will help avoid malware landing in S3 storage and impacting downstream workflows or being redirected to customer or external sources and web pages.
Using 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 and accidental issues.
Enabling MFA delete
The “S3 Bucket” can be deleted by the user even if he/she does not log in using MFA by default. It is highly recommended that only users authenticated using MFA have the ability to delete buckets. Using MFA to protect against accidental or intentional deletion of objects in S3 buckets will add an extra layer of security.
Access and activity logging
If the S3 buckets have the server access logging feature enabled, IT teams will be able to track every request made to access the bucket. This will allow the IT teams the ability to monitor activity, detect anomalies and protect against unauthorized access.
Regularly auditing and monitoring S3 policy changes
AWS CloudTrail provides logs for all changes to S3 policy. The auditing of policies and checking for public buckets help, but instead of waiting for regular audits, any change to the policy of existing buckets should be monitored in real-time.
*The checklist of best practices are general guidelines and don’t represent a complete security solution because these best practices might not be appropriate or sufficient.
The breaches discussed above are a clear indication that organizations are struggling to configure, monitor, and enforce the least privileges to secure AWS S3 sensitive data. It is imperative to consider the AWS shared responsibility model and to understand your security responsibilities with AWS S3 storage services. Based on this model, you can use AWS-native tools, or you can find a third-party solution that is tightly integrated with the AWS platform to provide the automation and visibility required to appropriately manage AWS S3 data security. By following the above best practices and guidelines, organizations can protect their sensitive data in AWS S3 storage.
Securing AWS S3 sensitive data can be challenging. The simpler it is to create S3 buckets, the easier it is to make mistakes that can lead to security threats that end up exposing sensitive data to the internet. Zscaler Workload Posture can simplify the process of monitoring and protecting AWS S3 buckets as well as other resources in the AWS ecosystem. It can continuously discover and help automatically protect sensitive cloud data at the scale and speed. With Zscaler Workload Posture, organizations can protect their AWS S3 buckets from misconfigurations, misuse, attacks, threats, and data loss. This includes:
Learn more about the secure approach for protecting sensitive data in AWS S3 storage using Zscaler Workload Posture in this video by Max Shirshov, Cloud Security Sales Specialist, Zscaler.
Find out more about workload posture or schedule a free AWS S3 Storage Security and Compliance Assessment to get a handle on your AWS platform security posture and learn how Zscaler Workload Posture can help.