Chapter 13 — Identity and access
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Least privilege"]
N2["13.2 Staff accounts"]
N3["13.3 Admin accounts"]
N4["13.4 Shared accounts"]
N5["13.5 Reviews"]
N6["MFA for admins"]
N7["Separation of duties"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Least privilege"]
N2["13.2 Staff accounts"]
N3["13.3 Admin accounts"]
N4["13.4 Shared accounts"]
N5["13.5 Reviews"]
N6["MFA for admins"]
N7["Separation of duties"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Least privilege]
|
v
[13.2 Staff accounts]
|
v
[13.3 Admin accounts]
|
v
[13.4 Shared accounts]
|
v
[13.5 Reviews]
|
v
[MFA for admins]
|
v
[Separation of duties]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) apply least privilege to staff and admins; (2) use named admin accounts and MFA; (3) review access.
13.1 Least privilege
Saltzer and Schroeder (1975) described least privilege: each user and program gets only the access it needs.
At Bramley the principle applies to people and to programs. A housing officer needs to read and edit tenant files but not to install drivers, so a standard account is enough. The backup agent needs to read every shared folder but not to change system settings. Aisha lists each account's real needs before any rights are removed. The same reasoning applies to Aisha herself, whose read-only access to device reports is the least privilege her project needs.
13.2 Staff accounts
Staff become standard users; software requests go to Gareth.
The change affects the 25 laptops whose users still hold local admin rights. Staff keep everything they need for daily work: email, the housing system, documents and printing. When they need new software, they send a request and Gareth installs it centrally, which also means every installed program is recorded in the management server. Gareth aims to answer each request within two working days, which keeps staff from looking for ways around the new restrictions.
13.3 Admin accounts
Gareth and the contractor use separate named admin accounts with multi-factor authentication, used only for admin tasks.
The named accounts are it-gareth and it-contractor, the same names that appear in the logon review lab. Gareth signs in to his daily account for email and documents, and to it-gareth only for server and management tasks. A phished daily password therefore gives no admin access, and the second factor protects the admin accounts themselves. The contractor's account is also enabled only for agreed maintenance windows, so outside those windows it cannot be used even with the correct password and second factor.
13.4 Shared accounts
The old shared admin account is disabled so actions can be traced to people.
A shared account means a log entry can show that "admin" signed in, but never which person did. Disabling it is the change Gareth made after Aisha reported it, and each person now uses a named account. The later logon review still flags "admin" on S04 at 02:47, because a scheduled task had not yet moved to another account. Aisha adds the default account to the weekly logon review, so any further use of it is flagged until it is fully disabled.
13.5 Reviews
Admin group membership is reviewed monthly.
The monthly review is short: Gareth exports the members of each admin group and compares them with the access register Aisha created. Anyone not on the register is removed or added to it with a reason. The contractor approves Gareth's own entries, so nobody reviews only their own access. Each monthly review is saved with its date as evidence for later audits. Aisha's access register lists each admin account, the systems it can reach and the reason, which is what the monthly review compares group membership against.
MFA for admins
Multi-factor authentication means an admin needs something they know and something they have. If a password is phished, the attacker still lacks the second factor. Bramley uses an authenticator app for Gareth and the contractor.
Aisha also checks whether remote access for staff uses MFA; it does not yet, so it becomes a recommendation for later work.
She documents who holds admin rights on each system and why, creating the first version of an access register.
Separation of duties
The contractor cannot approve their own access changes; Gareth approves them, and vice versa.
Reading the evidence
Aisha compares two sources for this chapter: the relevant NIST guidance and a research paper. The guidance tells her what organisations should do; the paper tells her what tends to happen in practice. Where they differ, she notes the gap and asks which applies to an organisation of Bramley's size. This habit of reading both kinds of source carefully is one the tutor stresses throughout the course.
Worked example
Removing local admin rights from 25 laptops leads to five requests for software in the first week; Gareth installs them centrally, and requests drop after.
Synthetic case. Synthetic.
Errors and limits
Removing rights without a request process creates frustration and workarounds.
Exercises
- EX037 — Principle. Who described least privilege? Rubric: 3 = Saltzer and Schroeder 1975; 2 = partial; 1 = vague; 0 = none.
- EX038 — Admin use. How are admin accounts used? Rubric: 3 = named, MFA, admin tasks only; 2 = two; 1 = one; 0 = none.
- EX039 — First week. What happened after removing admin rights? Rubric: 3 = five requests, installed centrally; 2 = partial; 1 = vague; 0 = none.
Synthesis
Least privilege needs a support process.
Continue studying — chapter 13 of 40
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →