Chapter 7 — Identity and access foundations
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Developer access"]
N2["7.2 Client access"]
N3["7.3 Service accounts"]
N4["7.4 Tokens"]
N5["7.5 Access reviews"]
N6["7.6 Role design"]
N7["Leaver checklist"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Developer access"]
N2["7.2 Client access"]
N3["7.3 Service accounts"]
N4["7.4 Tokens"]
N5["7.5 Access reviews"]
N6["7.6 Role design"]
N7["Leaver checklist"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]
[Learning outcomes]
|
v
[7.1 Developer access]
|
v
[7.2 Client access]
|
v
[7.3 Service accounts]
|
v
[7.4 Tokens]
|
v
[7.5 Access reviews]
|
v
[7.6 Role design]
|
v
[Leaver checklist]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) manage developer and client access to systems; (2) apply multi-factor authentication; (3) use roles and least privilege; (4) review access regularly.
7.1 Developer access
Developers sign in to code hosting, the build service and the hosting platform with multi-factor authentication. Each has only the roles needed: most can deploy to test environments; only two can deploy to production. Limiting production deployment to two developers means a stolen test-environment account cannot change a live client site. When the former contractor's access is found in the first review, this split is why the exposure was limited to deploy rights on three projects rather than every client.
7.2 Client access
Clinic staff log into their booking admin pages with their own accounts; shared logins are not allowed. OWASP Top 10:2021 A07 covers identification and authentication failures. Personal accounts mean Greenleaf's log shows which receptionist changed a booking. A shared login would hide that, and nobody could remove one leaver's access without changing everyone's password. When a receptionist leaves a clinic, the manager disables that one account without disturbing anyone else's work. OWASP's description of A07 lists shared and weak credentials among common causes, which is why Brightwave refuses shared clinic logins even when a client asks for one to save time.
7.3 Service accounts
The build service uses a dedicated identity with permission to push images, not a developer's personal token. Before this change, an image push from the build ran under whichever developer had set the pipeline up. If that developer left, the pipeline either broke or kept a leaver's credential alive. A dedicated build identity can be given exactly the rights to push images and nothing more, and its use appears separately in the platform's logs. If the build identity were ever misused, its permissions would limit the damage to pushing images, which the approved-image rule later checks as well.
7.4 Tokens
Long-lived tokens are replaced with short-lived ones where the platform allows, reducing harm if a token leaks. A short-lived token copied into a log or a chat message by mistake stops working within hours rather than staying valid for months. Diego lists which of Brightwave's platforms still require long-lived tokens so they can be rotated on a schedule instead. A long-lived token found in an old repository would remain dangerous long after anyone remembered creating it. Short-lived tokens make the build identity's access expire on its own unless the pipeline requests a new one for the next run.
7.5 Access reviews
Every quarter Diego lists who has which access and asks owners to confirm. Leavers' access is removed on their last day. The first review is the one that finds the former contractor still able to deploy to three client projects. Diego's list goes to each platform owner, who confirms every name individually. Owners are asked to confirm each person and role, not to approve the whole list at once. Leavers are checked against the leaver checklist, so a missing tick shows which platform still needs attention. The review record is kept, so the next quarter's review can compare names and show what changed in between.
7.6 Role design
Roles for clinic staff: receptionist (manage bookings), vet (view records), manager (settings and staff). Checks happen on the server. Greenleaf's roles also decide who could reach the old CSV export that Diego's data-flow diagram later uncovers. Because the export checked only that a user was logged in, receptionists could download every booking, which their role never needed. Checks on the server, not hidden buttons in the page, are what stop a receptionist's account from reaching manager functions. Diego tests each of the three roles with a synthetic account before release.
Leaver checklist
The leaver checklist now lists every place access might exist: code hosting, the build service, the hosting platform, the image registry, client admin pages used for support, and shared password vaults. Each line is ticked by a named person on the leaver's last day, and the record is kept with the access review. Diego also asks the platform owners to send a monthly list of accounts with no sign-in in 60 days, since unused accounts are often forgotten accounts. The first such list finds four, all removed after confirming with their owners.
Worked example
The first access review finds a former contractor still able to deploy to three client projects. Access is removed the same day, and the leaver checklist gets a line for build and hosting access.
Synthetic case. Accounts and findings are synthetic.
Errors and limits
Access reviews only help if owners check carefully; ask them to confirm each name, not approve the list in bulk.
Exercises
- EX019 — Production deploy. Who can deploy to production? Rubric: 3 = only two developers; 2 = partial; 1 = vague; 0 = none.
- EX020 — Build identity. What identity does the build service use? Rubric: 3 = dedicated identity, not personal token; 2 = partial; 1 = vague; 0 = none.
- EX021 — Review finding. What did the first review find? Rubric: 3 = former contractor with deploy access; 2 = partial; 1 = vague; 0 = none.
Synthesis
Strong sign-in, least privilege and regular reviews keep access under control.
Continue studying — chapter 07 of 30
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →