Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Layers"]
N2["16.2 Trust boundaries"]
N3["16.3 Environments"]
N4["16.4 Secrets architecture"]
N5["16.5 Third-party scripts"]
N6["16.6 Decision records"]
N7["16.7 Reviews"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Layers"]
N2["16.2 Trust boundaries"]
N3["16.3 Environments"]
N4["16.4 Secrets architecture"]
N5["16.5 Third-party scripts"]
N6["16.6 Decision records"]
N7["16.7 Reviews"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Layers]
|
v
[16.2 Trust boundaries]
|
v
[16.3 Environments]
|
v
[16.4 Secrets architecture]
|
v
[16.5 Third-party scripts]
|
v
[16.6 Decision records]
|
v
[16.7 Reviews]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) design layered defences for a web application; (2) place trust boundaries; (3) separate environments; (4) record architecture decisions.
16.1 Layers
CampusEats' defences are layered: the hosting platform's firewall and rate limits at the edge; validation, encoding and authorisation in the application; least-privilege database accounts and encryption for data; and a pipeline that checks code and dependencies before anything is deployed. If one layer fails, others still protect students.
Lena maps each layer to the failures it covers, so the society can see where a single mistake would be caught and where it would not. For example, an encoding mistake in a review page would still meet the content policy in the browser.
16.2 Trust boundaries
Boundaries separate the browser from the server, the server from the database, CampusEats from the payment provider, and the build from the internet. At each boundary, data is checked: requests are validated, payment callbacks are verified (chapter 17), downloaded packages are hash-checked (chapter 22).
Lena marks each boundary on her diagram with the check that happens there. A boundary with no check is a gap to fix or to record as an accepted risk. Lena reviews the boundaries with the society whenever a new external service is added.
16.3 Environments
Development, test and production are separate, with separate secrets. The leaked token was a test key; because test and production were separate, the leak could not touch real payments. Lena records this as evidence that separation limited harm.
Test data contains no real student details, and production secrets are available only to the deployed service and the two administrators. Separation costs some convenience, since bugs sometimes appear only in production, but the leak showed its value clearly. The decision is now written up as a record.
16.4 Secrets architecture
Secrets live in the platform's secret store, scoped per environment, rotated each term and when people leave.
Rotation each term limits how long a leaked secret stays useful, and rotation when people leave removes access they no longer need. Lena checks that rotating a key needs no code change, only an update in the store and a restart. Each secret has a named owner and a record of when it was last rotated, which the society reviews at the start of term.
16.5 Third-party scripts
Only two third-party browser scripts remain, both loaded from CampusEats' own domain at pinned versions with integrity hashes.
Hosting them on CampusEats' own domain means a compromise of the original provider cannot change what students receive, and the integrity hash makes the browser refuse a modified file. Updating either script is a deliberate change: the new version is reviewed, its hash recorded and the change tested before deployment. Lena removed a third script during the privacy review. Each pinned version is recorded.
16.6 Decision records
Each architecture choice is recorded briefly: context, options, decision, consequences. When new members ask "why is it like this?", the record answers.
Records are a page or less and stored with the code. Lena writes one for keeping test and production separate, citing the token leak, so the reason is not lost when the members who lived through it graduate. Records are not rewritten later; a changed decision gets a new record that refers to the old one. New members read them first.
16.7 Reviews
Grace reviews architecture changes that cross a trust boundary, such as adding a new external service.
She asks for a short description of the change, an updated diagram and the decision record. Changes inside a boundary, such as a new page using existing data, are reviewed by other society members using the code review checklist. This keeps Grace's time for the changes most likely to introduce new risks and makes reviews predictable for the developers. Grace's reviews take about a week.
Monitoring
Logs from each layer feed one dashboard, so problems at any layer are seen quickly.
Worked example
A member proposes letting the café tills connect directly to the CampusEats database for speed. Lena's review notes this would cross a trust boundary and give till machines database credentials. Instead, the tills use a narrow API with its own role, rate-limited and logged.
Synthetic case. The architecture is synthetic.
Errors and limits
Architecture diagrams drift from reality; check configuration regularly.
Exercises
- EX046 — Layers. List the four layers of defence. Rubric: 3 = edge, application, data, pipeline; 2 = three; 1 = one; 0 = none.
- EX047 — Separation evidence. How did environment separation limit the token leak? Rubric: 3 = test key could not reach real payments; 2 = partial; 1 = vague; 0 = none.
- EX048 — Till proposal. What replaced direct database access for tills? Rubric: 3 = narrow API with own role, rate-limited, logged; 2 = partial; 1 = vague; 0 = none.
Synthesis
Layer defences, guard boundaries and separate environments.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →