Chapter 18 — Security architecture | Engineering Privacy and data protection

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 18 — Security architecture

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Zones"]
  N2["18.2 Least privilege at scale"]
  N3["18.3 Privacy patterns"]
  N4["18.4 Evaluating the design"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Zones"]
  N2["18.2 Least privilege at scale"]
  N3["18.3 Privacy patterns"]
  N4["18.4 Evaluating the design"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Zones]
    |
    v
[18.2 Least privilege at scale]
    |
    v
[18.3 Privacy patterns]
    |
    v
[18.4 Evaluating the design]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) apply zones and segmentation to health data; (2) design for least privilege at scale; (3) evaluate architecture against data protection by design.

18.1 Zones

Zara divides Pellmore's architecture into zones: a public zone for the app front end, an application zone for booking and video, a restricted zone for clinical records and a management zone for administrators. Traffic between zones passes through controlled interfaces. Clinical records are reachable only from services that need them. Segmentation limits how far an attacker can move after compromising one service, and it also limits accidental access, since a misconfigured analytics job in the application zone cannot read the records zone directly.

18.2 Least privilege at scale

With dozens of services, manual permissions become unmanageable. Zara designs role templates for services and people, with permissions tied to purposes. A service account for appointment reminders can read names and appointment times but not clinical notes. Permissions are declared in configuration and reviewed automatically for changes. She explains that least privilege is not only about attackers: it also implements the purpose limitation principle in Article 5(1)(b), since each component can use data only for the purposes its role allows. Roles encode purposes.

18.3 Privacy patterns

Zara studies architectural patterns that support privacy: aggregation before data leave a zone, pseudonymisation at zone boundaries, and separate stores for identity and clinical data. She applies them to analytics: events leaving the application zone carry a pseudonymous identifier and coarse timestamps, and aggregation runs before data reach the analytics vendor. The EDPB guidelines on data protection by design describe such measures as ways to implement principles effectively, and Zara cites them when presenting her design to Pellmore's architecture board. The board approves the pattern list.

18.4 Evaluating the design

Zara evaluates the architecture with three questions: what personal data reach each zone, who can access them, and how would a failure in one zone affect others. She finds that support staff in the application zone can see full clinical notes through a support tool. She redesigns the tool to show notes only when a patient grants temporary access during a support call. The evaluation shows that architecture reviews must look at tools and people as well as servers, because many disclosures happen through legitimate interfaces used too broadly.

Worked example

Zara segments Pellmore into four zones, templates purpose-based permissions, pseudonymises and aggregates at zone boundaries and redesigns a support tool to require patient-granted access.

Synthetic case. The architecture is synthetic; GDPR Article 5(1)(b) and EDPB Guidelines 4/2019 are real.

Errors and limits

Zones on diagrams can differ from deployed reality; verify with network tests.

Exercises

EX052 — Segmentation benefit. Name two benefits of zone segmentation. Rubric: 3 = limits attacker movement and accidental access;; 2 = names one;; 1 = vague;; 0 = none.
EX053 — Purpose via roles. How does least privilege implement purpose limitation? Rubric: 3 = each component can only use data its role's purpose allows;; 2 = mentions purpose;; 1 = unrelated;; 0 = none.
EX054 — Support tool. How was the support tool redesigned? Rubric: 3 = notes visible only with temporary patient-granted access;; 2 = mentions consent;; 1 = removes tool;; 0 = none.

Synthesis

Chapter 18 designs zones and patterns. Chapter 19 covers identity and cryptography.

Continue studying — chapter 18 of 50

← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →