Amazon S3 Security Guide: Block Public Access, Bucket Policies and Object Lock

Amazon S3 buckets keep leaking data because access is decided by several overlapping policy layers, and one permissive layer is often enough. This guide sets out a configuration baseline for S3 general purpose buckets: how authorisation is evaluated, which settings to lock at organisation level, how to control the machine identities that read and write objects, what to log and alert on, and how to make data survive deletion or malicious encryption. It is written for cloud security engineers, platform teams and auditors who own S3 at scale. Incident response for an exposed bucket is covered separately in the Cloud Storage Exposure Playbook; this page is about preventing the exposure in the first place.

Key takeaways

• Turn on all four Block Public Access settings at organisation level and treat any exception as a reviewed, documented decision, because S3 enforces the most restrictive combination of organisation, account, bucket and access point settings.
• Disable ACLs with Object Ownership set to Bucket owner enforced so that access is decided only by policies (IAM, bucket, VPC endpoint, SCP and RCP), which are far easier to review than per-object ACLs.
• Most S3 incidents are identity incidents: a leaked access key or an over-scoped workload role reads or rewrites data with valid credentials, so bucket hardening must be paired with tight, short-lived machine credentials.
• Versioning plus Object Lock is the ransomware control for S3: it stops overwrites and permanent deletes from destroying the only copy, including attacks that abuse SSE-C or lifecycle rules.
• Management events are not enough: enable CloudTrail data events or GuardDuty S3 Protection on sensitive buckets, otherwise object reads and bulk deletes are invisible.

How identity and access work in Amazon S3

An S3 request is allowed only when the policy layers that apply to it allow it and none of them denies it. For a request inside one account, either an identity-based policy or the bucket policy can grant access. For a cross-account request, both the caller's identity policy and the bucket policy (or access point policy) must allow it. Guardrail layers such as SCPs, RCPs and VPC endpoint policies never grant anything; they only cap what the other layers can grant. Block Public Access sits across all of them and overrides public grants regardless of what a policy says.

What S3 treats as public

• ACLs: an ACL is public if it grants any permission to the AllUsers or AuthenticatedUsers groups. "Authenticated users" means any AWS account in the world, not your organisation.
• Bucket policies: S3 assumes a policy is public unless it grants access only to fixed values, without wildcards or policy variables, of keys such as a named principal, aws:PrincipalOrgID, aws:SourceVpc, aws:SourceVpce, aws:SourceAccount, aws:SourceArn or an aws:SourceIp range. IPv4 ranges wider than /8 (outside RFC 1918 space) are treated as public.
• Not covered: Block Public Access does not evaluate identity-based policies or the policies on other resources, such as the KMS key that encrypts the bucket. Those need their own review.

The four Block Public Access settings

Because none of the settings rewrites an existing ACL or policy, removing a setting immediately makes any old public grant effective again. Block Public Access can now be set as an AWS Organizations policy attached to the root or an OU, where all four settings apply together and override account settings in member accounts. Access point settings can only be chosen when the access point is created. Block Public Access is not available per object.

Admin roles and privileged access

A small set of S3 actions changes who can reach data. They deserve the same treatment as IAM administration: few holders, protected by SCPs, and alerted on every use.

• Root and break-glass: a bucket policy that denies everyone can only be repaired by the account root user or a principal it still allows. Document that recovery path before rolling out deny-by-default policies, and keep root credentials offline with MFA.
• Human access: engineers should reach S3 through federated, time-limited roles, not IAM users with access keys. See the AWS IAM Identity Center Guide.
• Separation of duties: the team that can change a bucket policy should not be the same team that can delete the CloudTrail and access-log buckets that would record the change.

Integrations, API tokens and service accounts

The majority of principals that touch S3 are machines: applications on EC2 and Lambda, CI/CD pipelines, data platforms, backup tools and SaaS vendors. They are where S3 breaches usually start. In the Capital One breach, a firewall's IAM role, reached through the instance metadata service, could list and read customer-data buckets it had no need for. In the Codefinger S3 ransomware campaign, long-term access keys with read and write rights were enough to re-encrypt objects with SSE-C and set expiry rules, with no AWS vulnerability involved.

