Chapter 16 — Access control

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Principles"]
  N2["16.2 Role-based access"]
  N3["16.3 Joiners, movers and leavers"]
  N4["16.4 Privileged access"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Principles"]
  N2["16.2 Role-based access"]
  N3["16.3 Joiners, movers and leavers"]
  N4["16.4 Privileged access"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 Principles]
    |
    v
[16.2 Role-based access]
    |
    v
[16.3 Joiners, movers and leavers]
    |
    v
[16.4 Privileged access]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) apply least privilege and need to know; (2) design role-based access; (3) manage joiners, movers and leavers.

16.1 Principles

Aisha learns two principles for access control. Least privilege means each person or program has only the access needed for their task. Need to know means access to information is limited to those who need it for their work. Saltzer and Schroeder listed least privilege among their 1975 design principles. At Ashfield, tellers need to view member balances but not approve loans; lending officers need loan records but not ledger entries. She writes a short example for each role showing what it can and cannot see in the core system.

16.2 Role-based access

Aisha designs roles for Ashfield: teller, lending officer, finance and IT. Each role has a defined set of application permissions. New staff receive their role's permissions rather than copying a colleague's, which often brings extra rights. She documents each role's permissions in a table approved by information owners. Dr. Carrow notes that roles make access easier to review, because reviewers can compare people with their role instead of judging each permission individually. The information owners sign the table, and IT uses it for every new account.

16.3 Joiners, movers and leavers

Access changes when people join, change roles or leave. Aisha maps Ashfield's process. Joiners are set up by IT after a request from human resources. Movers often keep old access because nobody removes it. Leavers' accounts are disabled when IT is told, which sometimes happens days later. She recommends that human resources trigger all three events automatically and that movers' old access be removed by default. Human resources agrees to send a notice to IT on the same day for each event. Aisha drafts the notice template.

16.4 Privileged access

Administrator accounts can change systems and access all data. Aisha recommends separate administrator accounts used only for administration, protected by multi-factor authentication and logged. Daily work uses normal accounts. She finds that one shared administrator account is used by both IT staff and a supplier. She recommends individual accounts so actions can be traced. Dr. Carrow notes that privileged accounts are the main target for attackers after initial entry. The supplier receives its own named account, which is enabled only when it has an approved support request open.

Worked example

Aisha applies least privilege and need to know, designs four roles, maps joiner, mover and leaver gaps and separates privileged accounts.

Synthetic case. Roles are synthetic.

Errors and limits

Copying a colleague's access often grants unneeded rights.

Exercises

• EX046 — Teller access. What do tellers need?
  Show marking criteria

  Rubric: 3 = view balances, not approve loans;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX047 — Mover problem. What happens to movers' old access?
  Show marking criteria

  Rubric: 3 = it is often kept;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX048 — Shared admin. Who shares the administrator account?
  Show marking criteria

  Rubric: 3 = IT staff and a supplier;; 2 = partly correct;; 1 = vague;; 0 = none.