◇ OpenCyber Academy
Engineering · Chapter 22 · English

Chapter 22 — Cloud and container security: system and data models

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 22 — Cloud and container security: system and data models

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 Component model"]
  N2["22.2 Identity model"]
  N3["22.3 Data model"]
  N4["22.4 Data flows"]
  N5["22.5 Trust boundaries"]
  N6["22.6 Using the model"]
  N7["Generating the model"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 Component model"]
  N2["22.2 Identity model"]
  N3["22.3 Data model"]
  N4["22.4 Data flows"]
  N5["22.5 Trust boundaries"]
  N6["22.6 Using the model"]
  N7["Generating the model"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
    |
    v
[22.1 Component model]
    |
    v
[22.2 Identity model]
    |
    v
[22.3 Data model]
    |
    v
[22.4 Data flows]
    |
    v
[22.5 Trust boundaries]
    |
    v
[22.6 Using the model]
    |
    v
[Generating the model]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) model meterhub's components, identities and data flows; (2) classify data; (3) mark trust boundaries; (4) use the model to find missing controls.

22.1 Component model

Components: load balancer, ingest service, message queue, time-series database, API, billing export job, analytics workspace, metrics stack, pipeline, image registry, secret manager, backup account.

Listing every component, including less obvious ones like the backup account and secret manager, ensures none is left out of later analysis. Each becomes a node in the data-flow and identity models. Elena checks the list against the cloud inventory and the cluster's running workloads, and finds an old reporting job nobody had mentioned. The job is added and given an owner.

22.2 Identity model

Each component has an identity: Kubernetes service accounts mapped to cloud roles, pipeline federated identity, human roles. The model lists what each identity can do, which reveals over-broad roles.

Writing down what each identity can do often reveals surprises. The billing export job can write to the readings it only needs to read. A pipeline role has rights to delete clusters that no pipeline task uses. Each over-broad permission is a risk if that identity is compromised, so the model drives a clean-up list.

22.3 Data model

Data classes: readings (personal, high), customer details (personal, high), aggregated statistics (internal), logs (may contain personal data), images (internal, may contain secrets). Each class has storage, retention and access rules.

Classifying data decides how it is handled. High-sensitivity personal data gets the strictest access and shortest retention; internal statistics can be shared more widely. Logs and images are classed as possibly sensitive because they can contain personal data or secrets by accident, which justifies scanning them. Elena tags each storage location in the cloud account with its data class, so rules can be checked automatically.

22.4 Data flows

Meters to load balancer to ingest to queue to database; database to API to customer portal; database to billing export to billing system; database to analytics as aggregates.

Drawing flows shows every path readings take and every system that touches them. The analytics flow receives aggregates, not raw readings, which limits exposure. The billing export is a flow out of the platform to another system, so its protection depends on both sides. Elena draws the flows on one page and numbers them, so later tables and tests can refer to each flow by number instead of describing it again.

22.5 Trust boundaries

Marked where data crosses between identities, networks or accounts. Shostack-style questions are asked at each: what can go wrong here?

At each boundary, asking what can go wrong prompts specific threats: could a caller pretend to be another service, could data be altered in transit, could a request be denied without trace? The questions are simple but, asked systematically, they surface issues that a general review overlooks. Answers are written beside each boundary on the diagram. Where a question has no good answer yet, such as how a fake meter would be noticed, it becomes an open item with an owner and a date.

22.6 Using the model

For each flow, Elena checks: is it authenticated, authorised, encrypted, logged? Missing marks become work items.

A simple table with four columns per flow makes gaps obvious. Elena finds that the billing export is authenticated and encrypted but not logged on the receiving side, so the team could not show later who received which file. That gap becomes a work item with an owner. She completes the table for all numbered flows in one afternoon with Rosa, who supplies details Elena could not find in the exports.

Generating the model

Elena writes a script that builds the identity part of the model from exported role bindings and cloud role policies, so it can be regenerated monthly instead of drawn by hand. Differences from the previous month are highlighted for review. The first regeneration finds two new role bindings added during an incident and never removed.

Worked example

The model shows the billing export job reads the full readings table with an identity that can also write to it. Reducing it to read-only, and to a view with only billing-period totals, removes write access and most personal detail from that path.

Synthetic case. Components and flows are synthetic.

Errors and limits

Models drift from reality; regenerate parts from live configuration where possible.

Exercises

Synthesis

Models of components, identities and data reveal missing controls.

Continue studying — chapter 22 of 50

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →