Chapter 41 — Identity and access management: system optimization | 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 41 — Identity and access management: system optimization

Lesson map

Lesson 41 published. Map, example, EX121.

flowchart TD
  N0["Learning outcomes"]
  N1["41.1 What to optimise"]
  N2["41.2 Role consolidation"]
  N3["41.3 Policy streamlining"]
  N4["41.4 Measuring the effect"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX121"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["41.1 What to optimise"]
  N2["41.2 Role consolidation"]
  N3["41.3 Policy streamlining"]
  N4["41.4 Measuring the effect"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX121"]

[Learning outcomes]
    |
    v
[41.1 What to optimise]
    |
    v
[41.2 Role consolidation]
    |
    v
[41.3 Policy streamlining]
    |
    v
[41.4 Measuring the effect]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX121]

Learning outcomes

You will (1) reduce unnecessary roles, groups and exceptions; (2) streamline policies without weakening them; (3) measure the effect of optimisation.

41.1 What to optimise

After rollout, Sana looks for ways to make the system simpler and cheaper to run without weakening security. Candidates include roles that differ only slightly, groups with no members or owners, exceptions that have become routine and could be folded into a role, conditional policies that overlap, and application integrations still using older settings. Optimisation is guided by evidence from monthly sprawl metrics and access reviews, and every candidate is checked with its owner before any change is made. Candidates are ranked by expected effort saved.

41.2 Role consolidation

Using assignment and usage data, Sana finds roles whose members hold almost identical entitlements. Where two roles differ by one rarely used permission, she proposes merging them and handling that permission as an exception for the few who need it. Role mining research, such as Molloy and colleagues (2008), emphasises keeping roles meaningful to the business rather than purely statistical, so each proposed merge is discussed with the department that owns the roles. The finance roles shrink from fourteen to eight without changing anyone's needed access.

41.3 Policy streamlining

The eleven conditional access policies noted in studio II are consolidated to six. Before changing anything, Sana writes test cases capturing current intended behaviour for representative synthetic users and contexts. She then rewrites the policies and runs the tests, confirming that every intended outcome is preserved and that two unintended gaps, where certain devices escaped multi-factor prompts, are now closed. Writing tests first is what makes the optimisation safe, because simplification without tests can quietly weaken controls. The tests then join the permanent regression suite.

41.4 Measuring the effect

Sana measures the results: the number of roles, policies and exceptions; time spent on access reviews per manager; and identity team hours spent on routine tasks. Reviews take about a quarter less time because lists are shorter and clearer. She also checks that security measures have not worsened, such as leaver removal times and conflict counts. Optimisation is only a success if it reduces effort and complexity while keeping or improving security, so both sides are reported together. Results are compared with the baseline taken before optimisation.

Worked example

Finance roles fall from fourteen to eight, conditional policies from eleven to six with two gaps closed, and access review time per manager drops by about a quarter, with security measures unchanged or improved.

Synthetic case. Roles, policies and timings are synthetic.

Errors and limits

Simplifying policies without first capturing intended behaviour in tests can quietly weaken controls.

Exercises

EX121 — Finance roles. How many finance roles remain after consolidation? Rubric: 3 = eight, down from fourteen;; 2 = eight;; 1 = fourteen;; 0 = none.
EX122 — Policy gaps closed. What did policy consolidation also fix? Rubric: 3 = two gaps where devices escaped MFA prompts;; 2 = gaps;; 1 = vague;; 0 = none.
EX123 — Optimisation success test. When is optimisation a success? Rubric: 3 = less effort and complexity with security kept or improved;; 2 = both;; 1 = cost only;; 0 = none.

Synthesis

Evidence-based consolidation, tests written first and measurement of both effort and security make optimisation safe.

Continue studying — chapter 41 of 50

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