Chapter 8 — Security architecture basics

Chapter 8 — Security architecture basics

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Components and boundaries"]
  N2["8.2 Controls at boundaries"]
  N3["8.3 Recording design choices"]
  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 Components and boundaries"]
  N2["8.2 Controls at boundaries"]
  N3["8.3 Recording design choices"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Components and boundaries]
    |
    v
[8.2 Controls at boundaries]
    |
    v
[8.3 Recording design choices]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) draw system components and trust boundaries; (2) place controls at boundaries; (3) record design choices.

8.1 Components and boundaries

Lucas draws the makerspace system: member wallets, the booking web application, its database, the issuing service, the multisig, the credit contract and three nodes. He marks trust boundaries where data crosses from one owner or trust level to another: from members' devices to the web application, from the database to the issuing service and from the service to the ledger. Each boundary is a place to check inputs and permissions. The drawing becomes a shared picture for staff and developers, and he keeps it updated whenever any component changes.

8.2 Controls at boundaries

At the member boundary the web application validates every input and uses secure sessions. At the database boundary the issuing service reads only approved workshops through a read-only account. At the ledger boundary multisig signers see a summary of each grant batch before signing. The contract itself enforces a monthly cap on credits per member. Lucas lists each control beside its boundary. Placing controls at boundaries means problems are stopped close to where they enter, before they can spread through the system and become harder to trace and fix.

8.3 Recording design choices

Lucas writes short design notes explaining choices: why a permissioned ledger was chosen, why grants are batched weekly, why the cap is set at a certain level. Each note lists the alternatives considered and the reasons. When a new developer suggests removing the batch summary to save time, the note explains that it was added after a near miss. Design notes preserve reasoning that would otherwise be lost when people change. Ms Adebayo calls them the system's memory, and she asks students to write them throughout the course.

Worked example

Lucas places input validation, a read-only issuing account, batch summaries and a monthly contract cap at the system's boundaries.

Synthetic case. The architecture and notes are synthetic.

Errors and limits

Removing a control without knowing why it was added can reopen a risk it addressed.

Exercises

• EX022 — Boundary example. Name one trust boundary Lucas marks. Rubric: 3 = database to issuing service;; 2 = service to ledger;; 1 = inside the database;; 0 = none.
• EX023 — Contract control. What does the contract enforce? Rubric: 3 = a monthly cap on credits per member;; 2 = cap;; 1 = vague;; 0 = none.
• EX024 — Design note use. How did a design note help? Rubric: 3 = it explained the batch summary followed a near miss;; 2 = preserved reasoning;; 1 = it did not;; 0 = none.

Synthesis

Boundaries, controls placed at them and recorded reasoning make architecture defensible.

Continue studying — chapter 08 of 30

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