S3 Security: Bucket Policies and Block Public Access

The pattern shows up in every "AWS data breach" headline: a misconfigured S3 bucket exposes customer records, internal documents, or credentials. The cause is almost always the same — public access that was supposed to be private, or a bucket policy that was meant to grant one team access and accidentally granted the entire internet.

This chapter is about the four layers of S3 access control and the one default setting that protects you from the most common mistake.

The Four Access Mechanisms

S3 has four overlapping ways to control who can read or write an object:

• IAM policies — attached to users, groups, or roles. Best for granting your own employees and applications access to your buckets;
• Bucket policies — JSON documents attached to a bucket. Best for cross-account access or making a bucket publicly readable for static website hosting;
• Access Control Lists (ACLs) — a legacy mechanism that grants per-object permissions. AWS recommends disabling these for new buckets;
• Access Points — named endpoints with their own policies, useful for buckets serving many applications or accounts. For new projects, the modern guidance is simple: use IAM policies for your own access, bucket policies for cross-account or public access, and disable ACLs.

Block Public Access: The Safety Net

The single most important S3 setting is Block Public Access. By default on any new bucket, four switches are all flipped on:

• Block public ACLs;
• Ignore public ACLs;
• Block public bucket policies;
• Restrict public bucket policies. Together, these prevent any combination of settings from accidentally exposing the bucket to the internet. If someone tries to attach a policy with "Principal": "*", AWS rejects it.

Carlos's nine-day breach from the shared responsibility chapter happened because someone turned Block Public Access off "just to test something" and forgot to turn it back on. The lesson: turning it off should require a written reason and a calendar reminder to turn it back on.

Bucket Policy Anatomy

A bucket policy is a JSON document. The minimal shape:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/AnalyticsRole" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-data/*"
    }
  ]
}

Each statement has:

• Effect — Allow or Deny. Deny always wins;
• Principal — who. An IAM role ARN, an account ID, or * for "anyone";
• Action — what they can do. s3:GetObject, s3:PutObject, s3:*;
• Resource — which bucket or objects. Note the /* for objects inside the bucket vs the bucket itself;
• Condition — optional extras like "only from this VPC" or "only over HTTPS". The condition block is where mature teams add their own safety: requiring HTTPS, restricting to specific IP ranges, or denying anything not encrypted.

Encryption at Rest

Every S3 bucket now encrypts objects by default with SSE-S3 (S3-managed keys). You can upgrade to:

• SSE-KMS — encryption using AWS KMS keys. Lets you audit who decrypted what via CloudTrail, and rotate keys on a schedule;
• SSE-C — you provide the key on every request. Rare;
• Client-side encryption — encrypt before uploading, AWS never sees the plaintext. For most workloads, SSE-KMS with a customer-managed key strikes the right balance — encrypted at rest with a clear audit trail.

A Real-World Hardening Checklist

A production-ready S3 bucket has:

• Block Public Access on, all four switches;
• A bucket policy that denies requests without aws:SecureTransport: true (forcing HTTPS);
• Default encryption set to SSE-KMS with a customer-managed key;
• Versioning enabled, with MFA Delete on the most critical buckets;
• Server access logging or CloudTrail data events on, written to a separate bucket;
• A lifecycle rule that cleans up incomplete multipart uploads after 7 days. Six switches. The companies that flip all six rarely show up in breach headlines.