Blog
Sicherheit

Die Dokumenten-DLP-Pipeline: Masken, die halten

Die Dokumenten-DLP: drei Erkennungsebenen, dokumentweite nummerierte Platzhalter, ein totales Re-Embed, AES-256-GCM-Originale - zwei explizite Unmask-Schranken. Census: F-DLP-1.

Simmetric Team8 Min. Lesezeit13/10/2026
Die Dokumenten-DLP-Pipeline: Masken, die halten

Das Dokument geht einmal hinein; der Platzhalter bleibt

Die Knowledge Base eines AI-Workspaces ingested echte Dokumente - Verträge, HR-Schreiben, Rechnungen. Manche tragen die Daten, die niemand beiläufig lesen sollte, und ein LLM sollte sie nie zitieren. Die Antwort von Simmetric Chat für aktivierte Workspaces: eine Dokumenten-Scan-Pipeline, die die sensiblen Entitäten in dokumentweite nummerierte Platzhalter verwandelt und die einzige saubere Kopie verschlüsselt hält. Der Punkt des Entwurfs ist der letzte Halbsatz - der Platzhalter bleibt: Die Maskierung ist nach Konstruktion einseitig, sodass „das Dokument" und „der suchbare Korpus" dem Entwurf nach verschiedene Objekte werden.

Dieser Artikel geht die Pipeline so durch, wie der Bediener ihr begegnet: der asynchrone Scan, die drei Erkennungsebenen, was ein Platzhalter garantiert, was beim Re-Embedding passiert, wie die Originale gelagert werden, und die zwei Unmask-Schranken (Chat-Re-Komposition, Vorschau-Unmask), die die saubere Kopie nur absichtlich erreichbar machen.

Eine optionale Enterprise-Funktion, je Workspace aktivierbar und standardmässig aus (der Workspace-Schalter + die Evaluations-Schranke). Fakten: FACT-CENSUS.md F-DLP-1.

Der Scan: asynchron, in der Warteschlange, nach dem Ingest

Wenn der Dokumentenscan für einen Workspace aktiviert ist, durchläuft jedes hochgeladene Dokument nach dem Ingest einen asynchronen pg-boss-Scan - der Upload-Pfad bleibt responsive, und der Scan verhält sich wie jeder andere Hintergrund-Job der Plattform: in der Schlange, wiederholt, beobachtbar. Ein Legacy-Korpus hat sein eigenes Backfill (an der Evaluierung gegendert und in der Oberfläche ausdrücklich bestätigt), unter der Live-Schlange limitiert und wieder aufnehmbar: eine Marker-Spalte (dlpScannedAt) bindet jeden Re-Lauf an die nie gescannten Dokumente.

Erkennen: drei Ebenen

Die Erkennung ist eine 3-Ebenen-Pipeline, jede für das, was sie ist:

  1. Admin-konfigurierbare Regex-Patterns - der Pattern-Dienst, den die Verwaltung pflegt (jedes Pattern an/aus, Testvorschauen).
  2. Checkpoint-Validierung für die festformatierten italienischen/europäischen Identifikatoren - Codice Fiscale (die omocodia-Prüfung eingerechnet), P.IVA, IBAN: Diese Klassen sind deterministisch; ein String, der seine Checksumme verfehlt, ist kein Identifikator, sodass gewöhnliche Zahlen sie nie auslösen.
  3. Die kontextuelle LLM-Erkennung für Namen/Adressen - die kontextuellen Klassen durchlaufen das Modell; ihr Recall ist ein gemessener, dokumentierter Wert, kein Versprechen.

Zwei benannte Klassen sind deterministisch (die Checksummen) und zwei sind kontextuell (die LLM-Klassen) - und die Evaluations-Schranke misst genau diese Spaltung: Die Qualitätsschwelle zur Aktivierung = null unterdrückte Falschtreffer auf den deterministischen Klassen, mit dokumentiertem Recall der kontextuellen Klassen pro Lauf.

