Teams often miss cross-account and service-mediated access paths that do not look risky at first glance. A bucket can still be reachable through an EC2 role, VPC peering, or an AWS service grant even when direct public access is blocked. The result is a false sense of security, delayed detection, and a larger attack surface than the policy review suggests.
Why bucket ACLs and IAM policies miss the full S3 exposure picture
Bucket ACLs and IAM policies answer only part of the access question: who has been explicitly granted permissions at the bucket or account layer. S3 exposure can still emerge through adjacent paths that are not obvious in a policy review, especially when access is mediated by another AWS service, an instance profile, or an account relationship outside the bucket policy itself. The practical failure is not usually one bad rule, but an incomplete model of how access is actually reached.
That matters because S3 is frequently consumed by workloads rather than people. If the review stops at direct principals and bucket-level statements, teams can miss the effective trust boundary created by roles, temporary credentials, cross-account delegation, and service integrations. In other words, “private bucket” and “safe bucket” are not the same thing.
How cross-account and service-mediated access creates hidden reachability
Cross-account access is often introduced for a legitimate business reason, such as sharing data with another environment or letting a workload read or write objects. The risk appears when the relationship is evaluated only as a static bucket ACL or an IAM allow statement, rather than as a living trust path. A role in another account, an attached policy on an EC2 instance, or an AWS service permission can still make the bucket reachable even when direct public access is blocked.
Service-mediated paths are especially easy to underestimate because they do not always look like “someone can open the bucket.” The bucket may be exposed through assumed roles, temporary credentials, or AWS service grants that inherit broader permissions than the reviewer expected. When those paths are accepted as normal infrastructure plumbing, the exposure becomes invisible to teams that are looking only for public ACLs or obvious broad grants. This is why access review needs to include the full chain of authorization, not just the bucket boundary.
A useful way to think about the problem is to separate authorization design from resource presentation. The bucket may appear locked down, yet effective access can still come from the surrounding identity and trust model. For workloads, the relevant question is not only “who can list this bucket,” but “what runtime principal can reach it, through which trust relationship, and from which account or service context?”
What teams usually miss when they assess S3 exposure
The most common miss is assuming that one control surface tells the whole story. Bucket ACLs, bucket policies, identity policies, VPC boundaries, and service integrations all contribute to effective exposure, but none of them is sufficient alone. A workload with the right role can still reach data even if the bucket is not public, and an internal service can become an unexpected bridge into a bucket that looked isolated on paper.
Another common miss is failing to inventory the credential path behind the access. Temporary credentials, instance profiles, and delegated service access can change over time, so a point-in-time policy check may be outdated almost as soon as it is complete. If the team does not track who can assume which role, and under what conditions, then the review will miss the real attack surface. That is especially true when access is granted for convenience and left in place after the original need has passed.
Good practice is to pair the resource policy review with an identity and lifecycle review of the principals that can touch the bucket. NHIMG’s Cloud Workload Identity Guide is a useful companion here because it frames the runtime identity side of the problem: temporary credentials, role assumption, and keyless workload access are often what actually decide whether S3 is reachable. For teams that need a broader governance lens, Ultimate Guide to NHIs helps connect bucket exposure to the wider issue of machine and workload identity governance.
Risk and Threat Considerations
Relying on ACLs and IAM policies alone creates a false negative in exposure analysis. The bucket may look tightly controlled while an attacker or unintended workload can still reach it through an assumed role, service grant, or cross-account trust relationship that was never reassessed after initial setup.
Failure mechanism: The review model stops at direct access statements and misses indirect authorization paths, so effective permissions remain intact even after the visible controls appear restrictive.
Impact: Sensitive objects can be read, modified, or encrypted through a non-obvious path, which delays detection and expands blast radius when a role, account, or service is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | S3 exposure hinges on enforced access decisions across policies and trust paths. |
| IA-5 — Authenticator Management | Temporary credentials and role-based access are central to hidden S3 reachability. | |
| AC-6 — Least Privilege | Overbroad role and service permissions are the key failure mode behind excess S3 exposure. | |
| Recommendation — Enforce access decisions across bucket, role, and service trust paths. Manage credential lifecycles for workload and cross-account access paths. Reduce S3 access paths to the minimum required permissions. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governs the trust relationships and delegated access that expose S3. |
| SEF — Security Incident Response, Forensics and eDiscovery | Hidden access paths increase detection delay and complicate incident scoping. | |
| Recommendation — Review cloud IAM trust and entitlement paths that can reach S3 data. Instrument logs to trace which identities actually accessed S3 objects. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is incomplete access control coverage across identities and resources. |
| CIS-5 — Account Management | Cross-account roles and workload principals must be governed as active accounts. | |
| Recommendation — Inventory and remove unnecessary S3 access paths and trust relationships. Review active principals and retire stale roles that can reach S3. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The question is about excessive effective access despite apparent controls. |
| ID.AM-01 — Physical devices and systems within the organization are inventoried | Effective S3 exposure review depends on inventorying the systems and workloads that can reach it. | |
| Recommendation — Apply least-privilege controls to every S3 access path. Maintain an inventory of workloads and services that can access S3. | ||
Practitioner Guidance
What to verify: Validate the complete access path, not just the bucket policy. That means checking which principals can assume roles, which services can act on behalf of workloads, and whether cross-account trust is still required. If the bucket is sensitive, require a clear owner for every non-obvious path to it.
Common mistake: Treating “not public” as equivalent to “not exposed.” In practice, hidden exposure usually comes from a legitimate integration that was never reclassified after the environment changed.
Practitioner takeaway: The safest S3 review is the one that starts from effective access, then works backward through identity, delegation, and service relationships until every reachable path is explained.
