/iam-audit

name: iam-audit
description: "Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization (RBAC, ABAC, ReBAC), and federated identity. Use when the user mentions 'IAM,' 'identity,' 'access management,' 'least privilege,' 'role design,' 'SSO,' 'SAML,' 'OIDC,' 'OAuth,' 'JIT access,' 'just-in-time access,' 'break-glass,' 'service accounts,' 'RBAC,' 'ABAC,' 'privilege creep,' 'role explosion,' 'identity governance,' 'IAM strategy,' 'identity migration,' 'Okta,' 'Entra ID,' 'Azure AD,' 'Auth0,' 'Cognito,' or needs identity consultant-level guidance."
allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch

IAM Audit — Identity & Access Management Review and Design

Cover the identity and access layer end-to-end: audit existing setup, design from scratch, plan migrations, and codify the patterns most teams get wrong. This is the consultant-style skill — not just "what's misconfigured" but "what should this look like."

Three modes — pick the one that matches the engagement:

• **Audit** — review what's already deployed, find privilege creep and gaps
• **Design** — greenfield IAM for a new project or new identity provider
• **Migrate** — consolidate multiple identity providers, federate access, move to SSO

Cross-references: `cloud-audit` for the cloud-provider audit (broader than IAM), `container-audit` for K8s RBAC and ServiceAccounts (orchestration-layer identity).

Mode 1 — Audit existing IAM

Cloud provider IAM

**AWS:**

• IAM users with console access — should be zero in mature setups (use SSO/Identity Center)
• IAM users with permanent access keys — every one is a credential rotation problem; replace with role assumption via SSO or IAM Roles Anywhere
• Permissions boundaries set on every role that can create roles (prevents privilege escalation via `iam:CreateRole` + `iam:AttachRolePolicy`)
• `AdministratorAccess` policy attachments — flag every one and justify
• Wildcard `Action: "*"` or `Resource: "*"` outside of break-glass roles
• Cross-account trust policies — `Principal: { AWS: "*" }` is open to the world; should be specific account IDs with optional `aws:PrincipalOrgID` condition
• IMDSv2 enforced — `MetadataOptions.HttpTokens: required` on every EC2 launch template
• Service-linked roles audited — they bypass normal restrictions
• Run: `aws accessanalyzer list-findings`, `aws iam generate-credential-report`, `aws iam get-account-authorization-details`

**GCP:**

• `roles/owner` and `roles/editor` are too broad — replace with custom roles or fine-grained `roles/*Admin`
• Service account keys downloaded (`projects.serviceAccounts.keys.create`) — should be zero; use Workload Identity Federation
• Service accounts with `iam.serviceAccountTokenCreator` on themselves = self-impersonation = privilege escalation
• Org-level vs project-level bindings — over-scoped bindings at the org level are silent privilege grants to every project
• `allUsers` / `allAuthenticatedUsers` bindings on any sensitive resource
• Run: `gcloud asset analyze-iam-policy`, `gcloud policy-intelligence query-activity`, Recommender API

**Azure:**

• `Owner` and `Contributor` role assignments at subscription/management-group scope
• Custom roles with `*` actions
• Conditional Access policies cover *every* sign-in surface (legacy auth, service principals, break-glass accounts excluded with explicit reason)
• Privileged Identity Management (PIM) used for all Global Admin / Privileged Role Admin / Application Admin roles
• Service principal credentials (client secrets) — should expire and rotate; check expiration dates
• Run: `az role assignment list --all`, Microsoft Graph `auditLogs/signIns`, Microsoft Entra recommendations

Identity provider

**Okta / Entra ID / Auth0 / Google Workspace:**

• MFA enforced for 100% of users — no "MFA optional" cohort
• Phishing-resistant MFA (FIDO2 / WebAuthn / hardware key) for admins; TOTP is the minimum for everyone
• Inactive accounts disabled after 30/60/90 days (pick a policy, enforce it)
• Lifecycle automation — joiner / mover / leaver flows are automated, not ticket-driven
• Group-based access — users get permissions via group membership, not direct assignment; group membership is the auditable surface
• Admin separation — privileged admin actions require a separate elevated account, not the day-to-day account
• App assignments — every SaaS app reviewed quarterly; orphaned apps (no longer used) removed
• Authentication policies — block legacy protocols (IMAP, POP, SMTP basic auth), enforce device compliance for high-trust apps
• Session lifetime appropriate to sensitivity (admin: short, end user: longer with refresh)
• Logs forwarded to SIEM — sign-ins, admin changes, MFA failures

Application authorization

• Role definitions written down somewhere (not just in code) — `docs/roles.md` or equivalent
• "Admin" is not one role — usually 3-5: support, billing, content moderator, platform admin, security responder
• Per-tenant role isolation — a "tenant admin" of org A cannot read org B even with the same role
• Permission checks centralized — one `can(user, action, resource)` function, not scattered `if (user.role === "admin")` checks throughout
• ABAC where the access decision depends on resource attributes (record owner, tenant, status) — ReBAC tools (Cerbos, OpenFGA, Oso, SpiceDB) when role explosion threatens
• Permission checks logged for the audit trail

Common audit findings

• **Role explosion** — every new requirement spawned a new role; nobody knows what they all do; nobody dares delete one
• **Permission accretion** — engineers got temporary permissions for an incident, permissions were never revoked
• **Shadow admin** — a non-admin role can `iam:AssumeRole` into admin, transitively
• **Stale break-glass** — emergency-access accounts haven't been tested in 12+ months; nobody knows if they work
• **MFA bypass v