Chapter 50 — Hands-on: build SecureShop's data-protection layer

Brief

Assemble Part 7 into one working data-protection layer for SecureShop: a current classification-driven inventory, field-level encryption with a per-tenant key hierarchy, a working erasure orchestrator proven against every system it touches, residency-aware architecture, database hardening beyond RLS, and an access governance process — then run a simulated DSAR and a simulated insider-access review end to end.

Setup

   * The SecureShop stack from Part 5's hands-on (services, PostgreSQL
     with RLS, OpenSearch, Redis, Kafka), extended with: an object
     storage bucket for exports, a mock "analytics warehouse" (a
     separate Postgres schema is fine), a mock third-party support tool
     (a stub API with its own "deletion endpoint" is fine).
   * KMS (cloud or a local simulator) for the key hierarchy from Part 2
     Ch 9 / Ch 42 / Ch 44.
   * An open-source DP library (OpenDP or Google's differential-privacy)
     for the analytics layer.
   * A simple ticketing/tracking tool (even a shared doc or a lightweight
     tracker) for the recertification and DSAR workflows.

Tasks

   1. CLASSIFICATION & MAPPING (Ch 41)
      [ ] Tag every table/column/bucket/topic in the stack with a
          classification tier.
      [ ] Produce a data-flow diagram as code covering every system
          listed in the setup.
      [ ] Write a one-page RoPA for "customer order processing".

   2. ENCRYPTION (Ch 42, 44)
      [ ] Build the key hierarchy: root -> per-environment CMK ->
          per-tenant CMK -> per-record/per-field DEK.
      [ ] Field-encrypt at least two RESTRICTED columns (e.g. customer
          email, address) with AAD binding to tenant+record+field.
      [ ] Add a blind index for one field that needs equality lookup.
      [ ] Demonstrate backing-key rotation (cheap) vs simulate a scenario
          requiring full data re-encryption (expensive) and show you have
          a migration path for the latter.

   3. TOKENIZATION (Ch 43) -- if you handle any card-shaped data in the
      lab
      [ ] Stand up a token vault (Vault Transform, or a minimal custom
          one) and tokenize a mock "payment method" field; confirm the
          token has no exploitable relationship to the original.

   4. DE-IDENTIFICATION (Ch 45)
      [ ] Ensure the "analytics warehouse" schema receives only
          de-identified/aggregated data -- no raw RESTRICTED fields.
      [ ] Put a differential-privacy query layer in front of it for at
          least one aggregate query type; show the epsilon/accuracy
          trade-off at two different budget settings.

   5. ERASURE (Ch 46)
      [ ] Build the orchestrator: given a subject/tenant ID, it visits
          every system in your Ch 41 inventory and either hard-deletes,
          crypto-shreds (via key destruction), calls the mock third
          party's deletion endpoint, or logs "nothing identifiable
          present" -- with a completion record per system.
      [ ] Include at least one documented RETENTION EXEMPTION (e.g.
          "invoice financial fields retained N years") handled correctly
          -- the personal-data FIELDS within that record are still
          crypto-shredded even though the record itself is retained.
      [ ] VERIFY: after running the orchestrator, re-query every system
          and confirm zero identifiable results (except the documented
          exemption).

   6. RESIDENCY (Ch 47)
      [ ] Document (even if simulated) which "region" each system in the
          lab is pinned to, and write the one Transfer Impact Assessment
          paragraph for any flow that crosses a boundary.
      [ ] Add a mock sub-processor list entry for the third-party support
          tool stub, including its transfer mechanism.

   7. DATABASE HARDENING (Ch 48)
      [ ] Enable audit logging (pgAudit or equivalent); establish a crude
          volume baseline for one service account; inject an anomalous
          bulk-query pattern and confirm it's visible in the log/alertable.
      [ ] Confirm no service shares a DB account with another; confirm no
          app role is superuser/BYPASSRLS.
      [ ] Migrate one service to IAM-based DB auth (or a Vault dynamic
          secret) instead of a static password.

   8. ACCESS GOVERNANCE (Ch 49)
      [ ] Define a JIT access flow (even a lightweight, manual-approval
          version) for the "support-lookup" role that can see decrypted
          PII per Ch 42's worked example.
      [ ] Run one simulated quarterly recertification cycle over your
          lab's access grants; find and revoke at least one intentionally-
          planted stale grant.
      [ ] Write the break-glass procedure for the lab's most sensitive
          system.

   9. END-TO-END DRILLS
      [ ] Run a full simulated DSAR/erasure request through the
          orchestrator for a test tenant; produce the "what was deleted,
          what was retained and why" response.
      [ ] Run the recertification cycle and produce its findings report.

Deliverable

~/sec-lab/adv/reports/p7-dataprotection.md: the classification/data-flow artefacts, the key hierarchy diagram, the erasure orchestrator's run log and verification output for a test subject, the residency documentation, the database-hardening evidence, and the access-governance artefacts (JIT flow, recertification findings, break-glass procedure). Plus: "if you could only build one control from this Part before shipping to real customers, which, and why."

Definition of done

• A current, tag-driven classification and data-flow map covering every system in the lab.
• Field-level encryption with a real per-tenant key hierarchy; backing-key rotation demonstrated; a re-encryption migration path documented.
• Analytics receives only de-identified data, fronted by a differential- privacy query layer with a tracked epsilon budget.
• An erasure orchestrator that runs against every system, correctly handles at least one retention exemption, and is independently verified (re-queried, not just trusted).
• Residency documented per system with at least one TIA paragraph and a sub-processor list entry.
• Database audit logging with a demonstrated anomalous-pattern detection; IAM-based auth on at least one service; no shared/over-privileged DB accounts.
• A working JIT flow, a completed recertification cycle that found and revoked a stale grant, and a documented break-glass procedure.

Rubric (/100)

   Classification + data-flow mapping ............ 10
   Key hierarchy + field encryption + rotation ... 20
   De-identification + DP query layer ............ 10
   Erasure orchestrator, exemption handling,
     independently verified ...................... 25
   Residency documentation + sub-processor list .. 10
   Database hardening (audit, IAM auth, hygiene) . 15
   Access governance (JIT, recertification,
     break-glass) .................................. 10