Die Zahl, die dieser Beitrag nie drucken wird: eine Zählung „wie viele PII-Typen es gibt". Der Census-Vertrag ist explizit - nicht rückverfolgbare Zahlen versandt man nicht; die Klassen werden benannt, der Code sagt, was er erkennt.

Maskieren: nummerierte Platzhalter, die nicht wieder matchen

Erkannte Entitäten werden zu dokumentweiten nummerierten Platzhaltern ([PERSON_1], [GOV_ID_2], ...). Drei Eigenschaften machen das bedeutsam:

  • Dokumentweite Kohärenz - dieselbe Entität ist derselbe Platzhalter durchs ganze Dokument; das LLM liest ein einheitliches Dokument weiter.
  • Idempotenz - Maskierung ist ihr eigener Fixpunkt: Die Platzhalter-Syntax kann nie wieder matchen, sodass ein Re-Scan nie Artefakte der [PERSON_1_1]-Klasse produziert.
  • Die Umschrift ist total - die Chunks werden mit dem maskierten Text umgeschrieben, die FTS-Vektoren neu gerechnet, und die Embeddings auf den maskierten Text neu erzeugt. Kein ungeschwärzter Vektor bleibt suchbar.

Verschlüsseln: die einzige saubere Kopie ist AES-256-GCM

Der Originale-Text und jeder Entitätenwert landen verschlüsselt (AES-256-GCM unter dem Schlüsselvertrag der Plattform). Das macht die Pipeline ehrlich: Maskierung ist kein „Verstecken in einer Ansichtsschicht" - die unmaskierten Bytes existieren im Speicher schlicht nicht unverschlüsselt. Die verschlüsselten Originale sind die einzige saubere Kopie.

Die zwei Unmask-Schranken

Die saubere Kopie ist durch genau zwei Schranken erreichbar, beide ausdrücklich:

  1. Chat-Re-Komposition - am Streamende, genau einmal, re-komponiert der Server die Platzhalter in der Endnachricht nur für Nutzer mit dem dlp:unmask-Recht im Workspace des zitierten Dokuments. Der re-komponierte Text reist im SSE-done-Payload; Widget-Besucher erhalten nie re-komponierten Text (serverseitig erzwungen, nicht durch Verstecken einer Schaltfläche).
  2. Vorschau-Unmask - der Dokumenttext-Endpoint liefert standardmässig den maskierten Text; ein Unmask-Parameter wirkt nur durch die Schrankenleiter (der Parameter vorhanden, der Workspace-Schalter an, die Rolle mit dem Recht). Jeder Fehlarm bleibt maskiert mit einem 200 - der Endpoint ist nie ein Berechtigungs-Orakel.

Die Audit-Matrix

Jeder Lesepfad ist durch einen Verhaltenstest verankert (die Textansicht, die OCR-Vorschau, die Synthese, Zitationen, das Widget, die MCP-Tools, die Volltextsuche, die Exporte, der Admin-Re-Embed). Die drei härtesten Stifte sind die „Nie"-Arme: Widget-Besucher, die Zitations- und die MCP-Oberflächen erhalten maskierten Text und nie eine Re-Komposition. Die Audit-Log-Klasse (das unveränderliche Ereignisregister der Plattform, F-AUDIT-1) protokolliert die Operationen, die die Fläche berühren.

Weiterlesen

Die Anleitung trägt den kompletten Bediener-Durchgang - den Schalter, den Evaluationsläufer, das Backfill, jeden Endpunkt - unter /de/docs/document-dlp-pipeline:

  • Document DLP pipeline - die Anleitung
  • Fakten dieses Beitrags: Zeilen FACT-CENSUS.md F-DLP-1 (die Pipeline), F-DLP-2 (die Entscheidung der nicht rückverfolgbaren Zählung), F-AUDIT-1 (das Ereignisregister)

Provenance: Simmetric Chat docs/DLP_DOCUMENT_PIPELINE.md (v0.28.1, Phase 192 DLP-01..06), packages/server/src/services/ (dlpPatternService/dlpChecksum/quota services), encryptionService - am vom Census fixierten Dokumentenstand (SHA aca5b8ff).

Ähnliche Artikel