From 8d2facaa200005c8d237698082333d2b42e60d79 Mon Sep 17 00:00:00 2001 From: patrick Date: Tue, 22 Sep 2026 00:20:15 +0200 Subject: [PATCH] dms-kanban: Ticket FDN-22 (Verschluesselung der Textkopien) anlegen Co-Authored-By: Claude Sonnet 5 --- dms-kanban/tickets/FDN-22.md | 56 ++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 dms-kanban/tickets/FDN-22.md diff --git a/dms-kanban/tickets/FDN-22.md b/dms-kanban/tickets/FDN-22.md new file mode 100644 index 00000000..f3a44aca --- /dev/null +++ b/dms-kanban/tickets/FDN-22.md @@ -0,0 +1,56 @@ +# FDN-22 – Verschlüsselung der Textkopien (DSGVO) + +**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 13 + +--- + +## Rolle +Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet. +Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche. + +## Auftrag +Dateien liegen verschlüsselt im Objekt-Speicher (FDN-09, Envelope-Verfahren mit Mandanten-KEK), ihr Klartext aber zusätzlich unverschlüsselt in der Datenbank: als OCR-Text je Seite (`revision_ocr_pages.text`, SRC-05), als extrahierter Klartext (`revision_text_index.text`, SRC-13) und als Suchtext der E-Rechnung (`revision_einvoice.search_text`, MET-06). Wer die Datenbank liest oder sichert, bekommt damit den Inhalt aller Dokumente. Für Kunden mit personenbezogenen Daten und besonderen Kategorien (Art. 9 DSGVO) ist das nicht hinnehmbar. + +Die drei Textspeicher verschlüsselt ablegen, Bestandsdaten überführen und belegen, dass ohne Schlüssel kein Klartext zurückfällt. Der Suchindex (Manticore) enthält notwendig durchsuchbare Begriffe und kann nicht verschlüsselt werden: Restrisiko und Betriebsvorgabe festhalten. + +**Technische Grundlage:** `internal/crypto`, neues Paket `internal/textcrypt`, `internal/ocr`, `internal/plaintext`, `internal/einvoice`, `internal/workerruntime`, Migration `0031`, `docs/BETRIEB-UMGEBUNGSVARIABLEN.md` + +## Produkt-DNA für diesen Bereich +**Bewusst vermeiden:** +- Kein stiller Rückfall auf Klartext: fehlt der Schlüssel oder ist er falsch, schlägt der Zugriff fehl. +- Kein Datenverlust bei der Überführung von Bestandsdaten und keine Entschlüsselung in der Datenbank (nur im Speicher des Dienstes). +- Kein Vermischen von Mandanten: ein Text ist an seine Revision und Seite gebunden (Additional Data) und mit dem Mandanten-KEK verpackt. + +## Ausgangslage +Setzt auf folgenden bereits fertigen Kacheln auf: FDN-09, SRC-05, SRC-07, SRC-13, MET-06. + +## Akzeptanzkriterien +Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind: +1. OCR-Text, Klartext-Extrakt und E-Rechnungs-Suchtext werden nur verschlüsselt gespeichert (AES-256-GCM, DEK je Revision mit dem Mandanten-KEK verpackt, Bindung an Revision und Seite); die Klartextspalten bleiben leer +2. Suche, Regelauswertung, Sprachbestimmung und E-Rechnungs-Indexierung liefern unverändert dieselben Ergebnisse; fehlender oder falscher Schlüssel und ein fremder Mandanten-KEK führen zu einem Fehler, nie zu Klartext +3. Bestehende Klartextzeilen lassen sich ohne Datenverlust nachverschlüsseln, der Stand ist abfragbar; endgültiges Löschen entfernt Text und Indexeintrag + +## Prüfungen vor der Abnahme +Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen: +1. Rohabfrage der drei Tabellen nach einem Lauf enthält kein Klartextwort, weder in Textspalten noch im Byte-Inhalt der Chiffretexte +2. Falscher Schlüssel, fehlender Schlüsselbezug und Chiffretext einer anderen Revision oder Seite werden abgelehnt +3. Bestandsdaten: Klartext vorher, verschlüsselt nachher, Suche vorher und nachher gleich; zweiter Lauf ändert nichts + +## Nicht Bestandteil dieser Kachel +- Verschlüsselung des Manticore-Index (Restrisiko, siehe Protokoll) +- Verschlüsselung der Metadatenfelder und der Fehlerliste (`findings`) +- Schlüsselrotation der Textschlüssel (der KEK-Wechsel läuft über das Umverpacken des DEK wie bei FDN-09) + +## Arbeitsweise +1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster. +2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche. +3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test. +4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis. +5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code. +6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen. + +## Abschluss +- Commit-Nachricht: `FDN-22: verschlüsselung der textkopien` +- Branch: `feature/fdn-22-verschluesselung-textkopien-dms` +- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy. +- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.