Chapter 27 — Identity and access management: control design
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Authentication policy"]
N2["27.2 Separation of duties checks"]
N3["Lab — Conflict scan"]
N4["27.3 Reading the conflicts"]
N5["27.4 Sessions and administrators"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Authentication policy"]
N2["27.2 Separation of duties checks"]
N3["Lab — Conflict scan"]
N4["27.3 Reading the conflicts"]
N5["27.4 Sessions and administrators"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Authentication policy]
|
v
[27.2 Separation of duties checks]
|
v
[Lab — Conflict scan]
|
v
[27.3 Reading the conflicts]
|
v
[27.4 Sessions and administrators]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) specify authentication, authorisation and session controls; (2) design separation-of-duties checks; (3) design administrator protections.
27.1 Authentication policy
Sana specifies authentication policy at the provider. All staff use multi-factor authentication; passkeys on council laptops and phones are the default; security keys serve shared and depot devices. Administrators must use phishing-resistant authenticators at all times. Conditional rules require stronger checks for unusual contexts, such as a new device. Following NIST SP 800-63B-4, she avoids periodic forced password changes, which encourage weak patterns, and instead requires changes when compromise is suspected. Each rule is written in a policy table that both people and test scripts can read.
27.2 Separation of duties checks
Separation-of-duties rules are listed as pairs of entitlements that must never be held by one identity, such as raising and approving payments, editing vendor details and approving payments, or editing staff records and running payroll. Sana designs two checks: a preventive check that blocks role assignments creating a conflict, and a detective check that scans all assignments nightly and reports any conflicts that slipped through, for example via exceptions or application-level grants outside the role model. Both checks use the same rule list, so they cannot drift apart.
Lab — Conflict scan
"""Check synthetic role assignments against separation-of-duties rules (stdlib only)."""
roles = {"clerk": {"pay-raise"}, "approver": {"pay-approve"}, "vendor-admin": {"vendor-edit"}, "payroll": {"payroll-run"},
"hr-admin": {"staff-edit"}, "auditor": {"audit-read"}}
rules = [("pay-raise", "pay-approve"), ("vendor-edit", "pay-approve"), ("staff-edit", "payroll-run")]
users = {"s01": ["clerk"], "s02": ["clerk", "approver"], "s03": ["approver", "vendor-admin"], "s04": ["payroll"],
"s05": ["hr-admin"], "s06": ["hr-admin", "payroll"], "s07": ["auditor"], "s08": ["approver"]}
bad = 0
for u, rs in sorted(users.items()):
p = set().union(*(roles[r] for r in rs))
for a, b in rules:
if a in p and b in p: bad += 1; print(f"conflict {u}: {a} + {b} via {rs}")
print(f"users={len(users)} rules={len(rules)} conflicts={bad}")
Run with python3 lab_sod.py. Verified output:
conflict s02: pay-raise + pay-approve via ['clerk', 'approver']
conflict s03: vendor-edit + pay-approve via ['approver', 'vendor-admin']
conflict s06: staff-edit + payroll-run via ['hr-admin', 'payroll']
users=8 rules=3 conflicts=3
27.3 Reading the conflicts
The synthetic scan of eight users and three rules finds three conflicts: s02 can raise and approve payments; s03 can edit vendor details and approve payments; s06 can edit staff records and run payroll. Each conflict goes to the relevant manager, who either removes one role or documents a compensating control, such as a second approver for that person's payments, with an expiry date. The detective scan matters because preventive checks only see assignments made through the identity system, not those granted directly inside applications.
27.4 Sessions and administrators
Session controls limit how long access lasts: tokens expire within an hour, sessions require re-authentication daily and immediately on sensitive actions, and disabling an identity revokes its sessions. Administrators use separate administrator accounts, not their everyday accounts, sign in only from managed administration workstations, and receive elevated rights just in time for a defined period. Every administrator action is logged to a store the administrators themselves cannot alter. These controls limit what a stolen session or a compromised administrator account can do.
Worked example
The policy table defines default passkeys, phishing-resistant administrators and no periodic password changes; the conflict scan finds three synthetic conflicts, each resolved or covered by a documented compensating control.
Synthetic case. Policies, users and conflicts are synthetic.
Errors and limits
Relying only on preventive checks misses conflicts granted directly inside applications.
Exercises
- EX079 — Conflict count. How many conflicts does the lab scan find? Rubric: 3 = three: s02, s03, s06;; 2 = three;; 1 = vague;; 0 = none.
- EX080 — Detective need. Why is a nightly detective scan needed? Rubric: 3 = preventive checks miss grants made inside applications;; 2 = app grants;; 1 = speed;; 0 = none.
- EX081 — Admin separation. How are administrator accounts separated? Rubric: 3 = separate admin accounts, managed workstations, just-in-time rights;; 2 = separate accounts;; 1 = shared;; 0 = none.
Synthesis
Clear authentication policy, preventive and detective separation checks, and tight session and administrator controls form the core control design.
Continue studying — chapter 27 of 50
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →