Benjamin_Boenisch/breakpilot-compliance
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4b1eede45b473cee9be364ba7241dea9d21b6332
breakpilot-compliance/docs-src/services/sdk-modules/tom.md
Benjamin Admin 4b1eede45b feat(tom): audit document, compliance checks, 25 controls, canonical control mapping 
Phase A: TOM document HTML generator (12 sections, inline CSS, A4 print)
Phase B: TOMDocumentTab component (org-header form, revisions, print/download)
Phase C: 11 compliance checks with severity-weighted scoring
Phase D: MkDocs documentation for TOM module
Phase E: 25 new controls (63 → 88) in 13 categories

Canonical Control Mapping (three-layer architecture):
- Migration 068: tom_control_mappings + tom_control_sync_state tables
- 6 API endpoints: sync, list, by-tom, stats, manual add, delete
- Category mapping: 13 TOM categories → 17 canonical categories
- Frontend: sync button + coverage card (Overview), drill-down (Editor),
  belegende Controls count (Document)
- 20 tests (unit + API with mocked DB)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-19 11:56:53 +01:00

272 lines
13 KiB
Markdown
Raw Blame History

# TOM — Technische und Organisatorische Massnahmen (Art. 32 DSGVO)
## Uebersicht
Das TOM-Modul implementiert die systematische Ableitung, Dokumentation und Ueberpruefung technischer und organisatorischer Massnahmen gemaess Art. 32 DSGVO. Es bietet einen 6-Schritt-Generator-Wizard, eine regelbasierte Kontrollbibliothek mit 88 Massnahmen, Gap-Analyse, SDM-Mapping, auditfaehige Dokumentengenerierung und 11 Compliance-Checks.
**Route:** `/sdk/tom` | **Backend:** `backend-compliance:8002` | **Checkpoint:** `CP-TOM`
---
## Art. 32 DSGVO Anforderungen
| Absatz | Anforderung | TOM-Modul Umsetzung |
|--------|-------------|---------------------|
| Art. 32 Abs. 1 lit. a | Pseudonymisierung und Verschluesselung | Kategorien ENCRYPTION (5 Controls) und PSEUDONYMIZATION (4 Controls) |
| Art. 32 Abs. 1 lit. b | Vertraulichkeit, Integritaet, Verfuegbarkeit, Belastbarkeit | 8 Kategorien: ACCESS_CONTROL, ADMISSION_CONTROL, ACCESS_AUTHORIZATION, TRANSFER_CONTROL, RESILIENCE, AVAILABILITY, SEPARATION, INPUT_CONTROL |
| Art. 32 Abs. 1 lit. c | Rasche Wiederherstellung nach Zwischenfall | Kategorie RECOVERY (5 Controls) |
| Art. 32 Abs. 1 lit. d | Regelmaessige Ueberpruefung und Bewertung | Kategorie REVIEW (11 Controls) + Compliance-Check NO_REVIEW_PROCESS |
---
## TOM-Ableitung — Zwei Quellen
TOMs werden aus zwei unabhaengigen Quellen abgeleitet:
### 1. Scope/Profil-Module (Embedded Controls)
Der 6-Schritt-Wizard erfasst:
- **CompanyProfile**: Branche, Groesse, Rolle (Controller/Processor)
- **DataProfile**: Datenkategorien, besondere Kategorien (Art. 9), Betroffene
- **ArchitectureProfile**: Hosting, Cloud-Provider, Mandantenfaehigkeit
- **SecurityProfile**: Auth, Backup, Logging, DR-Plan
- **RiskProfile**: CIA-Bewertung, Schutzniveau
Die **Rules Engine** wertet 88 Embedded Controls gegen die Profile-Daten aus. Jeder Control hat `applicabilityConditions` mit Operatoren (EQUALS, IN, GREATER_THAN, CONTAINS) und Prioritaeten.
### 2. Canonical Control Library (CP-CLIB)
Die dynamisch generierte **Canonical Control Library** (`/sdk/control-library`) enthaelt unternehmensrelevante Security-Controls aus OWASP, NIST, ENISA und weiteren Frameworks. Diese werden durch den Control Generator Pipeline erzeugt und haben einen eigenen Review-Workflow.
!!! info "Herkunftsdokumentation"
Im TOM-Dokument (Sektion 2 und 6) wird die **Herkunft** jeder Massnahme dokumentiert —
ob sie aus der Embedded Control Library oder der Canonical Control Library stammt.
---
## Frontend — 5-Tab-Aufbau
| Tab | Beschreibung |
|-----|-------------|
| **Uebersicht** | Alle TOMs mit Filter (Kategorie, Typ, Status, Applicability), SDM-Abdeckung, Statistiken |
| **Detail-Editor** | Einzelne TOM bearbeiten: Status, Verantwortlich, Evidence, Review-Datum |
| **Generator** | 6-Schritt-Wizard starten, Quick-Stats |
| **Gap-Analyse & Export** | Gap-Analyse-Ergebnisse, SDM/Modul-Abdeckung, JSON/DOCX Export |
| **TOM-Dokument** | Auditfaehiges HTML-Dokument (12 Sektionen), Org-Header, Revisionsmanager, PDF-Druck |
---
## Kontrollbibliothek (88 Massnahmen)
| Kategorie | Code-Prefix | Anzahl | DSGVO-Referenz |
|-----------|-------------|--------|----------------|
| Zutrittskontrolle | TOM-AC | 6 | Art. 32 Abs. 1 lit. b |
| Zugangskontrolle | TOM-ADM | 6 | Art. 32 Abs. 1 lit. b |
| Zugriffskontrolle | TOM-AZ | 7 | Art. 32 Abs. 1 lit. b |
| Weitergabekontrolle | TOM-TR | 7 | Art. 32 Abs. 1 lit. b |
| Eingabekontrolle | TOM-IN | 5 | Art. 32 Abs. 1 lit. b |
| Auftragskontrolle | TOM-OR | 6 | Art. 28 |
| Verfuegbarkeit | TOM-AV | 7 | Art. 32 Abs. 1 lit. b, c |
| Trennbarkeit | TOM-SE | 6 | Art. 32 Abs. 1 lit. b |
| Verschluesselung | TOM-ENC | 5 | Art. 32 Abs. 1 lit. a |
| Pseudonymisierung | TOM-PS | 4 | Art. 32 Abs. 1 lit. a |
| Belastbarkeit | TOM-RE | 5 | Art. 32 Abs. 1 lit. b |
| Wiederherstellbarkeit | TOM-RC | 5 | Art. 32 Abs. 1 lit. c |
| Ueberpruefung & Bewertung | TOM-RV / TOM-DL / TOM-TR | 11 | Art. 32 Abs. 1 lit. d |
---
## SDM Gewaehrleistungsziele
Das [Standard-Datenschutzmodell](https://www.datenschutz-wiki.de/SDM) definiert 7 Gewaehrleistungsziele:
| Ziel | Relevante Kategorien |
|------|---------------------|
| Verfuegbarkeit | AVAILABILITY, RESILIENCE, RECOVERY |
| Integritaet | ADMISSION_CONTROL, TRANSFER_CONTROL, INPUT_CONTROL, ENCRYPTION, RECOVERY |
| Vertraulichkeit | ACCESS_CONTROL, ADMISSION_CONTROL, ACCESS_AUTHORIZATION, TRANSFER_CONTROL, ENCRYPTION |
| Nichtverkettung | ACCESS_AUTHORIZATION, SEPARATION, PSEUDONYMIZATION |
| Intervenierbarkeit | ORDER_CONTROL, REVIEW |
| Transparenz | INPUT_CONTROL, ORDER_CONTROL, REVIEW |
| Datenminimierung | SEPARATION, PSEUDONYMIZATION |
!!! tip "SDM-Abdeckung"
Die Gap-Analyse (Tab 4) zeigt pro SDM-Gewaehrleistungsziel den Abdeckungsgrad
in Prozent. Ziele mit 0% Abdeckung loesen den Compliance-Check `UNCOVERED_SDM_GOAL`
(Schweregrad HIGH) aus.
---
## 11 Compliance-Checks
| # | Check | Schweregrad | Ausloeser |
|---|-------|-------------|-----------|
| 1 | `MISSING_RESPONSIBLE` | MEDIUM | REQUIRED-TOM ohne verantwortliche Person/Abteilung |
| 2 | `OVERDUE_REVIEW` | MEDIUM | TOM mit reviewDate in der Vergangenheit |
| 3 | `MISSING_EVIDENCE` | HIGH | IMPLEMENTED-TOM ohne Evidence (obwohl evidenceRequirements > 0) |
| 4 | `INCOMPLETE_CATEGORY` | HIGH | Kategorie, in der alle REQUIRED-Controls NOT_IMPLEMENTED sind |
| 5 | `NO_ENCRYPTION_MEASURES` | CRITICAL | Kein ENCRYPTION-Control implementiert |
| 6 | `NO_PSEUDONYMIZATION` | MEDIUM | Besondere Datenkategorien (Art. 9) ohne PSEUDONYMIZATION |
| 7 | `MISSING_AVAILABILITY` | HIGH | Kein AVAILABILITY/RECOVERY implementiert + kein DR-Plan |
| 8 | `NO_REVIEW_PROCESS` | MEDIUM | Kein REVIEW-Control implementiert |
| 9 | `UNCOVERED_SDM_GOAL` | HIGH | SDM-Gewaehrleistungsziel mit 0% Abdeckung |
| 10 | `HIGH_RISK_WITHOUT_MEASURES` | CRITICAL | Schutzniveau VERY_HIGH aber < 50% implementiert |
| 11 | `STALE_NOT_IMPLEMENTED` | LOW | REQUIRED-TOM seit > 90 Tagen NOT_IMPLEMENTED |
**Score-Berechnung:** `100 - (CRITICAL*15 + HIGH*10 + MEDIUM*5 + LOW*2)`, Minimum 0.
---
## Backend API (9+ Endpoints)
| Methode | Pfad | Beschreibung |
|---------|------|--------------|
| `GET` | `/api/v1/tom/state` | TOM-Generator-State laden |
| `POST` | `/api/v1/tom/state` | State speichern |
| `POST` | `/api/v1/tom/evaluate` | Controls evaluieren (Rules Engine) |
| `POST` | `/api/v1/tom/gap-analysis` | Gap-Analyse durchfuehren |
| `POST` | `/api/v1/tom/evidence/upload` | Evidence-Dokument hochladen |
| `POST` | `/api/v1/tom/evidence/analyze` | KI-Analyse eines Evidence-Dokuments |
| `POST` | `/api/v1/tom/export` | Export (JSON, DOCX, PDF, ZIP) |
| `GET` | `/api/v1/tom/controls` | Kontrollbibliothek abrufen |
| `GET` | `/api/v1/tom/controls/:id` | Einzelnen Control abrufen |
### TOM ↔ Canonical Control Mapping API
| Methode | Pfad | Beschreibung |
|---------|------|--------------|
| `POST` | `/api/compliance/tom-mappings/sync` | Controls synchronisieren (Profil-basiert) |
| `GET` | `/api/compliance/tom-mappings` | Alle Mappings auflisten |
| `GET` | `/api/compliance/tom-mappings/by-tom/{code}` | Mappings pro TOM-Kategorie |
| `GET` | `/api/compliance/tom-mappings/stats` | Coverage-Statistiken |
| `POST` | `/api/compliance/tom-mappings/manual` | Manuelle Zuordnung |
| `DELETE` | `/api/compliance/tom-mappings/{id}` | Zuordnung entfernen |
!!! info "Proxy-Route (Frontend)"
Das Admin-Frontend ruft die Endpoints ueber den Next.js-Proxy auf:
`/api/sdk/v1/tom/**` → `backend-compliance:8002/api/v1/tom/**`
`/api/sdk/v1/compliance/tom-mappings/**` → `backend-compliance:8002/api/compliance/tom-mappings/**`
---
## TOM-Dokument (12 Sektionen)
| # | Sektion | Inhalt |
|---|---------|--------|
| 0 | Deckblatt | Organisation, DSB, IT-Sicherheit, Version |
| — | Inhaltsverzeichnis | Automatisch generiert |
| 1 | Ziel und Zweck | Art. 32 DSGVO Rechtsrahmen |
| 2 | Geltungsbereich | Unternehmen, Hosting, Systeme, Control-Quellen |
| 3 | Grundprinzipien Art. 32 | Vertraulichkeit, Integritaet, Verfuegbarkeit, Belastbarkeit, Wirksamkeitspruefung |
| 4 | Schutzbedarf und Risikoanalyse | CIA-Bewertung, Schutzniveau, DSFA-Pflicht |
| 5 | Massnahmen-Uebersicht | Tabelle: Kategorie, Anzahl, Status-Verteilung |
| 6 | Detaillierte Massnahmen | Pro Kategorie: Detail-Karten mit Code, Status, Evidence, Mappings |
| 7 | SDM Gewaehrleistungsziele | Abdeckungstabelle (7 Ziele x Prozent) |
| 8 | Verantwortlichkeiten | Rollenmatrix |
| 9 | Pruef- und Revisionszyklus | Review-Zeitplan |
| 10 | Compliance-Status | Score, Issues nach Schweregrad |
| 11 | Aenderungshistorie | Versionstabelle |
**Ausgabe:** HTML-Download oder PDF-Druck via Browser (`window.print()`).
---
## Drei-Schichten-Architektur (TOM ↔ Canonical Controls)
Die Audit-faehige Dokumentation nutzt eine **Drei-Schichten-Architektur**:
```mermaid
graph TD
TOM["TOM-Massnahmen (~88, Audit-Level)"]
MAP["tom_control_mappings (Bridge-Tabelle)"]
CC["Canonical Controls (10.000+, Implementation-Level)"]
TOM --> MAP --> CC
```
| Schicht | Beschreibung | Beispiel |
|---------|-------------|---------|
| **TOM-Massnahmen** | 88 abstrakte, auditfaehige Massnahmen in 13 Kategorien | TOM-ENC-01: Transportverschluesselung |
| **Mapping-Bridge** | Verknuepfung TOM-Kategorie → Canonical Controls per Profil | ENCRYPTION → encryption-Kategorie, Industry-Filter |
| **Canonical Controls** | 10.000+ konkrete Security-Controls aus OWASP, NIST, ENISA | CRYP-001: Cryptographic Key Lifecycle |
### Kategorie-Zuordnung
| TOM-Kategorie | Canonical Kategorien |
|---------------|---------------------|
| ACCESS_CONTROL | authentication, identity, physical |
| ADMISSION_CONTROL | authentication, identity, system |
| ACCESS_AUTHORIZATION | authentication, identity |
| TRANSFER_CONTROL | network, data_protection, encryption |
| INPUT_CONTROL | application, data_protection |
| ORDER_CONTROL | supply_chain, compliance |
| AVAILABILITY | continuity, system |
| SEPARATION | network, data_protection |
| ENCRYPTION | encryption |
| PSEUDONYMIZATION | data_protection, encryption |
| RESILIENCE | continuity, system |
| RECOVERY | continuity |
| REVIEW | compliance, governance, risk |
### Sync-Algorithmus
1. CompanyProfile (Branche, Groesse) wird gehasht
2. Aenderung erkannt → alte auto-Mappings loeschen
3. Pro TOM-Kategorie: Canonical Controls mit passender `category`, `applicable_industries`, `applicable_company_size` und `release_state = 'approved'` suchen
4. Neue Mappings inserieren (ON CONFLICT DO NOTHING)
5. Sync-State aktualisieren
---
## Cross-Modul-Integration
| Modul | Integration |
|-------|------------|
| **DSFA** | TOM-Controls als Massnahmen in Datenschutz-Folgenabschaetzung |
| **VVT** | Verknuepfung von TOMs mit Verarbeitungstaetigkeiten |
| **Loeschfristen** | Loeschkontrollen (TOM-DL) referenzieren Loeschfristen-Policies |
| **Control Library** | Canonical Controls als belegende Security-Controls pro TOM-Kategorie |
| **Risk Assessment** | RiskProfile steuert Applicability der Controls |
```mermaid
graph LR
Scope["Scope Engine"] -->|Profile| TOM["TOM (Art. 32)"]
CLIB["Control Library"] -->|Canonical Controls| TOM
TOM --> DSFA["DSFA (Art. 35)"]
TOM --> VVT["VVT (Art. 30)"]
TOM --> Loeschfristen["Loeschfristen"]
Risk["Risk Assessment"] -->|RiskProfile| TOM
```
---
## Audit-Faehigkeit
Das TOM-Modul erfuellt 7 Audit-Kriterien:
1. **Vollstaendigkeit**: 88 Controls decken alle Art. 32 Anforderungen ab
2. **Nachvollziehbarkeit**: Rules Engine dokumentiert Applicability-Gruende
3. **Aktualitaet**: Review-Zyklen + Compliance-Check OVERDUE_REVIEW
4. **Verantwortlichkeit**: Rollenmatrix im TOM-Dokument
5. **Evidence**: Evidence-Verknuepfung + Gap-Analyse
6. **Druckfaehigkeit**: Auditfaehiges HTML-Dokument mit 12 Sektionen
7. **Wirksamkeitspruefung**: 11 Compliance-Checks + Score
---
## Datei-Uebersicht
| Datei | Beschreibung |
|-------|--------------|
| `admin-compliance/app/sdk/tom/page.tsx` | Haupt-Seite mit 5 Tabs |
| `admin-compliance/components/sdk/tom-dashboard/` | Tab-Komponenten (Overview, Editor, GapExport, Document) |
| `admin-compliance/lib/sdk/tom-generator/types.ts` | Alle TypeScript-Typen |
| `admin-compliance/lib/sdk/tom-generator/controls/loader.ts` | 88 Embedded Controls |
| `admin-compliance/lib/sdk/tom-generator/rules-engine.ts` | Applicability-Auswertung |
| `admin-compliance/lib/sdk/tom-generator/context.tsx` | State Management (Reducer) |
| `admin-compliance/lib/sdk/tom-generator/sdm-mapping.ts` | SDM-Gewaehrleistungsziel-Mapping |
| `admin-compliance/lib/sdk/tom-compliance.ts` | 11 Compliance-Checks |
| `admin-compliance/lib/sdk/tom-document.ts` | HTML-Dokument-Generator |
| `backend-compliance/compliance/api/tom_mapping_routes.py` | TOM ↔ Canonical Control Mapping API (6 Endpoints) |
| `backend-compliance/migrations/068_tom_control_mappings.sql` | DB-Schema fuer Mapping-Bridge |
Reference in New Issue View Git Blame Copy Permalink