Chapter 8 — Security architecture basics
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Segments"]
N2["8.2 Controls around data"]
N3["8.3 Vendors in the diagram"]
N4["8.4 Documentation"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Segments"]
N2["8.2 Controls around data"]
N3["8.3 Vendors in the diagram"]
N4["8.4 Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Segments]
|
v
[8.2 Controls around data]
|
v
[8.3 Vendors in the diagram]
|
v
[8.4 Documentation]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) apply segmentation and least privilege; (2) place controls around sensitive data; (3) document an architecture.
8.1 Segments
Aisha draws Quayside's architecture with segments: public app and website, head office services, club networks and CCTV. She places the membership database and heart-rate store in a restricted segment. She explains the reasoning for each boundary to the IT team. Public services face the internet and are attacked most often, so they should not reach member stores directly. Club networks are physically exposed in public buildings. CCTV produces large volumes of footage of identifiable people, and each segment has rules describing exactly which traffic may cross into another.
8.2 Controls around data
Access to the heart-rate store passes through an API that checks role and purpose. Exports require approval. Encryption protects data at rest. She explains that layered controls reduce reliance on any single measure. The API records every request with the role and stated purpose, so unusual patterns can be found later, such as a trainer reading hundreds of profiles in an evening. Export approvals go to the data protection officer for large lists. Encryption keys are managed by the cloud key service and access to keys is limited to two administrators.
8.3 Vendors in the diagram
Aisha includes vendors: payment processor, chat support, analytics and wearable strap provider. She marks which receive personal data and whether contracts exist. The mapping shows that the wearable strap provider receives raw heart-rate readings, not just zones, and that its contract does not mention retention. Aisha flags the gap for the procurement team. She also discovers that chat support transcripts are stored by the vendor for five years by default, which is far longer than Quayside needs for customer service. Aisha asks for ninety days.
8.4 Documentation
Aisha writes a short architecture document with the diagram, data flows and controls. Mr. Reilly notes that documentation helps new staff and auditors understand how member data are protected. She writes the document in plain language with a glossary for terms such as segment, API and encryption at rest. She includes a section listing known weaknesses and planned fixes, so readers do not assume the design is perfect. The document has a version number and an owner in IT who will update it after each major change.
Worked example
Aisha segments Quayside's architecture, restricts the heart-rate store behind a role-checking API, maps vendors and documents the design.
Synthetic case. The architecture is synthetic.
Errors and limits
Diagrams drift from reality; review after changes.
Exercises
- EX022 — Restricted segment. Which stores sit in the restricted segment? Rubric: 3 = membership database and heart-rate store;; 2 = one;; 1 = vague;; 0 = none.
- EX023 — Layered controls. Why use several layers of controls? Rubric: 3 = reduces reliance on any single measure;; 2 = mentions layers;; 1 = one enough;; 0 = none.
- EX024 — Vendor mapping. What does Aisha mark for each vendor? Rubric: 3 = whether it receives personal data and has a contract;; 2 = one;; 1 = vague;; 0 = none.
Continue studying — lesson 08 (chapter 08 of 30)
← Chapter 07 · Course chapter index · Chapter 09 →
Continue to the next authored lesson.