Notifications
Clear all
Topic starter
08/06/2026 5:04 pm
TL;DR: In AWS, the hard problem is not encryption but correlating IAM identities, permissions, and data sensitivity across multi-account environments, because teams often cannot tell who can access which sensitive datastore or at what level, according to Cyera. That visibility gap turns least privilege into guesswork and makes compliance and breach response slower and less reliable.
NHIMG editorial — based on content published by Cyera: Know Your Data, Control Your Access: How Cyera and AWS IAM Access Analyzer Deliver Data-Aware Governance for Sensitive Data in AWS
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should teams govern AWS access when sensitive data is spread across multiple accounts?
A: Teams should correlate IAM entitlements with data classification so they can see who can reach each sensitive datastore and at what privilege level.
Q: Why do identity reviews often miss the real risk in cloud data access?
A: Because identity reviews usually stop at the principal, not the data it can reach.
Q: What breaks when access findings are not paired with data sensitivity?
A: Without sensitivity labels, access findings become a list of permissions instead of a risk picture.
Practitioner guidance
- Map sensitive datastores to all reachable identities Build a permissions matrix that joins AWS IAM findings to sensitivity labels for S3, RDS, DynamoDB, and snapshots, then review cross-account access first.
- Prioritise cleanup by sensitivity level Triage the highest-risk combinations of privileged access and restrictive data classifications before you spend time on low-impact entitlements.
- Re-run access reviews against actual data exposure Use the correlated access view as the evidence pack for recertification, audit, and least-privilege remediation, rather than reviewing roles in isolation.
What's in the full article
Cyera's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step use of AWS IAM Access Analyzer to collect cross-account findings.
- The permissions matrix workflow used to correlate IAM access with sensitive datastore classifications.
- Example commands and scripts for extracting findings into CSV for review and reporting.
- A practical walkthrough of how the Cyera DSPM layer changes prioritisation for sensitive data access.
👉 Read Cyera's analysis of data-aware governance for sensitive AWS data →
AWS IAM Access Analyzer and data sensitivity: what teams should do?
Explore further
08/06/2026 7:02 pm
Data-aware IAM is now the difference between policy and proof. Cloud teams can write least-privilege policies all day and still fail to answer the operational question of who can reach which sensitive datastore. The article shows that the missing layer is not another IAM control in isolation, but the correlation of identity, access, and sensitivity at scale. Practitioners should treat data-aware visibility as the proof layer for governance, not a reporting enhancement.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do you know if cloud least privilege is actually working?
A: You know it is working when every high-sensitivity datastore has a short, explainable list of identities with clearly bounded access and documented business need. If cross-account roles, inherited trust, or federated permissions reach sensitive data without a strong justification, least privilege is only partially implemented.
👉 Read our full editorial: Data-aware IAM for AWS shows why access and sensitivity must align
