Audit-Log / lückenlose Dokumentation (G-4)

Bezug: G-4, R8, OP-AUDIT-1 · Status: Gebaut (Slice 6, 0.5.0) — append-only D1-Store mit SHA-256-Hash-Verkettung; Retention/Archiv-Strategie definiert (Umsetzung offen, OP-AUDIT-1 Rest).

Warum

Medidentas koordiniert rechtsrelevante Vorgänge (Beratung, Verträge, Unterschriften, Fristen). G-4 verlangt eine lückenlose, manipulationssichere, auditierbare Historie — Grundlage für Nachweis im Streitfall, Aufsicht und interne Revision. Das Audit-Log ist append-only und nicht reverse-engineerbar (aus dem Log darf sich der ursprüngliche Zustand nachvollziehen lassen, aber das Log selbst ist nicht nachträglich umschreibbar).

Event-Modell (Skizze)

• Append-only: nur Insert, kein Update/Delete im Normalbetrieb.
• PII-arm: im Diff nur das Nötigste; sensible Inhalte als Referenz, nicht im Klartext (G-5).
• Korrelation: trace_id verbindet Events über NextCloud-/Signatur-Webhooks hinweg.

Anforderungen

Thema	Anforderung
Integrität	append-only; optional Hash-Verkettung (jedes Event referenziert Hash des Vorgängers) für Manipulationsschutz
Retention	je Entity-Typ definierte Aufbewahrungsfrist (GoBD/§147 AO + branchenspez.); Löschung erst nach Frist (Sperre statt Hard-Delete)
Residenz	EU-/CH-Speicherung (G-5)
Abfragbarkeit	nach Mandant/Entity/Zeitraum (Cockpit, Revision)
Backup/Restore	Restore-Punkt rekonstruierbar; Audit-Log bleibt dabei append-only

Zugriffs-(Lese-)Protokollierung sensibler Entitäten (D-50, gebaut 0.48.0)

Das bisher Umgesetzte protokolliert zustandsändernde Ereignisse ("wer hat wann was getan"), nicht reine Lesezugriffe. Für besonders sensible / Art.-9-Daten ist Zugriffs-Nachvollziehbarkeit jedoch State of the Art (Art. 5(2)/24/32/33 DSGVO, revDSG, ISO 27001 A.12.4) — Grundlage für Missbrauchs-/Breach- Erkennung (RISK-27). Festgezurrte Richtung (D-50):

• Whitelist statt Alles-Loggen (G-6, Datenminimierung): geloggt werden nur Lesezugriffe auf sensible Entitäten:

  Entität	Loggen?	Grund
  Beratungsdoku / Beratungsprotokoll (R6)	✅	rechtsrelevant, Haftung
  Gesundheitsbogen (R6-F18, §19 VVG) / Art.-9-Daten	✅	besondere Kategorie
  signierte Dokumente / Verträge / Vollmachten (R4)	✅	Beweiswert
  ganzer Mandant ("Aktendeckel geöffnet")	✅	zentraler PII-Träger
  Dexman / PVS-nahe Gesundheits-/Finanzdaten	✅	Art. 9, RISK-12
  Cockpit-/Listen-/Leitstand-Ansichten, Navigation, Such-Treffer	❌	Aggregat ohne Detail-PII → Rauschen

• Event-Form: neuer aktion-Wert eingesehen im bestehenden Modell; Payload PII-arm — nur actor (echte Identität, R7), entity+entity_id, ts, trace_id; kein Inhalt, kein Diff. Gleiche append-only Hash-Kette + verify und Retention wie oben.
• Mechanik (gebaut): Whitelist in server/src/domain/zugriff.ts (ZUGRIFF_SENSIBEL = mandant/beratungsdoku/dokument, zugriffAktion()); die Recorder-Methode AuditLog.protokolliereZugriff(entitaet, entitaetId, mandantId) schreibt das PII-arme Event. Verdrahtet an den drei Lese-Endpoints GET /api/mandanten/:id (ganzer Mandant), GET /api/mandanten/:id/beratungsdoku und GET /api/dokumente/:docId/datei (Datei-Inhalt) — nur bei erfolgreichem Zugriff.
• Nebenbedingung Mitarbeiterschutz: Das Zugriffslog ist zweckgebunden (Missbrauchserkennung, Breach-Aufklärung, Betroffenenauskunft Art. 15) und darf nicht zur verdeckten Leistungs-/ Verhaltenskontrolle eigener Mitarbeiter dienen (§87 Abs.1 Nr.6 BetrVG, Nähe RISK-11/21/26) → Betriebsrat beteiligen (KB-3, organisatorisch offen).
• Status: gebaut (0.48.0) — Whitelist + Recorder + drei Endpoints + Tests (domain/zugriff.test.ts, api/audit.test.ts). Rest: Dexman/PVS-Art.-9-Lese-Endpoints (ungebaut), Retention der Zugriffs-Events (Compliance #4).

Abgrenzung

• Audit-Log ≠ Anwendungs-Log (Observability, OP-OBS-1): Das Audit-Log ist fachlich/rechtlich (wer hat wann was getan bzw. gesehen); das Observability-Logging ist technisch (Performance, Fehler). Beide PII-arm, aber getrennt.

Umgesetzt (Slice 6, 0.5.0)

• Append-only D1-Store (audit_event, Migration v4): nur Insert; Repo bietet appendAuditEvent + listAuditEvents (kein Update/Delete).
• Hash-Verkettung (domain/audit.ts): hash = SHA-256(vorherHash | ts | actor | mandantId | entitaet | entitaetId | aktion | details); pruefeKette() erkennt Änderung und Löschung (Tamper-Evidence). IDs sind streng monoton (ULID-monotonicFactory) → Lese-Reihenfolge = Ketten-Reihenfolge.
• Quer verdrahtet (api/audit-log.ts, AuditRecorder): jeder zustandsändernde Dienst (Mandant, Onboarding, Dokument, Signatur) schreibt ein PII-armes Event (nur IDs/Status/Enums, G-5).
• API: GET /api/mandanten/:id/audit, GET /api/audit, GET /api/audit/verify (Integritätsprüfung). Felder R8-F01..11. Client: "Verlauf"-Sektion im Mandant-Detail.

Retention-Matrix (Default, OP-AUDIT-1 — admin-/branchenspezifisch verfeinerbar)

Entitäts-/Dokumenttyp	Mindest-Aufbewahrung	Grundlage
Verträge, Vollmachten, signierte Dokumente	10 Jahre	GoBD/§147 AO, HGB
Beratungsdokumentation	mind. 5 Jahre (branchenspez. länger)	VVG/FinVermV, Aufsicht
Onboarding-/Prozess-Events	6 Jahre	GoBD/§147 AO (Geschäftsbriefe)
Wiedervorlagen/Aufgaben (rein intern)	nach Zweckfortfall, ≤ 3 Jahre	Datenminimierung (G-5)

"Löschung" = Sperrung/Anonymisierung nach Frist, nie Hard-Delete vor Fristende (Audit bleibt append-only).

Offene Punkte

• OP-AUDIT-1 (Rest): Archiv-/Cold-Storage (Export der gealterten Kette nach Cloudflare R2 + Hash-Anker), Restore-Strategie, Concurrency-Härtung (globale Kette unter parallelen Writes → Transaktion/Sequenz oder per-Mandant-Kette), Anbindung an trace_id aus NextCloud-/Signatur-Webhooks.