IAM
Advanced 14 min read IAM

IAM Governance and Audit

Keeping identity status quo maintenable as you scale

Identity sprawl is real. Governance = policies as code, organizational guardrails, quarterly reviews, and audit trails that prove who could do what, when. It's how least privilege survives contact with a growing org.

IAM governanceauditpolicy as codeaccess reviewcomplianceaccess analyzer
Prerequisites: Roles and Policies Cloud Account Structure
Before we start

What you will learn

  • Apply policy-as-code and CI review
  • Run a periodic access review
  • Trace access via audit logs
In 60 seconds

IAM governance is the operational discipline: policies live in code with tests, org-level guardrails (SCP/Policy) set ceilings, and quarterly access reviews + audit logs keep entitlement reality aligned with intent.

Introduction

What is this?

Governance layer: policies as code (Terraform/Pulumi/IAM policy files) with CI lint; org guardrails (AWS SCPs, Azure Policy deny, GCP org-policy constraints); access analyzers/recommenders flag unused roles/permissions; audit trails (CloudTrail, Azure activity log, GCP logs) record each decision; quarterly access reviews certify who holds what. The point: entitlement truth is a living repo, not a diplomatic fog.

Motivation

Why do you need it?

  • Permissions rot quietly; reviews stop the 'wildcard became admin' drift.
  • Regulators ask 'show me who could access PHI last year' — audit logs answer.
  • Policy as code makes changes reviewable and revertable.
  • Organisational guardrails stop the 3am 'I'll just open port 3306' moment.
Think about it

Mental model

Imagine

A company's badge audit at year end

Think of

IAM governance

Every year the security office checks IDs against the directory, revokes lapsed ones, and writes the finding down. The directory has rules (no badge without HR), the review catches drift, and the log is the receipt.

Mechanics

How it works

  • Policies committed to a repo; reviewers approve diffs that only add precise conditions.
  • SCPs/Policy/Org-policy define the ceiling at the environment node.
  • Access Analyzer/Recommender watch cross-account/external exposure and unused privilege.
  • CloudTrail/activity logs capture every principal-action; log retention synced to compliance.
  • Quarterly reviews: export entitlements, confirm each, revoke stale.

IAM governance loop.

Policy as code
Org guardrails
Detection
Review
Audit trail
Hands-on

Examples

List roles that might be rot

List roles that might be rot
# AWS: find roles nobody assumed recently (illustrative query)
aws iam list-roles --query "Roles[?CreateDate < '2099-01-01'].[RoleName]" --output text
 
# Azure: review role assignments on a subscription
az role assignment list --scope /subscriptions/$SUB --output table
 
# GCP: recommend lower-cost members via Recommender
gcloud recommender insights list \
  --insight-type=google.iam.policy.Insight --project=$PROJ --format=table

List-role/assignment/insight commands start the review; append activity log cross-checks for proof of use.

Real world

In production

  • A platform team merges only policies that pass `checkov`/OPA — no wildcard actions — into main.
  • A security team runs quarterly access reviews exporting entitlements to a spreadsheet that sign-off managers.
  • Audit logs feed a SIEM that alerts on 'first-time use of break-glass role'.
Guidelines

Best practices

  • Automate reviews where possible, focus human review on the exceptions.
  • Ship policy-as-code with tests: assert no wildcard actions, no per-user grants.
  • Set the ceiling high and the floor right: deny default, grant only what's proven.
  • Rotate review dates with business owners; compliance is a shared calendar.
Watch out

Common mistakes

  • Reviews that 'Confirm all' quickly defeat the purpose.
  • Wildcard actions hiding in infrastructure modules.
  • No retention on audit logs, so 'who accessed PHI in Q3' is unanswerable.
  • Over-layering org rules until every new workload needs an exception — guardrails die by exception.
Root cause analysis

Common issues

Error
Review flags 'no one uses this role' but the app breaks after removal
Root cause

An automated consumer (cron, another account) used it

Fix

Check the audit log for the role's last use before removing; involve the app owner.

Error
Audit log gap for a key day
Root cause

Trail disabled or event retention expired

Fix

Enable org-level trail with long retention and lock encryption.

When things break

Debugging tips

  • When an audited action surprises: trace the exact session (identity, source IP, API) in logs.
  • If log-based forensics fail, you likely dropped retention or partition coverage.
  • Use analyzer findings as the source of next quarter's action list.
  • Cross-check policy-as-code vs the live account; drift means the pipeline was bypassed.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

What best practice makes IAM policy changes reviewable and revertable?

Go deeper

Official documentation

AWS — Access Analyzer
docs
Azure — Access reviews
docs
GCP — Recommender IAM insights
docs