Personal Data is licensed by CC0 1.0 Public Domain.
Imagine some of your most sensitive files suddenly appearing in a Google search result. Unfortunately, this is a very common problem for many organizations, due to cloud misconfigurations resulting in public data exposure.
Public data exposure is one of the most common cloud misconfigurations, with 38% of organizations in 2024 having at least one publicly exposed workload. Attackers actively seek out exposed data from AWS using automated tools, making it critical to audit and secure your resources against this common error.
In our sixth installment on the Top 10 Security Issues for AWS, we’ll discuss the #6 priority for securing your AWS accounts: auditing for public data exposure. This series highlights the most common security issues we at Cloud Security Partners have seen in our customers’ AWS accounts, and how to best address them.
Dangers of Public Data Exposure
Public data exposure is one of the most dangerous cloud misconfiguration vulnerabilities for a few reasons:
- It is easy to misconfigure.
- Setting up proper least privilege permissions can be difficult, so it is very common to have several misconfigured IAM policies.
- It is easy to detect by attackers.
- Attackers continuously monitor public endpoints for newly exposed resources. Tools like S3Scanner and BucketLoot are continuously run against all AWS infrastructure.
- With the average detection and containment time for an incident being 241 days, this can allow attackers ample time to find and exploit misconfigurations.
- The data exposed can be used for future attacks.
- Internal data often contains customer records, internal design architectures, or other highly sensitive information. Attackers can utilize this data to gain a further foothold in your environment.
Common Misconfiguration Mistakes
The main difficulty of auditing an environment for public data exposure is scale; the average AWS organization has many resources and many more IAM policies. As such, it is important to target your audit to a few key areas:
- Commonly exposed resources
The most commonly exposed resources within an AWS environment are S3 buckets. However, other resources like EBS, message queues such as SNS and SQS, databases such as Redshift and RDS, and the EKS control plane are also commonly misconfigured.
EC2 instances and Lambdas are also commonly vulnerable due to overly permissive network settings.
- Commonly misconfigured settings and policies
Most misconfigurations follow a few common patterns.
Cross-account IAM roles that are too broad, such as those containing wildcard policies * for the principal, are one of the most common mistakes. Similarly, the network rules for EC2 and Lambda functions should be audited. Security groups that allow 0.0.0.0 on port 22 or 3389, or other unauthenticated endpoints, should be scrutinized.
Auditing Your Resource Permissions
AWS offers several tools to make it simpler and quicker to find misconfigured roles:
- IAM Access Analyzer
The External Access Analyzer feature within IAM Access Analyzer allows you to find cross-account IAM roles quickly. This enables you to quickly understand what data, workloads, and resources can be accessed by users from outside your AWS environment. Using this information, you can focus your efforts on particular resources.
IAM Access Analyzer is the most important tool for auditing access, and should be the first step in any cloud permissions audit.
- AWS Config
AWS Config is a tool that tracks configuration changes and assesses compliance against configured rules. AWS Config can be used to detect real-time changes and alert if any new public S3 buckets are created within your environment.
AWS Config rules like s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited should be enabled to audit S3 bucket policies.
- Amazon Inspector
Amazon Inspector is a vulnerability management service that can automatically scan EC2 and Lambda functions. It generates security findings if it detects unintended network exposure, which also helps detect workloads that are exposed publicly.
Prevent Public Data Exposure
While the tools above help identify data exposure reactively, proactive security measures strengthen your security posture to prevent any new vulnerabilities.
To close the loop on publicly exposed data, a few key AWS security features should be enabled:
- S3 Block Public Access
The quickest way to secure your environment is to enable the S3 Block Public Access feature. This allows you to set the access control to all S3 buckets within your environment in one centralized setting.
S3 Block Public Access has four settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. BlockPublicAcls and BlockPublicPolicy are preventative measures that prevent new buckets from being created with public permissions. IgnorePublicAcls and RestrictPublicBuckets are overrides that rewrite permissions for all existing buckets. All four settings should be enabled in your AWS environment.
The Block Public Access setting should not be turned off for any buckets. If the content of an S3 bucket is to be shared publicly, use Amazon CloudFront with Origin Access Control instead. This ensures that content is readable, but with secure settings on the S3 bucket.
- Service Control Policies
Service Control Policies (SCPs) are a way to define the maximum permissions possible within your AWS environment. These ensure that safe default settings are “locked” into place and cannot be overridden by unauthorized users.
Service Control Policies should be set at the AWS Organization level to ensure safe settings are never overridden, and to block the creation of new, insecure resources.
A sample Service Control Policy to lock S3 Block Public Access in place is as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforceS3BPA",
"Effect": "Deny",
"Action": [
"s3:PutAccountPublicAccessBlock",
"s3:DeleteAccountPublicAccessBlock"
],
"Resource": "*"
}
]
}
- Use Infrastructure as Code
Infrastructure as Code, like Terraform and CloudFormation, can be used to detect resource configurations before they’re created. This allows cloud configuration changes to be linted and scanned before non-compliant resources are created.
Tools like tfsec and cfn-lint are the best tools for scanning for over-permissioned resources, with a default ruleset that scans for public data misconfigurations.
Checklist for Eliminating Public Data Exposure
- Run AWS IAM Access Analyzer
- The External IAM Access Analyzer feature should be run to understand what external users have access to your data
- All key resources are audited
- S3 Buckets
- Ensure that public read/write is not enabled for any S3 buckets unless there is a specific, documented need.
- Set all four settings on the S3 Block Public Access feature
- Databases (Redshift, RDS, etc.)
- Verify that database instances are deployed in a private subnet and are not accessible from the public internet.
- AWS SNS and SQS
- Make sure Simple Notification Service (SNS) topics and Simple Queue Service (SQS) queues are not exposed to public or overly broad principals. Permissions should be restricted only to roles and users who require access.
- EKS
- Confirm that the EKS control plane is not exposed to the public internet
- Lambdas and EC2 Instances
- Confirm that Security Groups are properly set to prevent unauthorized public access to any workloads.
- S3 Buckets
- Create AWS Config Rules
- s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited are enabled
- Other AWS Managed and custom rules are enabled for each resource
- Service Control Policies are created
- An SCP to lock S3 Block Public Access settings is enabled
- SCPs for preventing the creation of other non-compliant resources are created
Conclusion
Publicly exposed data is one of the most common cloud misconfigurations in AWS, with potentially dire consequences. Attackers have automated tools that actively scan for data and workload exposure, which may give them further footholds into your AWS environment. However, tools like IAM Access Analyzer, Amazon Inspector, and security features like S3 Block Public Access and Service Control Policies help you stay a step ahead of attackers and ensure all resources are securely administered.
This post is the sixth in our series on the AWS Top 10 Security Risks: each installment will dive deeper into the most common risks we see across customer environments and how to fix them. Stay tuned for the next blog, and if you’d like expert help evaluating your cloud security, reach out to Cloud Security Partners for a comprehensive assessment of your AWS environment.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
