Chapter 8 — Security architecture basics | Technologist Cryptography and trust services

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 8 — Security architecture basics

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Trust boundaries"]
  N2["8.2 Placing controls"]
  N3["8.3 Single points of failure"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Trust boundaries"]
  N2["8.2 Placing controls"]
  N3["8.3 Single points of failure"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Trust boundaries]
    |
    v
[8.2 Placing controls]
    |
    v
[8.3 Single points of failure]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) draw trust boundaries for council services; (2) place TLS, signatures and encryption at the right boundaries; (3) identify single points of failure in trust infrastructure.

8.1 Trust boundaries

Rosa draws the permit service architecture with trust boundaries: between the internet and the web gateway, between the gateway and application servers, between applications and the database, and between the council and the payment provider. She marks which data crosses each boundary and how it is protected. The diagram shows that the gateway terminates TLS and forwards traffic to applications over plain HTTP inside the data centre, a design chosen years ago for simplicity. She records it as a gap.

8.2 Placing controls

Rosa proposes controls at each boundary: TLS from citizens to the gateway, TLS with mutual authentication from gateway to applications, database connections over TLS with certificate checks, HMAC-signed webhooks from the payment provider, and signed PDFs for council decisions. Owen reviews the proposal and agrees, but asks her to estimate the operational load of the extra certificates. She answers that automated issuance from the internal authority will keep the load small, which leads to the automation work in later chapters.

8.3 Single points of failure

The diagram also reveals that the internal certificate authority runs on one virtual machine without a backup of its signing key, and that the same administrator account manages it and the gateway. If the machine failed, no new internal certificates could be issued; if the account were compromised, an attacker could issue certificates and redirect traffic. Rosa recommends an encrypted backup of the authority's key held under dual control and separate administrator accounts. Both recommendations are added to the council's risk register.

Worked example

Rosa's architecture diagram reveals plain HTTP behind the gateway and a single, unbacked internal CA, and she proposes boundary controls and dual-controlled backups.

Synthetic case. The architecture is invented.

Errors and limits

Internal networks are not automatically trustworthy. More certificates mean more operations unless issuance is automated.

Exercises

EX022 — Internal gap. What gap did the diagram reveal behind the gateway? Rubric: 3 = traffic forwarded to applications over plain HTTP;; 2 = plain HTTP;; 1 = vague;; 0 = none.
EX023 — Webhook control. Which control protects payment webhooks? Rubric: 3 = HMAC signatures from the payment provider;; 2 = HMAC;; 1 = TLS only;; 0 = none.
EX024 — CA weakness. Why is the internal CA a single point of failure? Rubric: 3 = one VM without key backup, managed by the same account as the gateway;; 2 = both;; 1 = one;; 0 = none.

Synthesis

Drawing trust boundaries places cryptographic controls where they matter and exposes fragile trust infrastructure.

Continue studying — chapter 08 of 30

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →