Chapter 6 — Cloud and container security: system model
Lesson map
Lesson 06 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Model"]
N2["6.2 Data"]
N3["6.3 Boundaries"]
N4["6.4 Where controls belong"]
N5["6.5 Shared responsibility"]
N6["Checking the model"]
N7["Using the model"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Model"]
N2["6.2 Data"]
N3["6.3 Boundaries"]
N4["6.4 Where controls belong"]
N5["6.5 Shared responsibility"]
N6["Checking the model"]
N7["Using the model"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[Learning outcomes]
|
v
[6.1 Model]
|
v
[6.2 Data]
|
v
[6.3 Boundaries]
|
v
[6.4 Where controls belong]
|
v
[6.5 Shared responsibility]
|
v
[Checking the model]
|
v
[Using the model]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) model Fairway's cloud system with components, data and trust boundaries; (2) identify where controls belong.
6.1 Model
Tomás draws Fairway's system: users and partners on the internet; the tracking site in the cluster; buckets for manifests, assets, backups and driver photos; the database. The diagram places partners on the internet side, where the March downloads came from, and draws the tracking site, the buckets and the database as separate components. Tomás adds arrows for every data flow he knows about. Checking the diagram against the provider's bucket list later shows that a component, the driver-photos bucket, was missing from his first draft.
6.2 Data
He labels data by sensitivity: manifests contain customer names and addresses; driver photos are personal data; assets are public by design; backups contain everything. These labels decide how strict each control on each bucket must be. A public read on the assets bucket is intended; the same setting on manifests, driver photos or backups would expose personal data. Backups are labelled the most sensitive because they combine every other kind of data, even though nobody accesses them day to day.
6.3 Boundaries
Boundaries lie between the internet and the cluster, the cluster and storage, and storage and the internet. In March the storage-to-internet boundary is the one that failed: a policy change let anyone on the internet read the manifests bucket. The cluster-to-storage boundary is crossed by the tracking site and the CI pipeline, which use service identities. Marking each crossing tells Tomás where an access decision is made and therefore where a control can be checked. Each boundary later gets at least one check or alert in the guardrail pack.
6.4 Where controls belong
Public access blocks on sensitive buckets, least-privilege identities, encryption and logging belong at the storage boundary. Placing controls there means they protect the data whichever path a request takes. A public access block works whether the request comes from a browser, a script or a partner tool, and logging records it in all cases. Controls in the tracking site's code would not have helped in March, because the anonymous reads never went through the site. The cluster boundary keeps its own controls, such as service identities and network policy, recorded separately.
6.5 Shared responsibility
The provider secures storage infrastructure; Fairway configures access, as the providers' shared responsibility pages explain. In practice the provider keeps the storage service running, encrypts disks and protects its data centres; Fairway decides who may read each bucket and whether access is logged. The March exposure sat entirely on Fairway's side: the service did exactly what the policy told it. Tomás quotes this in the review so nobody looks for the fix in the wrong place. The shared responsibility pages are cited in the policy so the division is documented, not assumed.
Checking the model
Tomás compares the model with the provider's list of buckets and finds driver-photos, created by a mobile app project, which was not on his diagram. He adds it and labels its data as personal. The comparison shows why models must be checked against real inventories: the bucket nobody remembered turns out, in chapter 11, to be the worst configured.
He also confirms the database endpoint is private by checking its network settings, not just the diagram.
Using the model
The model becomes the reference for later chapters: every check, alert and policy rule points back to a component and boundary on it. When a new service is added, the model is updated first.
Data owners
Each data type gets an owner: operations for manifests, HR for driver photos and IT for backups.
Worked example
The model shows that only the assets bucket should ever be public. Tomás marks the others as never public, which becomes a policy rule.
Synthetic case. Model is synthetic.
Errors and limits
A model is a simplification; check it against real settings.
Exercises
- EX021 — Sensitive data. Which data is most sensitive? Rubric: 3 = backups, manifests, driver photos; 2 = two; 1 = one; 0 = none.
- EX022 — Public bucket. Which bucket should be public? Rubric: 3 = assets only; 2 = partial; 1 = vague; 0 = none.
- EX023 — Storage controls. Which controls belong at the storage boundary? Rubric: 3 = public block, least privilege, encryption, logging; 2 = three; 1 = two; 0 = none.
- EX024 — Provider duty. What does the provider secure? Rubric: 3 = storage infrastructure; 2 = partial; 1 = vague; 0 = none.
Synthesis
Model data sensitivity and boundaries to place controls.
Continue studying — chapter 06 of 18
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →