Securing Cloud Storage Buckets

Misconfigured object storage — AWS S3 buckets, Azure Blob containers, Google Cloud Storage buckets — remains one of the most common sources of publicly disclosed data exposure, precisely because the failure mode requires no exploit at all: a bucket left readable (or writable) to anyone on the internet is a data breach the moment a scanner finds it, not after some sophisticated attack chain. This guide covers hardening object storage across the three major providers, aligned to each provider's own CIS Foundations Benchmark and to NIST SP 800-53 Rev. 5.

Scope: AWS S3, Azure Blob Storage, and Google Cloud Storage (GCS). The underlying principles — deny public access by default, prefer policy over ACLs, encrypt everywhere, log everything, restrict by network — apply equally to any object storage service, including smaller/regional providers.

Why Storage Buckets Are a Distinct Risk Category

1. Deny Public Access by Default

Every major provider now offers an account/organization-wide switch that overrides individual bucket misconfigurations — enable it first, before reviewing anything else.

AWS S3 — Block Public Access, set at both the account level and per-bucket:

aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Azure Storage — disable "Allow Blob public access" at the storage account level:

az storage account update \
  --name mystorageaccount --resource-group myrg \
  --allow-blob-public-access false

GCS — enforce Public Access Prevention, ideally as an organization policy so it can't be disabled per-project:

gcloud storage buckets update gs://my-bucket --public-access-prevention

Org-level enforcement: constraints/storage.publicAccessPrevention.

2. Prefer Policies Over ACLs — and Disable ACLs Entirely Where Possible

Legacy ACLs (per-object, per-grantee) are difficult to audit at scale and easy to misapply. Modern practice is to disable them entirely and manage access through a single, reviewable resource policy.

AWS: Set Object Ownership to Bucket owner enforced — this disables ACLs for the bucket entirely, making the bucket policy the sole access-control mechanism:

aws s3api put-bucket-ownership-controls \
  --bucket my-bucket \
  --ownership-controls Rules=[{ObjectOwnership=BucketOwnerEnforced}]

Least-privilege bucket policy example — explicit principal, explicit actions, explicit deny for everything else (implicit by omission, reinforced by Block Public Access):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificRoleReadWrite",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/AppServiceRole" },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Azure: Use Azure RBAC role assignments (Storage Blob Data Reader/Contributor) scoped to the specific container rather than Shared Access Signatures with broad, long-lived permissions. Where SAS tokens are unavoidable, scope them narrowly and set the shortest practical expiry.

GCS: Use uniform bucket-level access (disables per-object ACLs) combined with IAM Conditions to scope grants precisely:

gcloud storage buckets update gs://my-bucket --uniform-bucket-level-access

3. Encrypt at Rest and Enforce Encryption in Transit

All three providers encrypt at rest by default today, but "default" isn't the same as "enforced and verified" — and transit encryption still needs an explicit deny rule.

To require SSE-KMS on every upload (rejecting unencrypted or wrong-key uploads) on S3, add a bucket policy statement denying s3:PutObject unless the s3:x-amz-server-side-encryption header matches your expected value.

4. Versioning, Object Lock, and Ransomware Resilience

Versioning alone protects against accidental overwrite/deletion; combined with immutability controls, it protects against a compromised identity deliberately deleting or encrypting data.

• AWS S3: Enable Versioning, then layer S3 Object Lock (Governance or Compliance mode) for a defined retention period on data that must survive a compromised-credential scenario. Enable MFA Delete on the bucket so permanently removing a version requires a second factor, not just IAM permissions.
• Azure: Enable blob versioning and configure immutable blob storage policies (time-based retention or legal hold) on containers holding data that must be tamper-proof.
• GCS: Enable Object Versioning, and apply a Bucket Lock on a retention policy so the retention period itself cannot be shortened or removed, even by a project owner.

These controls are a direct, practical mitigation against ransomware and insider-threat scenarios where the attacker has valid write/delete credentials — the point isn't preventing access, it's preventing destruction.

5. Restrict by Network, Not Just by Identity

Layer network-level controls so that even a leaked credential with valid IAM permissions can't be used from an arbitrary internet location.

AWS: Restrict bucket access to traffic through a specific VPC Endpoint via a bucket policy condition:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
  "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1a2b3c4d" } }
}

Azure: Configure Storage account firewall and virtual networks to allow access only from selected VNets/subnets or specific public IP ranges, and use Private Endpoints for traffic that should never traverse the public internet at all.

GCS: Apply VPC Service Controls to create a service perimeter around the project, preventing data exfiltration even via a valid but externally-used credential.

6. Logging, Monitoring, and Automated Drift Detection

Configuration drifts. A bucket that was correctly locked down at creation can become public again through a later, unreviewed change — automated detection is what catches that before a scanner does.

Independent of provider-native tooling, open-source multi-cloud scanners (ScoutSuite, Prowler) are worth running on a schedule as a second opinion against your own cloud-native posture tools — see Data Security Posture Management for the broader discovery-and-classification approach these fit into.

7. Cross-Account and Third-Party Access

Shared buckets accumulate trust relationships that outlive their original purpose.

• Never use a wildcard ("Principal": "*") in a bucket policy without a strong, explicit Condition narrowing it — a wildcard principal with a weak or missing condition is functionally a public bucket.
• Scope cross-account grants with aws:PrincipalOrgID (AWS) or equivalent tenant-restriction conditions so a compromised external account can't be substituted for the intended one.
• Maintain an inventory of every third party with standing bucket access (backup vendors, analytics platforms, CI/CD systems) and recertify it on the same cadence as any other third-party access review — a grant made for a since-cancelled vendor relationship is pure unmanaged risk.
• For S3 buckets fronting a CDN (static website hosting, asset delivery), prefer Origin Access Control with CloudFront over a public bucket — the bucket itself stays private; only the CDN can read it.

Hardening Checklist

CIS Foundations Benchmark Alignment

Each provider's CIS Foundations Benchmark includes a dedicated storage section covering the same core controls: block public access, encryption at rest, access logging, and versioning.

NIST SP 800-53 Rev. 5 Control Mapping

References

• AWS — Security Best Practices for Amazon S3
• AWS — Blocking Public Access to S3
• Microsoft — Security Recommendations for Blob Storage
• Google Cloud — Cloud Storage Security Best Practices
• CIS AWS Foundations Benchmark
• CIS Microsoft Azure Foundations Benchmark
• CIS Google Cloud Platform Foundation Benchmark
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls
• Encryption
• Data Security Posture Management