Compliance

Enforce IAM least privilege

One capability across IAM policy structure: grant each identity only the permissions it actually needs, attach them through groups and roles rather than directly, and keep wildcard and broad managed grants out of the estate.

14 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: IAM.2 IAM.21 IAM.27

Least privilege: the basics

What makes an identity "over-permissioned"?

Least privilege means an identity can do exactly what its job requires and nothing more. In IAM that shows up in three shapes: how broad each policy is, how policies are attached, and which broad managed grants are handed out. A policy that says s3:* allows every API call S3 exposes, including DeleteBucket and PutBucketPolicy, not the two reads the workload was written for. A policy attached straight to a user hides the intent that a named group would make obvious. A blanket grant like AWSCloudShellFullAccess bundles a privileged, internet-connected shell under one identity.

AWS Security Hub turns each of these into its own control. IAM.21 flags customer-managed policies that allow full administrative or service-level wildcards. IAM.2 flags policies attached directly to IAM users rather than through groups. IAM.27 flags identities carrying the broad AWSCloudShellFullAccess managed policy. They look like separate findings, but they are one capability: bounding what each identity is authorised to do.

Most over-permission is drift, not intent. A wildcard slips past code review because nobody enumerated what was actually called; a policy gets attached to a user "just for today" and never removed; a broad grant rides in on an onboarding template and copies forward for years. The job is to find every over-broad permission, scope it to what the workload genuinely uses, anchor access to groups and roles so intent is auditable, and then prevent the patterns from creeping back in.

In this lesson you will learn how AWS expresses over-permission across policy breadth, attachment structure and broad managed grants, how to find every over-broad identity in an account using the credential and policy data plus IAM Access Analyzer, and how to scope them down without breaking the workloads that depend on them. The Controls this lesson covers section lists every Security Hub control in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The Code Spaces lesson

In 2014 a code-hosting startup called Code Spaces was put out of business in twelve hours. An attacker phished an AWS access key whose policy included Action: "*", used it to delete every S3 bucket, every EBS snapshot, every instance and every backup, then demanded a ransom. There were no backups left to restore from. The wildcard was not the only failure, but it is the one that turned a compromise into an extinction event. The mirror image shows up in over-permissioned individual identities: in one later audit a single contractor user had accumulated 47 directly-attached managed policies, including an AdministratorAccess added "temporarily" during a migration and never removed, on a contract that had ended 18 months earlier.

Finding over-permission across an estate

Priya is auditing IAM after Security Hub fires a batch of findings overnight: several customer-managed policies with service wildcards, a stack of users with policies attached directly, and a group carrying AWSCloudShellFullAccess.

Rather than rewrite anything from scratch, she starts by enumerating what each over-broad policy actually grants and which identities carry it, so she can separate genuine drift from the handful of deliberate exceptions before changing anything.

Pull a wildcard customer-managed policy to confirm exactly how broad it is before scoping it down.

$ aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/DataPipelineWorkerPolicy --version-id v3 --query 'PolicyVersion.Document.Statement[].{Effect:Effect,Action:Action,Resource:Resource}'

[

{ "Effect": "Allow", "Action": "s3:*", "Resource": "*" },

{ "Effect": "Allow", "Action": "kms:*", "Resource": "*" }

]

# s3:* and kms:* on Resource:* is textbook IAM.21. The ETL job actually uses about 8 actions.

Service wildcards on a production policy are the highest-value target in this group. Enumerate real usage, then scope to it.

How AWS evaluates over-permissiondeep dive

IAM.21 runs against the AWS Config managed rule iam-policy-no-statements-with-admin-access. It parses every customer-managed policy and fails any statement with Effect: Allow plus an Action matching * or service:* on Resource *. It only inspects customer-managed policies, the ones you create, not AWS-managed policies like AdministratorAccess, and it is change-triggered, so it re-evaluates within minutes of a CreatePolicy or CreatePolicyVersion call. IAM Access Analyzer is the right tool to fix it: its policy generator reads CloudTrail for a principal over a window and emits a deny-by-default policy listing only the actions actually called.

