IAM Role Model

Which identities may do what to which resource, expressed through roles rather than by naming people, so that access can be reviewed.

Type Security View Stage Design Topic Identity & Access Management Area Security Architecture

flowchart LR
  subgraph who["Identities"]
    direction TB
    dev(["Developers<br/><i>group</i>"])
    sre(["SRE<br/><i>group</i>"])
    aud(["Auditors<br/><i>group</i>"])
    wl["Workload Identity<br/><i>order-api</i>"]
    ci["Pipeline Identity<br/><i>deploy-prod</i>"]
  end

  subgraph roles["Roles"]
    direction TB
    r1["Reader<br/><i>standing</i>"]
    r2["Operator<br/><i>standing</i>"]
    r3["Break-Glass Admin<br/><i>JIT — 60 min, approved, logged</i>"]
    r4["Deployer<br/><i>pipeline only</i>"]
    r5["Data Reader — Masked<br/><i>no raw PII</i>"]
  end

  subgraph what["Resources"]
    direction TB
    a1["Prod Compute"]
    a2["Prod Data Store"]
    a3["Key Vault"]
    a4["Audit Logs<br/><i>append-only</i>"]
  end

  dev --> r1 --> a1
  dev --> r5 --> a2
  sre --> r2 --> a1
  sre --> r3
  r3 --> a1
  r3 --> a2
  aud --> r1 --> a4
  wl --> r5
  wl --> a3
  ci --> r4 --> a1

What it is

The access model as three columns: identities, roles, resources — with the strict rule that nothing on the left connects to anything on the right without passing through the middle. Direct grants are the thing this artifact exists to make visible by their absence.

Human identities and workload identities both appear, because in a cloud estate the machine identities usually outnumber the people and are reviewed less often.

When you produce it

When designing a landing zone, when preparing for a certification audit, and whenever an access review takes more than a day because nobody can say what a permission actually grants.

Who reads it

Security and identity engineers who implement it. Auditors, who want to see segregation of duties and that privileged access is time-bound. Managers doing quarterly access recertification, who need roles they can understand.

What good looks like

Standing privileged access is either absent or justified in writing. Admin should be just-in-time, approved and logged, and the diagram should say so.
Workload identities are first-class and scoped to one resource each.
The pipeline identity can deploy but cannot read production data.
Audit logs are append-only and no operational role can delete them.
Every role name is meaningful to a non-specialist approver.

Common mistakes

Direct grants to individuals. They survive every reorganisation and every leaver process.
One "Admin" role held by fifteen people permanently.
Ignoring service principals. They are the most common lateral movement path and the least reviewed.
Roles named after the permission set rather than the job, so approvers rubber-stamp what they cannot interpret.