Securing Amazon S3: — How to Never Be the Next Public-Bucket Breach

① Why S3 leaks happen — the four access layers

Sneha is an L1 cloud engineer at Infosys. A teammate needs to share a few report files from an S3 bucket with a partner, gets frustrated by permissions, finds a Stack Overflow answer, and pastes a bucket policy with "Principal": "*". It works — the partner can read the files. It also means anyone on the internet can read them, including the customer PII sitting next to those reports. That one line is the shape of almost every S3 bucket breach you've read about.

Here's the reassuring part first: in S3, buckets and objects are private by default. A brand-new bucket grants access to nobody but the owner. Leaks happen because a human deliberately (or accidentally) opens one of four access layers. Understanding those four — and the order S3 checks them in — is the whole game.

Layer one is Block Public Access (BPA) — the master safety switch at the account and bucket level. Layer two is the bucket policy, a JSON document attached to the bucket. Layer three is ACLs — the legacy model AWS now tells you to switch off. Layer four is IAM identity policies attached to your users and roles.

These layers don't vote politely — they stack. The dangerous combination is simple: if BPA is OFF and a bucket policy (or an old ACL) grants AllUsers read, the bucket is public, full stop. AWS considers an ACL public the moment it grants any permission to the predefined AllUsers or AuthenticatedUsers groups, and considers a bucket policy public if it allows a wildcard principal with no condition that pins it to a fixed account, IP range or VPC. Block Public Access exists precisely to catch these mistakes — it overrides the policy or ACL and rejects the request, regardless of what the policy says.

The four layers, one tap each

Tap each card — every S3-security interview and the SCS-C02 exam starts from these four and the order they're evaluated.

② Block Public Access + Ownership — the master switch

Now the controls. Block Public Access is four independent settings you can mix in any combination. You almost always want all four ON, and you want them ON at the account level so they apply to every current and future bucket — AWS Security Hub control S3.8 checks exactly this.

The four settings, in plain words. BlockPublicAcls rejects any new request that tries to attach a public ACL. IgnorePublicAcls makes S3 ignore every public ACL that already exists. BlockPublicPolicy rejects any attempt to attach a bucket policy that would grant public access. RestrictPublicBuckets limits a bucket that already has a public policy to AWS service principals and the owner account only. The first two are about ACLs; the last two are about policies — together they cover both leak paths.

Layer two of this section is S3 Object Ownership. Set it to Bucket owner enforced and ACLs are disabled entirely — the bucket owner automatically owns every object and you control everything with policies, not ACLs. Since April 2023, new buckets are created with this setting by default. With ACLs disabled, a PutObject that tries to set a custom ACL fails with AccessControlListNotSupported — which is good: it means nobody can sneak a public grant in through an ACL again.

aws s3api put-public-access-block \
  --bucket tcs-payroll-prod \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-ownership-controls \
  --bucket tcs-payroll-prod \
  --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

# (both commands return no output on success — exit code 0)
$ aws s3api get-public-access-block --bucket tcs-payroll-prod \
    --query PublicAccessBlockConfiguration
{
    "BlockPublicAcls": true, "IgnorePublicAcls": true,
    "BlockPublicPolicy": true, "RestrictPublicBuckets": true
}

③ Encryption + data protection — at rest, in transit, immutable

Public access controls decide who can reach the data; encryption decides who can read it if they get the bytes, and immutability decides whether they can destroy it. Start with at-rest. S3 gives you three server-side options. SSE-S3 uses an AES-256 key AWS owns — free, zero config. SSE-KMS uses a KMS key you control, with a CloudTrail trail of every decrypt — the right pick for PII or regulated data. SSE-C means you supply the key on every request and AWS never stores it.

Since 5 January 2023, S3 automatically applies SSE-S3 as the base encryption on every new object in every bucket, at no cost — so "is my data encrypted at rest?" is now answered "yes" by default. The remaining decision is whether you need the control and audit trail of SSE-KMS. If you do, turn on the S3 Bucket Key: it can cut your KMS request cost by up to 99% by reducing per-object KMS calls. Forgetting the bucket key is how teams get a surprise KMS bill on a high-traffic bucket.

At-rest isn't enough on its own. Enforce encryption in transit too, with a bucket policy that denies any request where aws:SecureTransport is false — that blocks plain HTTP and forces TLS. You can also deny PutObject unless the right s3:x-amz-server-side-encryption header is present, so nobody uploads unencrypted or with the wrong key. These two policy statements are a standard SCS-C02 answer for "enforce encryption."

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::tcs-payroll-prod",
        "arn:aws:s3:::tcs-payroll-prod/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "DenyWrongEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::tcs-payroll-prod/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    }
  ]
}

# apply it, then test plain HTTP is blocked:
$ aws s3api put-bucket-policy --bucket tcs-payroll-prod --policy file://policy.json
$ curl http://tcs-payroll-prod.s3.amazonaws.com/test.txt
AccessDeniedAccess Denied
# 403 over HTTP — TLS now mandatory

Last, defend against deletion and ransomware. Turn on Versioning so an overwrite or delete never truly loses the old copy. Add Object Lock (WORM): in Governance mode only users with a special permission can remove the lock; in Compliance mode nobody — not even the account root — can delete the version until retention expires. Top it with MFA Delete so wiping versions needs a physical second factor.

④ Detect + verify — Access Analyzer, Macie, CloudTrail

Configuring controls is half the job; proving they hold is the other half — and it's where the exam and real audits live. Three tools do the proving. IAM Access Analyzer for S3 tells you which buckets are public or shared cross-account. Amazon Macie tells you which buckets actually contain sensitive data like PAN/Aadhaar-style PII. CloudTrail S3 data events tell you who read or changed which object.

Start with Access Analyzer, because it directly answers "is anything public?". In the S3 console, open General purpose buckets and expand the External access summary — it shows active public and cross-account findings per Region (you first create an external-access analyzer once per Region in the IAM console). For each public bucket it shows whether the access comes from a bucket policy, an ACL, or an access-point policy, and gives you a one-click Block all public access button to fix it.

Then layer in Macie to find the data that actually matters. A sensitive-data discovery job (Macie console → Jobs → Create job) scans selected buckets and reports objects containing credit-card numbers, credentials, passport/PII patterns and more, using built-in managed data identifiers. Automated discovery samples your whole estate daily; targeted jobs go deep on the buckets you choose. The point: a public bucket full of cat photos is a shrug; a public bucket Macie flags as full of PII is a fire.

# 1) Ask S3 directly whether the bucket policy is public
aws s3api get-bucket-policy-status --bucket flipkart-invoices

# 2) Record object-level reads/writes (who-read-what) for the bucket
aws cloudtrail put-event-selectors --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":false,\
  "DataResources":[{"Type":"AWS::S3::Object",\
  "Values":["arn:aws:s3:::flipkart-invoices/"]}]}]'

{
    "PolicyStatus": { "IsPublic": false }
}
# IsPublic:false after the fix.  Data events now on:
{ "TrailName": "org-trail",
  "EventSelectors": [ { "ReadWriteType": "All",
    "DataResources": [ { "Type": "AWS::S3::Object" } ] } ] }

For the cert: this maps straight onto AWS Certified Security – Specialty (SCS-C02). Domain 2 (Security Logging and Monitoring) is your CloudTrail data events and Macie; Domain 4 (Identity and Access Management) is the bucket-policy / BPA / cross-account evaluation; Domain 5 (Data Protection) is SSE-S3/KMS/C, the bucket key, TLS enforcement and Object Lock. S3 questions show up across all three — get this lesson solid and you've covered a meaningful slice of the blueprint.