Preventing Cloud Storage Exposure

How Storage Exposure Happens

Cloud object storage is the most common source of data breaches in cloud environments. The pattern is always the same: a storage resource that should be private is accidentally configured as public, and an attacker discovers it through automated scanning. The breach is not sophisticated — it's a misconfiguration.

The anatomy of a public bucket exposure

Object storage services (S3, Azure Blob, GCS) are designed to support both public and private access. The service works correctly — the customer configures it incorrectly. Here's how it happens:

1. A developer creates a bucket for application data
2. The bucket inherits a permissive default or the developer adds a policy to allow public access for testing
3. The public access is never removed — it gets forgotten in the rush to production
4. An attacker runs a scanner that checks known bucket names for public access
5. Data is exfiltrated — often within hours of the bucket being created

# Checking if a bucket is publicly accessible
aws s3api get-bucket-acl --bucket my-app-data
aws s3api get-bucket-policy --bucket my-app-data

# Checking block public access settings
aws s3api get-public-access-block --bucket my-app-data

The four layers of storage access control

Object storage has multiple layers of access control, and a bucket is public if any layer allows it:

1. Bucket ACLs — legacy access control lists that can grant public-read or public-read-write
2. Bucket policies — JSON policies that can grant Principal: "*" (anonymous access)
3. Access Control Lists (ACLs) on individual objects — can override bucket-level settings
4. Account-level Block Public Access — a guardrail that overrides all of the above

A bucket is only truly private if all four layers are configured correctly. This is why exposure happens — teams fix one layer but miss another.

Real-world impact

Storage exposure breaches have affected major companies:

• Verizon (2017): A third-party contractor left an S3 bucket public, exposing 14 million customer records
• Accenture (2017): Four unsecured S3 buckets exposed secret AWS keys and customer data
• Booz Allen Hamilton (2019): A public S3 bucket exposed classified data from the U.S. National Reconnaissance Office

The common thread: none of these were sophisticated attacks. They were misconfigurations that automated scanners found within hours.

The default-deny principle

The fundamental rule of cloud storage security: object storage should be private by default. Access should be granted through:

• Signed URLs — time-limited, cryptographically signed URLs that grant temporary access to specific objects
• Pre-signed POST policies — allow clients to upload directly to storage without exposing the bucket
• CloudFront signed URLs/cookies — for content delivery with access control
• IAM-authenticated access — applications access storage through authenticated API calls

# Generating a pre-signed URL for temporary read access (boto3)
import boto3

s3 = boto3.client('s3')
url = s3.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'my-app-data', 'Key': 'reports/2026-q3.pdf'},
    ExpiresIn=3600  # URL expires in 1 hour
)
print(url)
# https://my-app-data.s3.amazonaws.com/reports/2026-q3.pdf?X-Amz-Algorithm=...&X-Amz-Expires=3600&X-Amz-Signature=...

The signed URL grants access to one specific object for a limited time. The bucket itself remains private. This is the correct pattern for sharing data from object storage.

Guardrails and Automated Detection

Relying on developers to correctly configure storage access every time is a losing strategy. The solution is to implement guardrails that prevent exposure before it happens, and automated detection that catches it when guardrails fail.

Account-level Block Public Access

All major cloud providers offer account-level settings that override any bucket-level public access configuration:

AWS S3 Block Public Access:

# Enable all four block public access settings at the account level
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

The four settings:

• BlockPublicAcls: Rejects any new public ACL on a bucket or object
• IgnorePublicAcls: Ignores any existing public ACL (treats the bucket as private)
• BlockPublicPolicy: Rejects any bucket policy that grants public access
• RestrictPublicBuckets: Restricts access to bucket policies that grant access to the same account only

When all four are enabled, it's impossible to make a bucket public through ACLs or policies. This is the single most effective guardrail against storage exposure.

Azure Blob equivalent:

# Disable public access at the storage account level
az storage account update \
  --name mystorageaccount \
  --resource-group myResourceGroup \
  --allow-blob-public-access false

GCS equivalent:

# Enforce uniform bucket-level access
gsutil uniformbucketlevelaccess set on gs://my-bucket

Infrastructure-as-code scanning

The best time to catch a public bucket is before it's created. Scan your Terraform, CloudFormation, or Pulumi code for permissive storage configurations:

# Terraform — DANGEROUS: public-read ACL
resource "aws_s3_bucket" "data" {
  bucket = "my-app-data"
}

resource "aws_s3_bucket_acl" "data" {
  bucket = aws_s3_bucket.data.id
  acl    = "public-read"  # This will be flagged by IaC scanning
}

Tools like Checkov, tfsec, and Terrascan detect these patterns at build time:

# Checkov scan for public S3 buckets
checkov -d . --framework terraform --check CKV_AWS_20

# Output: FAILED for resource aws_s3_bucket_acl.data
# CKV_AWS_20: Ensure S3 bucket has block public ACLs enabled

Continuous posture scanning

Even with guardrails, you need continuous scanning to detect:

• Buckets that were public before guardrails were enabled
• Snapshots and AMIs that are publicly shared
• Storage accounts in subscriptions you don't actively manage

# AWS CLI: Find all public S3 buckets
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  tr '\t' '\n' | \
  while read bucket; do
    public=$(aws s3api get-public-access-block --bucket "$bucket" 2>/dev/null | \
      jq -r '.PublicAccessBlockConfiguration.BlockPublicAcls')
    if [ "$public" != "true" ]; then
      echo "WARNING: $bucket does not have BlockPublicAcls enabled"
    fi
  done

Snapshot and image exposure

It's not just storage buckets. Machine images and snapshots can also be public:

# Check for public AMIs
aws ec2 describe-images \
  --owners self \
  --query 'Images[?Public==`true`].[ImageId,Name]' \
  --output table

# Check for public snapshots
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?VolumeSize>=`8`].[SnapshotId,VolumeSize,Description]' \
  --output table

A public snapshot of a production database volume is just as dangerous as a public bucket.

The defense-in-depth approach

Effective storage exposure prevention uses multiple layers:

1. Account-level block public access — prevents new public buckets
2. IaC scanning — catches misconfigurations before deployment
3. Continuous posture scanning — detects existing public resources
4. Bucket policy conditions — even if public, restrict by IP or VPC endpoint
5. Monitoring and alerting — notify when bucket policies change

# CloudWatch Events rule to detect public bucket policy changes
import boto3
import json

# Event pattern for PutBucketPolicy
{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["PutBucketPolicy"]
  }
}

The goal is not to rely on any single control, but to create a system where exposure is prevented by default, caught early when it happens, and alerted immediately.