IAM.2 evaluates the IAM data model and counts each user that has either a non-empty attached-managed-policies list or a non-empty inline-policies list. Group memberships and assumed roles are not counted, which is the entire point: from the evaluation engine's view a policy on a user and the same policy on a group containing that user are identical at request time, but a group name documents intent and makes offboarding a single removal. There is also a hard ceiling, a user can hold at most 10 attached managed policies and 10 inline policies, which groups raise effectively to unlimited.

IAM.27 is backed by the Config rule iam-policy-blacklisted-check, parameterised with the AWSCloudShellFullAccess ARN, and evaluates users, groups and roles. The danger is the bundle: the policy grants the CloudShell session and file-transfer actions, and the environment itself provides sudo and outbound internet, which together is a textbook data-exfiltration path. The least-privilege replacement is a scoped customer-managed policy that allows the session actions but denies the file upload and download actions, keeping the convenience without the exfiltration leg.

What is the impact of leaving identities over-permissioned?

The direct impact is blast radius. A key with s3:* does not just read data; the same key can delete every bucket, rewrite policies to make data public, and disable versioning to defeat your last line of defence. A user with a broad CloudShell grant has a sudo-capable, internet-connected shell that can stage and exfiltrate anything its other permissions can reach. A workload meant to do one narrow thing has the authority to wipe customer data, and the attacker does not need to escalate, the policy already gave them everything.

The second-order impact is detection. Tight policies generate AccessDenied events the moment something unusual happens, which GuardDuty notices and the on-call gets paged. Wildcard and broad policies silently allow whatever the attacker does, so the first signal is the exfiltration itself, often days later. Least privilege is not only about prevention; it is about giving yourself something to detect.

On the compliance side, SOC 2, ISO 27001, HIPAA and PCI DSS all require role-based access aligned with least privilege, and evidence of it. A finding flagging s3:* on a production role, a user with eleven direct policies nobody can explain, or a long list of broad CloudShell grants is the paper trail an auditor finds quickly, and it becomes a finding in the report whether or not you were ever breached. It is also harder to wave away than most findings, because the failing identities frequently hold the broadest permissions.

How do you scope permissions down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: measure what is actually used before you tighten, anchor access to groups and roles, and prevent the patterns from creeping back in.

1. Inventory over-permission across the estate

List every customer-managed policy with a service or full wildcard (IAM.21), every IAM user with directly-attached or inline policies (IAM.2), and every user, group and role carrying AWSCloudShellFullAccess (IAM.27). Group findings by environment and by what each identity can reach. A single over-broad group fans out across many users, so the real count of decisions is usually far smaller than the count of failing identities.

2. Enumerate real usage, then scope to it

For wildcards, run IAM Access Analyzer policy generation over at least 35 days of CloudTrail for the principal, then replace service:* with the enumerated actions scoped to specific ARNs rather than Resource: "*". For CloudShell, replace the broad grant with a scoped policy that allows the session actions but denies file upload and download. Do not guess; the only reliable way to know what an identity needs is to look at what it actually called.

3. Anchor access to groups and roles

For IAM.2, migrate each direct policy to a named group in the safe order, attach the policy to the group and add the user before detaching from the user, so nobody loses access mid-change. Cluster users who share the same policy set into a purpose-named group. Long-term, move humans off IAM users entirely and onto IAM Identity Center, keeping one documented break-glass exception.

4. Prevent recurrence

Enable the relevant AWS Config rules so a new wildcard, direct attachment or broad grant is flagged within minutes, and attach Service Control Policies that deny creating catch-all policies and re-attaching AWSCloudShellFullAccess. Make least-privilege sign-off a gate on new production deployments, and keep a documented exception register with named owners and review dates for the deliberate exceptions.

