Chapter 19 — Identity and access management: scope and theory
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Scope of IAM"]
N2["19.2 Least privilege and separation of duties"]
N3["19.3 Access control models"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Scope of IAM"]
N2["19.2 Least privilege and separation of duties"]
N3["19.3 Access control models"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Scope of IAM]
|
v
[19.2 Least privilege and separation of duties]
|
v
[19.3 Access control models]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) define the scope of IAM; (2) explain least privilege and separation of duties; (3) relate access control models to Greenhill.
19.1 Scope of IAM
Identity and access management covers how identities are created, verified and removed; how access is granted, reviewed and revoked; and how actions are logged and checked. It includes people, such as staff and contractors, and non-human identities, such as service accounts used by systems. At Greenhill, Elena's scope covers staff and contractors across six systems, plus two service accounts used by the finance system to send payment files. Stating scope prevents her from drifting into unrelated areas such as network firewalls.
19.2 Least privilege and separation of duties
Saltzer and Schroeder (1975) described least privilege: each person or program should have only the access needed for its job. Separation of duties adds that no single person should complete a sensitive task alone, such as setting up a new supplier and paying them. In Greenhill's finance system, Elena finds one officer who can do both. She reports it, and the finance manager agrees that a second person will approve new suppliers, a small change that removes a serious risk.
The same check is worth repeating whenever finance staff change roles, since a mover can quietly end up holding both permissions.
19.3 Access control models
Role-based access control gives access through roles linked to jobs, as described by Sandhu and colleagues (1996). It suits Greenhill, where most staff in a team need the same access. Attribute-based access control, described in NIST SP 800-162, decides using attributes such as department or location, which suits finer rules. Elena recommends roles for Greenhill, implemented as team groups, with a short list of documented exceptions, because a small organisation benefits from the simplest model that works. Exceptions are reviewed each quarter.
Worked example
Elena's scope covers staff, contractors and two service accounts across six systems; she finds one finance officer able to create and pay suppliers, fixed by adding second approval.
Synthetic case. Systems, officers and accounts are synthetic; the cited papers and NIST SP 800-162 are real.
Errors and limits
Ignoring service accounts leaves powerful non-human identities unmanaged.
Exercises
- EX055 — Non-human identity. Give an example of a non-human identity at Greenhill. Rubric: 3 = finance service account sending payment files;; 2 = service account;; 1 = tenant;; 0 = none.
- EX056 — Supplier conflict. What separation-of-duties problem did Elena find? Rubric: 3 = one officer could set up and pay suppliers;; 2 = create and pay;; 1 = vague;; 0 = none.
- EX057 — Model choice. Which access model does Elena recommend for Greenhill? Rubric: 3 = role-based via team groups, few exceptions;; 2 = roles;; 1 = attributes;; 0 = none.
Synthesis
Clear scope, least privilege, separation of duties and a simple role model form the theory behind Greenhill's IAM.
Continue studying — chapter 19 of 40
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →