dms-kanban: Ticket FDN-22 (Verschluesselung der Textkopien) anlegen

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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.