AWS IAM least privilege with Access Analyzer

Generate tight IAM policies from real CloudTrail activity and find resources shared outside your account.

IAM least privilege is easy to preach and hard to practice because nobody knows which permissions a role actually uses. Teams default to s3: on “until we know what we need,” and that temporary policy lives for three years. IAM Access Analyzer closes the gap with two concrete workflows: policy generation from CloudTrail activity (what did this role actually call?) and external access analysis (what resource is reachable from outside the account?).

This walkthrough creates an analyzer, starts a policy generation job for an overprivileged CI role, reviews the generated policy against what CloudTrail recorded, and triages external-access findings on an S3 bucket and an assumable role. For SCPs, permission boundaries, and org-wide guardrails, continue in AWS security for DevOps; for the exam framing on IAM and resource policies, see AWS Solutions Architect Associate.

Enable Access Analyzer and create an analyzer

Access Analyzer is regional for resource analysis — enable it in every active region or use an organization-level analyzer in the security account. Findings appear when a resource policy or ACL allows access from outside your zone of trust (another account, the internet, unknown principals).

Generate a policy from real CloudTrail usage

Start a policy generation job anchored to the role you want to tighten. Access Analyzer reads CloudTrail data for that principal and emits a policy containing only actions and resources it actually invoked. Treat the output as a draft — it reflects history, not intent, and it will not invent least-privilege conditions you still need to add.

Find resources shared outside your account

External access findings are how you catch the backup bucket shared with a vendor account you forgot about, or a role trust policy with Principal: * hiding in a sandbox. Resolve findings by tightening the resource policy or removing the cross-account grant — do not just archive and forget.

Tighten the draft with conditions and boundaries

A generated allow list is a starting point. Add explicit denies for destructive actions, attach a permissions boundary on human roles, and use service control policies at the org level to cap what even an admin can grant. For CI roles, prefer OIDC federation (AssumeRoleWithWebIdentity) over long-lived access keys — then generate policy from the federated role, not from a static key user.

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::acme-app-artifacts/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "true" },
    "StringEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Where this goes next

Least privilege is a loop, not a ticket. Re-run policy generation after major refactors, wire IAM Access Analyzer findings into Slack or Jira, and pair IAM tightening with S3 bucket controls so readable buckets and readable roles fail together. AWS security for DevOps walks OIDC for GitHub Actions, permission boundaries, and org SCP patterns that keep generated policies from being undone by a single admin mistake.

Related posts