How should teams govern AWS access when sensitive data is spread across multiple accounts?

Why This Matters for Security Teams

When sensitive data is distributed across multiple AWS accounts, the security problem is not just “who has a role.” It is whether those roles, trust relationships, and inherited permissions let an identity reach a datastore it should never touch. A single account review can miss cross-account access paths, federated sessions, and permissions attached through resource policies. That is why teams need a permissions matrix tied to data classification, not a role inventory alone.

This is especially important because non-human identities often outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations say they have full visibility into their service accounts, according to NHI Management Group’s Ultimate Guide to NHIs. For broader control mapping, the NIST Cybersecurity Framework 2.0 remains useful, but it does not by itself reveal data-path exposure across accounts. In practice, many security teams discover over-permissioned cross-account access only after a data owner asks for evidence or an incident forces a full entitlement review.

How It Works in Practice

The practical approach is to build the review around data locations first, then map every AWS identity path that can reach them. Start by listing the sensitive datastores in each account, then identify the IAM roles, federated identities, assumed roles, resource policies, and service-linked permissions that can access them. The output should show privilege level, action scope, and whether access is direct, inherited, or transitive through cross-account trust.

For AWS, that usually means correlating IAM with S3 bucket policies, KMS key policies, Secrets Manager access, database grants, and organization-wide trust relationships. A team may think it has limited access because a role is scoped narrowly in one account, while the real exposure comes from a trusted principal in another account that can assume it. The OWASP Non-Human Identity Top 10 is a useful reminder that over-privileged NHIs, stale secrets, and weak lifecycle controls are recurring failure patterns rather than edge cases.

• Classify each datastore by sensitivity and business owner.
• Enumerate all principals that can reach it, including assumed roles and external trusts.
• Record effective permissions, not just attached policies.
• Flag paths that cross account boundaries or rely on broad wildcards.
• Use the matrix for recertification, remediation, and audit evidence.

NHI Management Group has repeatedly found that poor visibility and excessive privilege are common drivers of exposure, as reflected in the Top 10 NHI Issues and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives. These controls tend to break down when organisations use shared tooling accounts with broad trust, because the effective permissions become transitive and difficult to attribute to a single owner.

Common Variations and Edge Cases

Tighter cross-account governance often increases operational overhead, requiring organisations to balance auditability against deployment speed. That tradeoff is real, especially in environments with many ephemeral workloads, central platform accounts, or frequent account vending. Best practice is evolving, but current guidance suggests treating exceptions as time-bound and explicitly approved rather than allowing them to become permanent access paths.

Edge cases matter. A data store may be protected in one account but still reachable through a KMS key in another account, or through a read-only role that can later assume a more privileged role. Federated workforce access can also mask the true source of entitlement if session tags are not consistent. The 52 NHI Breaches Analysis shows how quickly identity control gaps become material when attackers or careless operators can move across trust boundaries.

Where teams are mature, they pair the permissions matrix with continuous monitoring and periodic recertification. Where they are immature, they often stop at account-level IAM reviews and miss the real exposure hidden in resource policies, inherited trust, or stale service identities. That gap is why the question is fundamentally about effective access, not just identity counts.

Related resources from NHI Mgmt Group

• How should security teams govern access when sensitive data is spread across multiple systems?
• How should security teams govern Active Directory access across multiple databases?
• How should security teams govern AI access to sensitive data across hybrid environments?
• How should security teams govern MySQL user access across many instances?