Chapter 68 — Project 5: the data-protection and privacy layer, productionised
Brief
Part 7 Ch 50 built the mechanics of a data-protection layer in isolation. This project wires that layer into the FULL stack built across Projects 1, 2, and 4 — the real multi-account cloud infrastructure, the Kubernetes deployment, the distributed services with proper authorization gating every decrypt call, and detection for anomalous data access — then proves it under simulated external scrutiny: a real DSAR request handled end to end, and a compliance-audit control-mapping exercise against everything you've built in this guide.
Tasks
1. INTEGRATE THE KEY HIERARCHY (Part 7 Ch 42/44) INTO THE REAL CLOUD
STRUCTURE (Part 2 Ch 7, Project 1)
[ ] the per-tenant CMKs live in the correct account per Part 2's
multi-account design (not the workload account); key POLICIES
reference the actual IAM roles/SPIFFE-federated identities
(Part 5 Ch 23) of the services built in Project 1/2, not
placeholder principals.
[ ] decrypt calls are GATED by the ReBAC authorization model from
Project 2 (Part 5 Ch 25) -- a service must pass an authz check
AND hold the KMS grant to decrypt a field; test that removing
either one independently still blocks access.
2. WIRE ERASURE INTO THE REAL SYSTEM LIST (Part 7 Ch 46)
[ ] the orchestrator's system list is the ACTUAL inventory from
Project 1's cluster + cloud accounts + Project 2's data stores
(Postgres/OpenSearch/Redis/Kafka) -- not a lab stand-in.
[ ] crypto-shredding a tenant's key correctly renders their data
unrecoverable across EVERY store in that real inventory,
verified by re-querying each one.
3. DETECT ANOMALOUS DATA ACCESS (Part 7 Ch 48-49, Part 8)
[ ] wire your DAM/audit-log baseline (Part 7 Ch 48) and your
JIT/recertification records (Part 7 Ch 49) into the SAME
telemetry pipeline built in Part 8, with at least one
live-validated detection for bulk/anomalous access to
field-encrypted data specifically.
4. RUN A REAL DSAR END TO END, UNDER TIME PRESSURE
[ ] simulate a deletion/access request arriving; run it through
identity verification, scope discovery (Ch 41's real map, now
covering the FULL Project 1/2 system list), execution (including
at least one documented retention exemption), and independent
verification -- TIME the whole process and compare it against
the legal SLA window (Ch 46).
5. MAP TO A COMPLIANCE FRAMEWORK (Part 9 Ch 61)
[ ] take one real framework (SOC 2 is a reasonable default) and map
at least 15 of its controls to SPECIFIC artifacts produced
across this ENTIRE guide (not just Part 7) -- access reviews
(Part 7 Ch 49), detection coverage (Part 8), vulnerability
management (Part 9 Ch 59), IR drills (Ch 67), incident
response plans, threat models (Part 1 Ch 4).
[ ] for each mapping, honestly flag it "real" (continuously
operating) or identify it as a genuine gap needing further work
-- per Ch 61's theater-detection discipline.
Deliverable
~/sec-lab/adv/projects/p5-dataprod/report.md: the integrated key hierarchy
diagram referencing real Project 1/2 identities, the erasure orchestrator's run
log against the real system inventory with verification output, the anomalous-
access detection with live-validation evidence, the timed DSAR walkthrough, and
the full compliance control-mapping table with the real/gap assessment for each
entry.
Definition of done
- The key hierarchy and decrypt-gating are wired into the real infrastructure and authorization model from Projects 1-2, not a standalone demo.
- Erasure runs against the real system inventory and is independently verified.
- At least one live-validated detection for anomalous access to field-encrypted data, integrated into Part 8's pipeline.
- A timed, complete DSAR walkthrough against the real system.
- A compliance mapping of at least 15 controls to real artifacts across the whole guide, each honestly assessed as real or a gap.
Rubric (/100)
Key hierarchy + decrypt gating integrated into real stack 20
Erasure orchestrator against real inventory, verified .... 25
Anomalous-access detection, live-validated ................ 15
Timed, complete DSAR walkthrough ........................... 15
Compliance mapping (15+ controls, honest assessment) ...... 20
Report ...................................................... 5
Further reading
- This project deliberately closes the loop across the entire guide — revisit Part 7 in full, Part 9 Ch 61, and Projects 1-2's artifacts together.
- Standard: revisit the CSA CCM / Secure Controls Framework (Ch 61) while building the mapping table — they'll save you from re-deriving mappings that are already published.
End of Part 10 — Milestone check
- Project 1 done: a combined cloud+cluster attack-path graph, a cross-boundary chain walked and closed, confirmed clean by both tool families — graded ≥ 80/100.
- Project 2 done (see Chapter 65): distributed authorization with a structural, automated proof of tenant isolation across all four required scenarios — graded ≥ 80/100.
- Project 3 done: a four-required-class exploitation chain to ATO/RCE, fully remediated with new SAST/DAST and detection rules — graded ≥ 80/100.
- Project 4 done: a full multi-stage intrusion emulated, every stage detected, a complete IR drill with the right cloud/container mechanics, and real program artifacts produced — graded ≥ 80/100.
- Project 5 done: the data-protection layer productionised into the real stack, a timed DSAR walkthrough, and a substantive compliance mapping — graded ≥ 80/100.
- All five reports are in
~/sec-lab/adv/projects/*/report.md, and each is a genuine cross-Part integration — none of them repeats a single earlier Part's hands-on lab unchanged.