Chapter 21 — Cloud and container security: system models
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Components"]
N2["21.2 Identities"]
N3["21.3 Data flows"]
N4["21.4 Trust boundaries"]
N5["21.5 Finding gaps"]
N6["21.6 Keeping current"]
N7["Drawing the model"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Components"]
N2["21.2 Identities"]
N3["21.3 Data flows"]
N4["21.4 Trust boundaries"]
N5["21.5 Finding gaps"]
N6["21.6 Keeping current"]
N7["Drawing the model"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Components]
|
v
[21.2 Identities]
|
v
[21.3 Data flows]
|
v
[21.4 Trust boundaries]
|
v
[21.5 Finding gaps]
|
v
[21.6 Keeping current]
|
v
[Drawing the model]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) model StudyHub's components, identities and data flows; (2) identify trust boundaries; (3) find missing controls from the model; (4) keep the model current.
21.1 Components
Load balancer, web front end, records-api, coursework service, message queue, managed database, storage buckets, registry, build system, identity provider, log account.
Listing every component, including supporting ones such as the message queue and the log account, ensures none is forgotten when flows are drawn. The registry and build system are on the list because the opening case showed they belong to the attack surface as much as the services students use. Each component has an owner in the model, which tells reviewers whom to ask about it.
21.2 Identities
Each service has a Kubernetes service account mapped to a cloud identity; people sign in through the identity provider; the build system has its own identity.
Mapping each service account to a cloud identity means records-api's pods can reach the database with credentials that are issued at run time and limited to that service. The build system's identity is separate, so a compromise of the build cannot be used to read student records directly. The model lists each identity's permissions beside it, so reviewers can compare them with the flows the identity takes part in. Permissions with no matching flow are candidates for removal.
21.3 Data flows
Students to web; web to records-api; records-api to database; coursework service to storage; build to registry; registry to cluster; all accounts to logs.
Each flow has a source, a destination and a purpose. Drawing them shows, for example, that the coursework service writes to storage but never reads the database, which tells reviewers its identity needs no database access. Flows into the log account come from every account, so that boundary is the most widely used. Samuel numbers the flows so findings can refer to them briefly.
21.4 Trust boundaries
Marked where flows cross networks, accounts or identity domains. Shostack's (2014) question "what can go wrong?" is asked at each boundary.
At the boundary between the build system and the registry, the answer to Shostack's question was the opening case: anyone could pull images. At the boundary between the cluster and the database, it is a stolen connection string, which the network rule and now short-lived credentials address. Samuel writes the answers beside each boundary on the model, with the control that addresses each one. Boundaries with no listed control stand out immediately and go to the backlog.
21.5 Finding gaps
For each flow, Samuel checks authentication, authorisation, encryption and logging. Gaps become backlog items.
The flow from the coursework service to storage passed authentication and encryption but failed authorisation, because the role allowed deleting any object, as the worked example below shows. Logging was present. Recording all four checks per flow makes it obvious which control is missing. In total, the first pass across all StudyHub flows found a handful of gaps, each turned into a backlog item with an owner. The most serious, the coursework role, was fixed within the week; others, such as missing logging on the message queue, were scheduled for later sprints.
21.6 Keeping current
The model is stored with the infrastructure code and updated in the same pull request as architecture changes.
Updating the model in the same pull request ties it to the change that requires it. A reviewer who sees a new flow in the code but no update to the model can ask for one before approving. This keeps the model from becoming a picture of last year's system. The model is also reviewed once a term against flow logs, as described next, to catch flows that were added without anyone updating it.
21.7 Model limits
The model shows intended flows; flow logs show actual flows. Comparing them finds surprises.
Comparing the model with flow logs found one surprise: an old reporting job still connected directly to the database, a flow not on the model. It was the same analytics job described in the privacy chapter; its connection was added to the model and narrowed to read-only when the job was changed to produce counts directly. Samuel now runs the comparison each term. Flows that appear in the logs but not the model are investigated; flows that appear in the model but not the logs may be dead and are checked with their owners before removal.
Drawing the model
Samuel draws the model in a simple text-based diagram format stored in the repository, so changes appear in pull request diffs like code. Each box has an owner and a link to its configuration. Reviewers can see when a new flow is added without a matching update to authentication or logging. The format is also easy for screen readers, which matters for one colleague on the team.
Worked example
The model shows the coursework service writes to storage using a role that can also delete any object in the bucket. Students' submissions could be deleted by a bug. The role is narrowed to write-only for new objects, and deletion is reserved for a retention job.
Synthetic case. The model is synthetic.
Errors and limits
Models omit details; verify important assumptions with real configuration.
Exercises
- EX061 — Per-flow checks. What is checked for each flow? Rubric: 3 = authn, authz, encryption, logging; 2 = three; 1 = one; 0 = none.
- EX062 — Model vs reality. How are surprises found? Rubric: 3 = compare model with flow logs; 2 = partial; 1 = vague; 0 = none.
- EX063 — Coursework role. What was wrong with the coursework role? Rubric: 3 = could delete any object; 2 = partial; 1 = vague; 0 = none.
Synthesis
Models of flows and identities reveal missing controls.
Continue studying — chapter 21 of 40
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →