Chapter 16 — Security architecture

Chapter 16 — Security architecture

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Trust boundaries"]
  N2["16.2 Defence in depth"]
  N3["16.3 Keys in the architecture"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Trust boundaries"]
  N2["16.2 Defence in depth"]
  N3["16.3 Keys in the architecture"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 Trust boundaries]
    |
    v
[16.2 Defence in depth]
    |
    v
[16.3 Keys in the architecture]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) place cryptographic controls in an overall architecture; (2) identify trust boundaries; (3) apply defence in depth to library systems.

16.1 Trust boundaries

Priya draws Tidewell's architecture with trust boundaries: lines where data passes between areas with different levels of trust, such as the internet and the portal, the portal and the patron database, and the consortium and the e-book provider. Cryptographic controls cluster at boundaries: TLS where the internet meets the portal, mutual authentication where the portal calls the database, and signed messages where the consortium exchanges loan data with the provider. Drawing boundaries first shows where cryptography is needed and where it would only add complexity.

16.2 Defence in depth

Priya layers controls so one failure does not expose patrons. The portal uses TLS and security headers; the application authenticates users and checks permissions; the database encrypts sensitive fields and accepts connections only from the portal with certificates; backups are encrypted; and logs are hash-chained. If an attacker exploited a bug in the portal, they would still face database permissions and field encryption. She documents which threats each layer addresses and avoids layers that duplicate each other without adding protection.

16.3 Keys in the architecture

Priya adds key management to the diagram, which earlier drafts left out. A managed key service holds database and backup keys; the portal's TLS private key lives on the web servers with restricted permissions; and staff security keys hold their own private keys. She marks the key service as a high-value component requiring separate administration and monitoring. Grace notes that previous architecture documents never showed keys, which made it impossible to plan rotation or assess who could decrypt what. The revised diagram is versioned.

Worked example

Priya's diagram marks three trust boundaries, five layers of defence and the location of every key, highlighting the key service as a high-value component.

Synthetic case. The architecture is invented.

Errors and limits

Layers that share a weakness, such as one admin account controlling all, do not add depth. Diagrams must be updated as systems change.

Exercises

• EX046 — Trust boundary. Name two trust boundaries in Tidewell's architecture. Rubric: 3 = two of internet-portal, portal-database, consortium-provider;; 2 = one;; 1 = vague;; 0 = none.
• EX047 — Portal bug. What would an attacker still face after exploiting a portal bug? Rubric: 3 = database permissions and field encryption;; 2 = one layer;; 1 = vague;; 0 = none.
• EX048 — Missing keys. What did earlier architecture documents omit and why did it matter? Rubric: 3 = key locations; rotation and access to decryption could not be assessed;; 2 = keys;; 1 = vague;; 0 = none.

Synthesis

Architectures should show trust boundaries, layered controls and every key, so cryptography is placed where it protects most.

Continue studying — chapter 16 of 40

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