# Generate a least-privilege policy from real usage, then promote it to default.
aws accessanalyzer start-policy-generation \
  --policy-generation-details principalArn=arn:aws:iam::123456789012:role/DataPipelineWorker
aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/DataPipelineWorkerPolicy \
  --policy-document file://generated-policy.json --set-as-default

# Move a user's direct policy to a group: attach + add BEFORE detach, so there is no gap.
aws iam attach-group-policy --group-name developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam add-user-to-group --group-name developers --user-name nina
aws iam detach-user-policy --user-name nina \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Detach a broad CloudShell grant, then scope down anyone with a genuine need.
aws iam detach-group-policy --group-name developers \
  --policy-arn arn:aws:iam::aws:policy/AWSCloudShellFullAccess

Quick quiz

Question 1 of 5

Security Hub shows wildcard policies, users with directly-attached policies, and a group carrying AWSCloudShellFullAccess. What is the most efficient way to think about them?

Keep learning

Go deeper on least-privilege policy design and the IAM tooling around it.

You can now treat least privilege as one capability rather than a scatter of findings: inventory every over-broad permission, enumerate real usage with Access Analyzer and scope policies to it, anchor access to named groups and roles so intent is auditable, replace broad managed grants with scoped ones, and prevent recurrence with Config rules and Service Control Policies. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

Least privilege: the cost and risk view

Over-permission is an unpriced liability that turns one compromised credential into a catastrophe

These controls do not change the AWS bill. Replacing s3:* with the eight actions a workload actually uses, or moving a policy from a user to a group, costs nothing under normal operation. The cost is entirely on the risk side: over-permission is an unpriced liability that sits invisible until a credential is compromised, at which point a role with s3:* on every bucket, or a user with a privileged CloudShell, can delete data, exfiltrate terabytes, or spin up GPU fleets, all charges that land on the bill with no warning.

Treat each failing control as a line on the risk register weighted by blast radius. A wildcard on a production role with access to customer data is a far higher expected loss than one on a throwaway dev pipeline. A broad CloudShell grant on a phishable developer is a ready-made exfiltration toolkit. Track production over-permission separately from the total finding count; dev exceptions with documented owners are acceptable, production ones are uninsured liabilities.

The insurance maths is one-sided. The remediation is engineering time to enumerate real usage and tighten policies, work you do once. The downside is the documented cost of a breach plus the audit drag: every modern framework expects evidence of least privilege, and a wildcard on a production role is what an auditor finds in the first ten minutes.

This lesson is for the finance partner who sees a cluster of IAM permission findings on the security report and wants to know what the right response is and what it costs. It covers why these controls are zero-cost to fix and an unpriced liability to ignore, how to track production over-permission separately from dev exceptions, and the governance levers, blast-radius triage, named-owner exceptions and a least-privilege gate on new deployments, that keep the count down.

Fun fact

The Code Spaces lesson

How a finance partner frames the over-permission backlog

Devi is the finance partner for the platform team. Security Hub hands her a batch of IAM findings overnight: several customer-managed policies with service wildcards (IAM.21), a stack of users carrying directly-attached policies (IAM.2), and a developer group holding AWSCloudShellFullAccess (IAM.27). Her first move is not to ask what remediation costs, because she already knows the answer is essentially nothing in AWS spend. Her question is which of these identities turns a single compromised credential into a balance-sheet event, and which are noise that fans out from one shared group.

She asks the team to weight each failing identity by what its policy can actually reach. The DataPipelineWorkerPolicy with s3:* and kms:* on Resource: * sits on a production role with access to customer data, so it goes to the top of her risk register as a near-term liability. The CloudShell grant on a phishable developer group is the next line, because it is a ready-made exfiltration toolkit. The dev-account wildcards she treats as documented exceptions. Her output for the risk pack is one sentence: the cleanup is near-zero cost on the bill, and we sequence it by blast radius, not by the raw count of failing identities.

Why over-permission belongs on the risk register

The cost model is asymmetric in a way that is rare for security work. Scoping a wildcard to enumerated actions, moving a policy to a group, or detaching a broad grant changes nothing about what the workload costs to run, while leaving them open creates an unbounded tail risk. An attacker with a compromised broad credential can spin up GPU fleets, exfiltrate terabytes, or re-encrypt data with a KMS key you no longer control, and the bill arrives at month end with an investigation on top.

The audit exposure is separate and ongoing. A failing IAM.21, IAM.2 or IAM.27 control is evidence the least-privilege control is not operating, and remediation after an audit is more expensive than before one. The finance role is to track production over-permission as the headline metric (dev exceptions with documented owners are expected), to price the tail risk for high-value accounts, and to make least-privilege sign-off a gate on new production deployments so the backlog stops re-accumulating.

What finance can drive on least privilege

Finance does not write IAM policies, but it owns the framing that keeps over-permission remediation a business priority rather than a deferred backlog item. Three levers.

1. Track production over-permission separately from the total

The raw finding count mixes production identities, which are genuine liabilities, with dev shortcuts, which are often acceptable. Ask for the production-attached count as the headline metric; zero production wildcards with documented dev exceptions is a very different story from a flat total.

2. Require named-owner sign-off for every exception

Any identity left over-broad after review should carry a business justification, a named owner and a review date, not a silent suppression. That converts we did not get to it into a deliberate, traceable, audit-defensible decision.

3. Make least-privilege a gate on new production deployments

Build it into the release process: any new production workload documents the actions it needs and confirms no wildcards. This stops new technical debt accumulating while the backlog is cleared, and makes scoping a standard part of the build cycle.

Quick quiz

Question 1 of 5

Why is closing an IAM over-permission finding described as a one-sided insurance trade for finance?

Keep learning

Go deeper on least-privilege policy design and the IAM tooling around it.

You have finished the finance view of least privilege. You know the cost is one-sided (near-zero to fix on the AWS bill, potentially catastrophic to ignore once a credential is compromised), that the right metric is production over-permission weighted by blast radius rather than the raw count of failing identities, that a tightened policy must be scoped from observed usage rather than relabelled, and that a least-privilege gate on new deployments stops the backlog re-accumulating. Next time a wall of IAM findings lands, you will ask a sharper question than how much will this cost.

Back to the library

Least privilege: the headline

Whether the organisation controls what its systems are authorised to do

Least privilege is a proxy for a more fundamental question: do you control what your systems can do, or did that drift away three engineers ago? The report shows it as separate findings about wildcards, direct user policies and broad grants, but they all answer the same thing, can you explain what each identity is allowed to do and why?

The blast-radius argument is the one that lands. An account where every production identity has a tight, enumerated permission set limits an incident to what that identity can actually do. An account full of service wildcards and broad grants means a single compromised credential is a potential full-account event, data deletion, exfiltration and compute abuse, with no further privilege escalation needed.

The healthy signal is not zero total findings. Dev and staging often carry broader access by deliberate choice, and that is fine with sign-off. The leadership question is whether all production identities are scoped to least privilege, access is anchored to named groups and roles so intent is auditable, and every exception is recorded with an owner and a review date.

A short read for the leader who needs to know what over-permissioned identities expose, why scoping them is a governance maturity decision rather than a budget one, and what a defensible end state looks like: every production identity scoped to what it uses, access anchored to groups and roles, and every exception on the record.

Fun fact

The Code Spaces lesson

What it looks like when authority is designed, not inherited

After a peer in the sector disclosed a breach where one phished access key with a wildcard policy deleted an entire estate, the CEO asked a single question at the next risk review: can we explain what each of our production identities is allowed to do, and why? The honest answer was no. Permissions had drifted: wildcards slipped past review, policies were attached to users just for today and never removed, broad grants rode in on onboarding templates and copied forward for years. The cluster of IAM findings on the security report was the visible symptom of that drift.

The leadership response was to treat least privilege as a governance posture rather than a backlog of findings. Production identities were scoped to enumerated actions using Access Analyzer, access was anchored to named groups and roles so intent was auditable, and a Config rule plus a Service Control Policy were put in place so a new wildcard or broad grant could not silently reappear. Six months on, the question changed from can we explain it to is production over-permission trending toward zero, and the answer was a line that stayed low quarter on quarter. That trend, not the point-in-time count, is the signal that belongs on a governance review.

Why this is a governance maturity signal

An over-permissioned identity is evidence that authority drifted away from intent, a shortcut nobody went back to tighten that has been granting far more than the workload needed ever since. The finding count for this capability is a proxy for whether permissions are set by deliberate design or inherited from whoever last edited the policy.

The cost of getting it wrong is large and well documented, while the cost of fixing it is engineering time and no change to the bill. The leadership question is not zero total findings, it is whether all production identities are scoped to least privilege, access is anchored to groups and roles so it is auditable, and every exception is recorded and owned. A yes to that means your blast radius is bounded, a compromised credential can only do what it was supposed to do.

The leadership move on least privilege

The handle is not to mandate that every policy be audited this quarter, it is to establish that production runs under least privilege by policy, with every exception on the record.

1. Set the default: production means least privilege

Make it a standard that any production identity carries a permission set scoped to what it actually does and access goes to named groups and roles, not individuals. That is a governance posture, not a technical detail.

2. Accept documented exceptions for development

Do not demand zero findings everywhere. Broader access in dev and staging is appropriate with visibility and sign-off; the requirement is that the exception is recorded, owned and reviewed, not that it is eliminated.

3. Ask for the trend and the prevention controls

The right question is whether production over-permission is declining toward zero, and whether a Config rule and an SCP prevent new wildcards and broad grants. A trend toward zero with structural prevention means the blast radius is bounded by design.

Quick quiz

Question 1 of 5

Why is an over-permissioned identity best framed as a governance maturity signal rather than a purely technical gap?

Keep learning

Go deeper on least-privilege policy design and the IAM tooling around it.

Two takeaways: an over-permissioned identity is an uninsured liability that exists because authority drifted away from intent and nobody went back to tighten it, and the durable fix is governance, not a one-off audit. The trade is engineering hours to enumerate real usage against an open-ended, full-account breach pattern, which is the one leadership should be quickest to approve. Set least privilege as the production default, anchor access to groups and roles, and require a Config rule plus an SCP so the surface stays bounded by design.

Back to the library

Controls this lesson covers

One capability, many AWS Security Hub controls. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

IAM

Part of the learning path Lock down access

Enforce IAM least privilege

Least privilege: the basics

The Code Spaces lesson

Finding over-permission across an estate

How AWS evaluates over-permissiondeep dive

What is the impact of leaving identities over-permissioned?

How do you scope permissions down safely?

1. Inventory over-permission across the estate

2. Enumerate real usage, then scope to it

3. Anchor access to groups and roles

4. Prevent recurrence

Quick quiz

Keep learning

Least privilege: the cost and risk view

The Code Spaces lesson

How a finance partner frames the over-permission backlog

Why over-permission belongs on the risk register

What finance can drive on least privilege

1. Track production over-permission separately from the total

2. Require named-owner sign-off for every exception

3. Make least-privilege a gate on new production deployments

Quick quiz

Keep learning

Least privilege: the headline

The Code Spaces lesson

What it looks like when authority is designed, not inherited

Why this is a governance maturity signal

The leadership move on least privilege

1. Set the default: production means least privilege

2. Accept documented exceptions for development

3. Ask for the trend and the prevention controls

Quick quiz

Keep learning

Controls this lesson covers

IAM

Related compliance lessons