Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Trust architecture"]
N2["16.2 Separation"]
N3["16.3 Backup and recovery"]
N4["16.4 Vendor architecture"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Trust architecture"]
N2["16.2 Separation"]
N3["16.3 Backup and recovery"]
N4["16.4 Vendor architecture"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Trust architecture]
|
v
[16.2 Separation]
|
v
[16.3 Backup and recovery]
|
v
[16.4 Vendor architecture]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) design a secure architecture for a multi-school trust; (2) separate sensitive data; (3) plan backup and recovery.
16.1 Trust architecture
Elena designs an architecture for the trust. A central management information system serves all twelve schools. Each school's staff see only their pupils. Safeguarding records sit in a separate, more restricted system. Classroom apps connect through single sign-on, which lets the trust control access centrally and remove it quickly. She draws the design with zones and explains why sensitive records are separated from everyday systems used by many staff. Sensitive safeguarding records sit in their own zone with separate access. Zones are documented.
16.2 Separation
Separation limits damage. If a teacher's account is compromised, the attacker can reach learning records but not safeguarding notes. Elena also separates pupil data from staff data, since different roles need each. She explains that the GDPR requires security appropriate to the risk under Article 32, and that separation is a cost-effective measure for a trust with limited security staff, because it reduces how much any single failure can expose. A compromised classroom laptop cannot reach safeguarding records directly. Rules are simple and testable.
16.3 Backup and recovery
Schools have suffered ransomware attacks. Elena designs backups that are encrypted, stored separately and tested. She sets recovery objectives: the management system restored within one day, safeguarding records within four hours, since safeguarding staff may need them urgently. She plans a restore test each term. She notes that backups also hold personal data and must follow retention rules, so old backups expire. In the first restore test, a term's attendance records are recovered in under an hour, and the restored copy is deleted afterwards so that no duplicate remains.
16.4 Vendor architecture
Many functions are provided by vendors. Elena includes vendors in the architecture diagram with their data flows and contracts. She notes that single sign-on lets the trust disable access to all apps quickly when a pupil leaves. She also sets a rule that new apps must connect through single sign-on and pass vetting. Architecture, she explains, includes rules about how new components join, not only the current components. New apps must use the trust's single sign-on. Each app joins only after vetting and appears on the architecture diagram.
Worked example
Elena designs a central system with per-school access, a separate safeguarding system, single sign-on for apps, encrypted tested backups and an onboarding rule for new apps.
Synthetic case. The architecture is synthetic; GDPR Article 32 is real.
Errors and limits
Central systems concentrate risk; protect and monitor them closely.
Exercises
- EX046 — Safeguarding separation. Why keep safeguarding records in a separate system? Rubric: 3 = a compromised teacher account cannot reach them;; 2 = mentions sensitivity;; 1 = same system;; 0 = none.
- EX047 — Single sign-on benefit. What does single sign-on give the trust? Rubric: 3 = central control and quick removal of access to all apps;; 2 = mentions control;; 1 = vague;; 0 = none.
- EX048 — Backup retention. Why must backups follow retention rules? Rubric: 3 = backups hold personal data too;; 2 = mentions data;; 1 = exempt;; 0 = none.
Synthesis
Chapter 16 designs architecture. Chapter 17 covers cryptography concepts.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →