IAM least-privilege without breaking production

Over-broad IAM permissions are the most common — and most exploited — weakness in AWS. The fix isn't to lock everything down overnight; that breaks production. It's to tighten permissions methodically, driven by what your workloads actually do.

Start from real usage, not guesses

Don't hand-write policies from memory. Let AWS tell you what an identity actually used. IAM Access Analyzer can generate a scoped policy from your CloudTrail history, and the IAM console flags permissions a role hasn't touched in months.

• Enable an all-region CloudTrail trail if you haven't already.
• Use Access Analyzer policy generation to draft a policy from a role's real activity.
• Review 'last accessed' data to find services an identity never uses.

Replace wildcards deliberately

Action '*' and Resource '*' are where breaches start. Scope actions to what's needed and resources to specific ARNs. Where a broad action is unavoidable, fence it with conditions.

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::app-prod-assets/*",
  "Condition": { "Bool": { "aws:SecureTransport": "true" } }
}

Add guardrails above identities

Even a perfect policy can be widened later. Set ceilings individual policies can't exceed: Service Control Policies (SCPs) at the org level, and permission boundaries on the roles your developers are allowed to create.

Roll out in staging first, watch CloudTrail for access-denied errors for a few days, then promote. Least-privilege is a process, not a one-time edit.

Catch drift before it bites

Permissions creep back. Have Access Analyzer flag resources shared outside your account, and review unused access on a schedule. Tightening once and never looking again is how you end up back where you started.