Frontend Labs
⋯

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.

Generated from real-life-security-guide-v1.md · 8 Oct 2026 16:36