• Use roles, not access keys: attach IAM roles to EC2, ECS, EKS and Lambda so workloads receive temporary credentials. Outside AWS, use OIDC federation for CI/CD or IAM Roles Anywhere for on-premises servers. See the AWS STS and AssumeRole Guide.
• Scope to bucket and prefix: grant s3:GetObject on arn:aws:s3:::bucket/prefix/*, not s3:* on *. List and delete rights are separate decisions; most readers need neither.
• Protect the credential source: require IMDSv2 on instances whose roles can read sensitive buckets. See the EC2 Instance Metadata Service Hardening Guide.
• Third parties: grant SaaS vendors a role they assume with an external ID and a policy limited to the prefixes they process, never an IAM user key pasted into their console. Restrict cross-account access to your own organisation with aws:PrincipalOrgID in bucket policies or, estate-wide, with an RCP. See the AWS Resource Control Policies and Data Perimeter Guide.
• Presigned URLs: a presigned URL carries the permissions of the principal that signed it for its lifetime. Sign with a narrowly scoped role and keep expiry short; a URL signed with temporary credentials stops working when those credentials expire.
• Network path: for workloads inside a VPC, use a gateway endpoint for S3 and a bucket policy with aws:SourceVpce or aws:SourceVpc. Pair it with an endpoint policy that only allows your organisation's buckets, which closes an easy exfiltration path. Test carefully: a wrong endpoint ID denies all access, and console users outside the VPC will lose access too.
• Leaked key hygiene: find and remove IAM user keys with S3 rights, and rotate any key that has appeared in code or logs. See the Cloud Access Key Leak Playbook.

Logging and detection

S3 has three distinct log sources and they answer different questions. CloudTrail management events record configuration changes and are on by default in event history. CloudTrail data events record object-level calls such as GetObject, PutObject and DeleteObject, and must be enabled on a trail or event data store. Server access logs record every request to a bucket, including anonymous ones, in a delivered log file. Destination buckets for server access logs must use SSE-S3, not SSE-KMS.

GuardDuty S3 Protection analyses S3 data events across all buckets in the Region without you configuring data event logging yourself, though it skips unauthenticated requests to public objects. Its finding types include Exfiltration:S3/AnomalousBehavior, Impact:S3/AnomalousBehavior.Delete, Impact:S3/AnomalousBehavior.Write, Impact:S3/AnomalousBehavior.Permission, Policy:S3/BucketBlockPublicAccessDisabled, Policy:S3/BucketAnonymousAccessGranted and Stealth:S3/ServerAccessLoggingDisabled. See the Amazon GuardDuty Guide. IAM Access Analyzer flags buckets shared outside your account or organisation, and Amazon Macie finds sensitive data so you know which buckets deserve the strictest controls.

Metrics that show the baseline is working

• Public exposure: number of buckets with a public or cross-account finding in IAM Access Analyzer that is not on the approved exceptions list (target zero).
• ACL debt: percentage of buckets with Object Ownership set to Bucket owner enforced (target 100%).
• Visibility: percentage of buckets classified as sensitive that are covered by data events or S3 Protection.
• Machine credential risk: count of IAM user access keys with S3 write or delete rights, and their age.
• Recoverability: percentage of critical buckets with versioning, Object Lock or replication to a separately controlled account, plus the last tested restore date.
• Response: median time from a policy or Block Public Access change outside the pipeline to triage.

Hardening baseline

Choosing between options

• SSE-S3 or SSE-KMS: SSE-S3 protects against lost disks and costs nothing extra. Choose SSE-KMS with a customer managed key when you need a second authorisation check (the reader also needs kms:Decrypt), key-level CloudTrail evidence, or the ability to cut off access by disabling the key. The AWS managed key aws/s3 cannot be shared across accounts and its key policy cannot be edited. Use a full key ARN, not an alias, in cross-account writes. See the AWS KMS Security Guide.
• Governance or compliance mode: governance mode lets holders of s3:BypassGovernanceRetention override retention, which suits testing and operational data. Compliance mode cannot be shortened or removed by anyone, including root, until it expires, so use it for regulated records and backup copies, and pilot retention periods in governance mode first.
• Small or large estate: a single account can set account-level Block Public Access and a handful of Config rules. A multi-account organisation should manage Block Public Access, SCPs and RCPs centrally and send findings to a delegated security account. See the AWS Multi-Account Security Reference Architecture Guide.

Rollout in phases

1. Inventory: list every bucket per account and Region with its Block Public Access state, Object Ownership, policy, encryption and logging. Use IAM Access Analyzer to list external and public sharing, and Macie to rank buckets by data sensitivity.
2. Agree exceptions: the few buckets that are intentionally public (static sites are better served through CloudFront with origin access control) get an owner, a reason and a review date.
3. Disable ACLs: for buckets still on Object writer, review bucket and object ACLs, move needed grants into the bucket policy, then switch to Bucket owner enforced. Watch for AccessControlListNotSupported errors from clients that still send ACLs. Rollback is switching the setting back, which restores the earlier ACLs.
4. Enforce Block Public Access: apply at account level in a pilot OU first, watch for broken access over one or two weeks, then attach the organisation policy to the root and add an SCP that denies changes to it.
5. Add deny statements: TLS-only, required encryption and, where relevant, VPC endpoint restrictions. Deploy through infrastructure as code with a tested recovery path for lockouts.
6. Turn on detection and resilience: GuardDuty S3 Protection, data events on sensitive buckets, versioning everywhere critical, and Object Lock on log and backup buckets.

Framework mapping

The ATT&CK techniques most relevant to S3 are T1530 Data from Cloud Storage, T1619 Cloud Storage Object Discovery, T1537 Transfer Data to Cloud Account, T1485 Data Destruction and T1486 Data Encrypted for Impact, usually preceded by T1078.004 Cloud Accounts or T1552.005 Cloud Instance Metadata API.

Common misconfigurations

• Turning off Block Public Access "temporarily": every old public ACL and policy becomes live again the moment the setting is removed. Make the organisation policy the only control point.
• "Authenticated users" grants: legacy ACLs granting AuthenticatedUsers are open to any AWS customer, not to your staff.
• Wildcard principals with a weak condition: "Principal": "*" with a broad aws:SourceIp range, a policy variable or a wildcard in the condition is still public by S3's definition.
• Over-scoped workload roles: roles with s3:* on every bucket turn a single SSRF or leaked key into a full data breach, as Capital One showed.
• Versioning without lock, or no versioning at all: an attacker with delete rights can remove noncurrent versions too; only Object Lock or a replica in a separately controlled account withstands that.
• Logs in the same blast radius: CloudTrail and access logs stored in the production account, writable by production administrators, can be deleted by the same compromised identity. Send them to a log archive account with Object Lock. See the AWS CloudTrail Guide.

Practitioner checklist

• Enable all four Block Public Access settings as an organisation policy or on every account, and deny changes to them with an SCP.
• Set Object Ownership to Bucket owner enforced on every bucket after migrating any needed ACL grants.
• Add TLS-only and required-encryption deny statements to every bucket policy through infrastructure as code.
• Use SSE-KMS with customer managed keys for sensitive buckets and keep SSE-C disabled unless documented.
• Replace IAM user access keys with roles, OIDC federation or IAM Roles Anywhere, and scope each role to bucket and prefix.
• Limit cross-account access with aws:PrincipalOrgID or an RCP, and restrict VPC endpoints to your organisation's buckets.
• Enable GuardDuty S3 Protection, and CloudTrail data events or server access logs on sensitive buckets.
• Alert on bucket policy, ACL, Block Public Access, lifecycle, replication and encryption changes made outside the pipeline.
• Turn on versioning for critical buckets and Object Lock for logs and backups, and test a restore each quarter.
• Review IAM Access Analyzer external access findings weekly and record every intentional public or shared bucket with an owner.

Standards and references

• AWS: Security best practices for Amazon S3
• AWS: Blocking public access to your Amazon S3 storage
• AWS: Controlling ownership of objects and disabling ACLs for your bucket
• AWS: Locking objects with Object Lock
• AWS: Using server-side encryption with AWS KMS keys (SSE-KMS)
• AWS: Controlling access from VPC endpoints with bucket policies
• AWS: Amazon GuardDuty S3 Protection
• MITRE ATT&CK: Data from Cloud Storage

Related NHI Mgmt Group resources: AWS Security Guide · Cloud Storage Exposure Playbook · AWS IAM Policies and Roles Guide · Cloud Ransomware Guide