OpenCyber AcademyLesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Systems and accounts"]
N3["1.3 Scope and permission"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Systems and accounts"]
N3["1.3 Scope and permission"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The case]
|
v
[1.2 Systems and accounts]
|
v
[1.3 Scope and permission]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) describe the identity services a dental practice depends on; (2) map accounts to systems; (3) set the course scope.
1.1 The case
Tomas Novak is a trainee on the eighteen-month technical course at the fictional Ridgeway Technical College. His instructor, Priya Raman, places him with the fictional Millbrook Dental Practice, which has two surgeries and 28 staff: dentists, dental nurses, receptionists, a practice manager and two people who share IT duties. Over the course Tomas will configure, verify, troubleshoot and document access control under supervision. Every account, log and figure in this book is synthetic, and every change he makes is agreed in advance with the practice manager.
1.2 Systems and accounts
Tomas lists Millbrook's systems: a cloud directory with email and documents, a dental records system holding patient charts and X-ray images, an appointment system, a card payment terminal and a payroll service. For each he records how people sign in, who administers it and what sensitive data it holds. He finds that the directory controls email and appointments, while dental records and payroll keep their own accounts. That split tells him where leavers could be missed and where single sign-on could later help.
1.3 Scope and permission
Priya insists on written scope before Tomas touches anything. The practice manager signs a short document stating which systems he may view, which settings he may change with approval, and that he must not access patient records beyond what configuration requires. Tomas keeps the document with his notes. Written scope protects patients, the practice and Tomas himself, because it makes clear that every action he takes is authorised and expected rather than a surprise to the people responsible. Priya reviews the scope with him at each monthly supervision meeting.
Worked example
Tomas lists five systems; two rely on the directory, two keep separate accounts, and his signed scope covers configuration but not browsing patient records.
Synthetic case. Tomas Novak, Priya Raman, Ridgeway Technical College, Millbrook Dental Practice and all data are synthetic.
Errors and limits
Starting configuration work without written scope leaves unclear who authorised each change.
Exercises
- EX001 — Practice size. How many surgeries and staff does Millbrook have?
Show marking criteria
Rubric: 3 = two surgeries, 28 staff;; 2 = 28;; 1 = one;; 0 = none. - EX002 — Separate accounts. Which systems keep separate accounts?
Show marking criteria
Rubric: 3 = dental records and payroll;; 2 = two;; 1 = email;; 0 = none. - EX003 — Scope limit. What does the scope forbid?
Show marking criteria
Rubric: 3 = accessing patient records beyond configuration needs;; 2 = patient records;; 1 = vague;; 0 = none. - EX004 — Scope benefit. Who does written scope protect?
Show marking criteria
Rubric: 3 = patients, the practice and Tomas;; 2 = everyone;; 1 = nobody;; 0 = none.
Synthesis
A system list and written scope are the starting point for any supervised identity work.