Chapter 39 — Identity and access management: maintainability | Engineering Identity and access management

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 39 — Identity and access management: maintainability

Lesson map

Lesson 39 published. Map, example, EX115.

flowchart TD
  N0["Learning outcomes"]
  N1["39.1 Configuration sprawl"]
  N2["39.2 Drift detection"]
  N3["39.3 Naming and ownership"]
  N4["39.4 Knowledge transfer"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX115"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["39.1 Configuration sprawl"]
  N2["39.2 Drift detection"]
  N3["39.3 Naming and ownership"]
  N4["39.4 Knowledge transfer"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX115"]

[Learning outcomes]
    |
    v
[39.1 Configuration sprawl]
    |
    v
[39.2 Drift detection]
    |
    v
[39.3 Naming and ownership]
    |
    v
[39.4 Knowledge transfer]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX115]

Learning outcomes

You will (1) keep identity configuration understandable over time; (2) control drift and sprawl; (3) plan documentation and knowledge transfer.

39.1 Configuration sprawl

Identity systems accumulate settings: groups, policies, application integrations and exceptions. Without care they become hard to understand, and nobody dares remove anything. Sana measures sprawl with simple counts tracked monthly: number of groups, groups without owners, conditional policies, applications without a named owner and active exceptions. Rising counts without matching business change signal that maintainability is slipping. Making sprawl visible lets the team decide deliberately what to clean up before it becomes unmanageable. The counts are shown in the monthly report to directors alongside the success measures.

39.2 Drift detection

Drift happens when production differs from version-controlled configuration, usually because someone made a quick change in the administration console. Sana schedules a nightly comparison between exported production settings and the repository. Differences raise a ticket: either the change is added to the repository through normal review, or it is reverted. Drift detection keeps the repository trustworthy as the single description of the system, which is essential for recovery, audits and anyone trying to understand why access behaves as it does.

39.3 Naming and ownership

Every group, role, policy and application integration follows a naming convention showing its purpose and owner, such as role-finance-clerk or app-payroll-users. Each has a named owning team and a review date. Objects without owners are flagged in the monthly report and either adopted or removed. Clear names and owners make reviews faster, because reviewers understand what they see, and they make cleanup safe, because someone can confirm whether an object is still needed before it is deleted. New objects cannot be created without both.

39.4 Knowledge transfer

Maintainability depends on people as much as configuration. Sana writes an operations guide explaining the architecture, the reasons behind key decisions, the runbooks and how to change things safely. She records short walkthrough videos of common tasks and pairs with each identity team member on real changes. The decision log from her studios explains why things are as they are. These materials matter because the identity team will change over the years, and new members must be able to work safely without her.

Worked example

Monthly sprawl metrics track five counts; nightly drift detection finds four console changes in its first month, three added to the repository after review and one reverted.

Synthetic case. Counts and drift events are synthetic.

Errors and limits

Allowing console edits without drift detection makes the repository an unreliable description of production.

Exercises

EX115 — Sprawl metrics. Name three sprawl counts Sana tracks. Rubric: 3 = groups, ownerless groups, policies, ownerless apps, exceptions (three);; 2 = two;; 1 = one;; 0 = none.
EX116 — Drift outcome. What happened to the four drift findings? Rubric: 3 = three added via review, one reverted;; 2 = resolved;; 1 = ignored;; 0 = none.
EX117 — Naming example. Give an example of Sana's naming convention. Rubric: 3 = role-finance-clerk or app-payroll-users;; 2 = example;; 1 = vague;; 0 = none.

Synthesis

Visible sprawl metrics, drift detection, clear naming and ownership, and good knowledge transfer keep identity maintainable.

Continue studying — chapter 39 of 50

← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →