Access You Didn’t Mean to Grant
Two questions decide how safe an AWS account really is: who can already get in, and how do people get in on purpose. AWS has a tool for each.
Nobody can answer “is anything in this account reachable from outside?” from memory. Policies accumulate, wildcards get added at 6pm on a Friday, and a bucket opened for a one-off migration two years ago is still open.
IAM Access Analyzer answers that question mechanically. IAM Identity Center stops you generating the problem in the first place.
The zone of trust
You tell Access Analyzer what you consider “yours” — this account, or your whole organisation. That boundary is the zone of trust, and everything the tool does is compare policies against it.
A finding is not an accusation. Deliberate cross-account access to a partner will show up, and you archive it. What you’re hunting for is the access nobody remembers granting.
Two analyzers, two questions
The analysis behind the external findings is worth knowing about: it is mathematical, not pattern matching. AWS applies automated reasoning to prove whether a policy can permit outside access, so it catches combinations of conditions and wildcards that a human reviewer reading JSON would miss.
One thing to get right at setup: external access analyzers are per-Region, so an analyzer in Virginia tells you nothing about your Frankfurt buckets. Unused access works account-wide or organization-wide instead, and unlike external access it is billed per identity monitored.
The credentials report: five minutes well spent
A single CSV, downloadable from the IAM console, listing every IAM user in the account and the state of their credentials — password age and last use, whether MFA is on, both access keys with their age, last-used date, region and service.
Sort it by access key age and you have your remediation list. Two limits to remember: it covers IAM users only — not roles, not Identity Center users — and it’s cached for up to four hours, so a fresh request may hand you a slightly stale file.
The policy generator
This is the fastest honest route from a broad policy to a narrow one, because it works from evidence rather than from someone’s guess about what an application might call.
The catch is in the word did. A code path that runs at quarter end won’t appear in a 90-day window, so treat the output as a strong draft: read it, widen anything seasonal, tighten the resources it left as wildcards, then ship it.
The other half of the problem is upstream
Auditing is worth doing, but every finding you fix by hand came from a grant someone made by hand. If humans get into your accounts through IAM users and manually attached policies, you will be cleaning up forever.
IAM Identity Center
It’s AWS’s front door for workforce access — the service that replaced AWS SSO — and it costs nothing. People sign in once at an access portal and see only the accounts and roles they’ve been granted.
Get Ankur Batham’s stories in your inbox
Join Medium for free to get updates from this writer.
The unit of access is the permission set: a collection of policies that becomes a real IAM role in each account you assign it to. Define “read-only in production” once, assign it to forty accounts, change it in one place.
Three things that follow from this, and they’re the actual reason to adopt it:
- Access is granted by assignment, not by writing a policy per account.
- Sessions expire on their own, so there is nothing to revoke on a normal day.
- Disable someone in your identity provider and their AWS access goes with it.
When it’s overkill: a single account you use for learning or a personal demo. Plain IAM with MFA is fine there. The value appears the moment there is a second account or a second person.
Identity Center or roles and STS?
The framing as a competition is the mistake. Identity Center is how humans arrive; roles assumed through STS are how applications, pipelines and cross-account automation arrive. A mature account uses both and keeps them separate — if a build pipeline is logging in as a person, something has gone wrong.
Where teams get burned
An analyzer in one Region only. Enable external access analysis everywhere you actually have resources, or the report is reassuring rather than true.
Findings nobody owns. A findings list read once at setup and never again is worse than none, because it creates the impression of coverage. Route new findings to a channel or a ticket queue.
Archiving to clear the board. Archive rules are for access you have decided is fine. Used to make the number go down, they hide exactly what you built the analyzer to see.
Identity Center enabled, IAM users left behind. The old path stays open until somebody closes it. Migrating people and then deleting their IAM users is the part that delivers the benefit.
Five checks worth running this week
- Is external access analysis enabled in every Region where you have resources?
- How many external access findings are currently open, and who looked at them last?
- Download the credentials report — what is the age of the oldest active access key in it?
- Pick your broadest role and run the policy generator against the last 90 days. How much of what it grants was ever used?
- How do humans get into your production account today, and how long does that access last?
Where to go next
Turn on both analyzers, download the credentials report, and read what comes back before changing anything. Findings are cheap to generate and genuinely informative, and the first pass usually explains more about how an account grew than any documentation will.
Written from AWS’s published IAM Access Analyzer and IAM Identity Center documentation. Features, limits and pricing change; check the current docs before committing to a design.
