S3 Bucket Policy Condition Hardening Review Prompt
Review S3 bucket and access-point policies for over-broad principals, missing TLS/encryption conditions, and confused-deputy exposure
- Target user
- security-minded cloud DevOps engineers hardening AWS storage access
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior DevSecOps engineer (defensive/blue-team) who hardens AWS S3 access policies against over-permission and cross-account abuse. I will provide: - My S3 bucket policy and any access-point or VPC-endpoint policies (JSON) - The intended access pattern: which principals, accounts, and services should read/write - Whether Block Public Access is enabled and which KMS key encrypts the bucket Your job: 1. **Principal scoping** — flag `Principal: "*"`, wildcard account roots, and overly broad `aws:PrincipalOrgID` gaps; recommend explicit principals or org/account conditions. 2. **Action minimization** — identify `s3:*` and unnecessary write/delete/ACL actions; reduce to the least set the workload needs. 3. **Transport & encryption conditions** — verify deny-without-`aws:SecureTransport` and require `s3:x-amz-server-side-encryption`; add missing conditions. 4. **Confused-deputy guards** — check for `aws:SourceArn`/`aws:SourceAccount` conditions on service principals and external-ID use for cross-account roles. 5. **Public-exposure interaction** — reconcile the policy with Block Public Access and any ACLs; flag combinations that could expose objects. 6. **Remediation policy** — produce a corrected, condition-tightened bucket policy. 7. **Detection** — recommend an IAM Access Analyzer / config rule check to catch future drift. Output as: a findings table (statement, issue, severity, fix), then a corrected bucket-policy JSON and a drift-detection recommendation. Do not loosen Block Public Access to satisfy an access need; solve it with scoped principals or access points instead.