Chapter 12 — Cloud and container security: data flows
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Why flows matter"]
N2["12.2 Recording flows"]
N3["Lab — data flows"]
N4["12.3 Reading the result"]
N5["12.4 Following up"]
N6["12.5 Data minimisation"]
N7["12.6 Keeping the list current"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Why flows matter"]
N2["12.2 Recording flows"]
N3["Lab — data flows"]
N4["12.3 Reading the result"]
N5["12.4 Following up"]
N6["12.5 Data minimisation"]
N7["12.6 Keeping the list current"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Why flows matter]
|
v
[12.2 Recording flows]
|
v
[Lab — data flows]
|
v
[12.3 Reading the result]
|
v
[12.4 Following up]
|
v
[12.5 Data minimisation]
|
v
[12.6 Keeping the list current]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) list data flows for a client system; (2) mark trust boundaries; (3) flag flows needing review.
12.1 Why flows matter
Knowing what runs is half the picture; knowing where data goes is the other. Patient contact details move from browser to booking to email service; reports go to a storage bucket; files go to a partner. The advisory search showed the cost of not knowing what runs; a flow list prevents the same problem for data. If a partner reported a leak or an email provider announced a breach, Cobalt would need to know at once which clients send data there and what that data contains. Priya builds the list for Riverside Dental first because its booking system handles patient contact details.
12.2 Recording flows
Priya records each flow as source, destination, zone and whether it is encrypted. The zone shows whether the flow stays inside the cluster, goes to a managed service or crosses the internet. Each field in a flow record has a specific purpose. Source and destination say what talks to what, the zone says which boundary is crossed, and the encryption field says whether the data is protected on the way. Priya fills the fields from the service configurations rather than from memory, and she marks any flow whose encryption she could not confirm as unknown rather than guessing.
Lab — data flows
"""List data flows and flag ones that cross a trust boundary without encryption (synthetic)."""
flows = [("browser", "proxy", "internet", True), ("proxy", "web", "cluster", True),
("web", "api", "cluster", False), ("api", "database", "managed service", True),
("reports", "storage bucket", "managed service", True), ("cron", "partner sftp", "internet", True),
("metrics", "monitoring saas", "internet", True), ("booking", "email api", "internet", False)]
cross = [f for f in flows if f[2] != "cluster"]
print(f"flows {len(flows)}, crossing a boundary {len(cross)}")
for s, d, z, enc in flows:
if z != "cluster" and not enc: print(f" REVIEW {s} -> {d} ({z}) not encrypted")
elif z == "cluster" and not enc: print(f" note {s} -> {d} inside cluster, not encrypted")
Run with python3 lab_flows.py. Verified output:
flows 8, crossing a boundary 6
note web -> api inside cluster, not encrypted
REVIEW booking -> email api (internet) not encrypted
12.3 Reading the result
Of 8 flows, 6 cross a boundary. One, booking to the email API over the internet, is not encrypted and is flagged for review. One inside the cluster, web to API, is also unencrypted and noted as a known limit. The six boundary flows are browser to proxy, the API's link to the managed database, reports to the storage bucket, cron to the partner's SFTP server, metrics to the monitoring service and booking to the email API. Five of the six use encryption. The two flows inside the cluster are proxy to web and web to API, and only the second is unencrypted, matching what Priya found when tracing the booking request in chapter 2.
12.4 Following up
Priya checks the booking configuration and finds the email library set to a plain connection. Switching to the encrypted endpoint is a one-line configuration change, tested in staging first. The plain connection had probably been chosen during early testing and never changed. In staging, Priya switches the library to the encrypted endpoint, sends a synthetic booking confirmation, and confirms that the email arrives and that the connection now uses TLS. Only then is the change made in production through the pipeline, and the flow list entry is updated with the date of the fix.
12.5 Data minimisation
She also asks whether the email needs the patient's full details. It needs only a name and time, so the flow is reduced. Before the change, the confirmation email carried the patient's full contact details, although its purpose was only to remind the patient of an appointment. Sending only a name and time means that even if the email provider were breached, much less patient data would be exposed. Priya records the reduced field list beside the flow, so a later change that adds fields again shows up in review.
12.6 Keeping the list current
The flow list is reviewed whenever a new integration is added. Integrations often arrive quietly, for example when a developer adds a new analytics service or a client asks for a calendar link. Priya adds a question about new outbound connections to the deployment review, so the flow list is updated together with the inventory. Kwame agrees to compare the list with observed outbound traffic every quarter, which catches integrations that bypass review. Removed integrations are deleted from the list as well, so it never describes flows that have stopped.
Partner flows
The cron workload sends files to a partner over SFTP. Priya confirms the partner's address and key are recorded.
Review
Kwame signs off the flow list.
Worked example
Kwame asks why the internal flow is acceptable. Priya explains that the cluster network is private, both workloads belong to the same client, and the risk is recorded with a plan to add mutual TLS when the service mesh is introduced.
Synthetic case. Flows are synthetic.
Errors and limits
A flow list from documentation may miss integrations added quietly; compare with observed traffic where possible.
Exercises
- EX034 — Lab flag. Which flow was flagged for review and why? Rubric: 3 = booking to email API; internet, unencrypted; 2 = partial; 1 = vague; 0 = none.
- EX035 — Minimisation. How was the email flow reduced? Rubric: 3 = only name and time sent; 2 = partial; 1 = vague; 0 = none.
- EX036 — Internal limit. Why was the internal unencrypted flow accepted for now? Rubric: 3 = private network, same client, recorded with plan; 2 = two; 1 = one; 0 = none.
Synthesis
Map where data goes and fix flows that leave unprotected.
Continue studying — chapter 12 of 30
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →