Sicherheit und DSGVO

Ein System, das Emails verarbeitet, hält automatisch sensible Daten: Namen und Adressen aus dem From-Feld, Vertragsinhalte im Body, interne Kommunikation in den Anhängen. Dieses Kapitel beschreibt, wie das System diese Daten schützt, welche Rollen welchen Zugriff haben und wie die Aufbewahrungs- und Löschfristen geregelt sind. Die rechtliche Einordnung im Einzelfall liegt bei der verantwortlichen Stelle, dieses Dokument liefert die Bausteine.

Bausteine des Datenschutzmodells

Vier Bausteine tragen den Schutz im laufenden Betrieb: eine Authentifizierung, die jeden API-Aufruf an einen identifizierbaren Token bindet; eine Verschlüsselung der Roh-Emails in der Datenbank; eine durchgehend lokale Verarbeitung, die keine Daten an externe Dienste übergibt; und eine Aufbewahrungspolitik, die zusammen mit dem Audit-Log die DSGVO-Anforderungen erfüllt.

Authentifizierung und Zugriffskontrolle

Die REST-API ist durch Bearer-Token-Authentifizierung geschützt, sodass jeder Aufruf einen Token im HTTP-Header mitschickt. In der Datenbank liegt nicht der Token im Klartext, sondern sein SHA-256-Hash, zusammen mit Ablaufdatum, Berechtigungen und Nutzungszähler. Der Klartext wird einmalig bei der Erzeugung ausgegeben und ist anschließend nicht mehr lesbar.

Die Berechtigungen orientieren sich an drei Rollen: ein Administrator hat Vollzugriff, ein Operator kann Emails ansehen, Entwürfe freigeben und Suchen ausführen, ein Betrachter darf nur lesen. So bekommt jede Person genau den Zugriff, den sie für ihre Aufgaben braucht, und kein einziges Recht mehr.

Verschlüsselung der Rohdaten

Jede Email wird als vollständiger MIME-Text in der Datenbank abgelegt, weil sich nur so spätere Schritte rekonstruieren lassen. Diese Rohdaten enthalten häufig vertrauliche Informationen, deshalb sind sie verschlüsselt: AES-256-CBC mit einem zufälligen Initialisierungsvektor pro Email. Der Schlüssel liegt nicht in der Datenbank, sondern in der Credentials-Datei, die nur der Anwendungs-User lesen darf.

Beim Lesen wird automatisch entschlüsselt. Wer direkten Datenbankzugriff hat (etwa über eine SQL-Konsole), sieht nur Base64-kodierten Krypttext und kommt ohne den Schlüssel nicht an die Inhalte heran.

Lokale Verarbeitung

Eine zentrale Designentscheidung: kein Text verlässt den Server. Das Sprachmodell läuft über Ollama auf eigener Hardware, das Embedding-Modell ebenso, und die Entitätenextraktion nutzt einen lokalen Python-Service. Es gibt keinen Cloud-LLM-Aufruf, keine externe API für Textanalyse und keine Telemetrie nach außen. Alle personenbezogenen Daten bleiben in der Infrastruktur, in der sie ankommen, und das Datenschutzkonzept lässt sich mit dieser Aussage in einem Satz zusammenfassen.

Aufbewahrungsfristen und Anonymisierung

Die DSGVO verlangt, dass personenbezogene Daten nicht länger gespeichert werden als nötig. Das System setzt diese Anforderung über drei Stufen um.

• Archivierung: Emails im Status awaiting_review oder sent werden nach einer konfigurierbaren Frist automatisch archiviert.
• Anonymisierung: Kontaktprofile ohne neue Aktivität werden anonymisiert, indem Name und Email-Adresse durch Platzhalter ersetzt werden.
• Endgültige Löschung: Gelöschte Emails werden nach einer weiteren Frist endgültig aus der Datenbank entfernt.

Drei Lösch-Ebenen

Jede Löschung gehört einer der folgenden Ebenen an, und jede Ebene hat ihre eigene Auslöser-Logik:

• Benutzer-Löschung: systemweit verboten. Benutzer können Emails archivieren oder als rejected markieren, eine echte Löschung steht ihnen nicht offen.
• Admin-Löschung: über Kommandozeile oder Admin-Oberfläche, audit-pflichtig. Jede Admin-Löschung erzeugt einen deleted_at-Eintrag im Audit-Log.
• Retention- und DSGVO-Löschung: automatisch über Cron, sobald die Aufbewahrungsfrist der Kategorie abgelaufen ist oder ein DSGVO-Antrag vorliegt.

Aufbewahrung pro Kategorie

Pro Kategorie ist hinterlegt, wie eine Email nach ihrer Aufbewahrungsfrist behandelt wird, entweder automatisch oder mit manueller Freigabe.

Lösch-Pfad über alle Speicher

Jede Admin- oder Retention-Löschung folgt einer festen Reihenfolge, damit keine Inkonsistenz zwischen den drei Speichern entsteht. Zuerst löscht das System in MariaDB, weil sie die Source of Truth für strukturierte Daten ist. Anschließend folgt Qdrant, weil die Embeddings sich aus dem Text rekonstruieren ließen, falls etwas schief ginge. Danach kommt ArangoDB, weil sich der Wissensgraph ebenfalls neu aufbauen lässt. Zum Schluss wird der Anhang-Speicher bereinigt. Der Audit-Log-Eintrag bleibt erhalten und wird nur anonymisiert, sodass die Tatsache der Löschung nachvollziehbar bleibt. Backups folgen einer rollierenden Aufbewahrung von maximal 90 Tagen, danach werden sie physisch entfernt.

Audit-Trail

Jede Aktion im System wird im Audit-Log protokolliert, und zwar mit Zeitstempel, Akteur (Mensch oder System), betroffener Email und der Art der Aktion. Der Audit-Trail ist append-only: Einträge werden nur hinzugefügt und niemals gelöscht oder geändert. Damit lässt sich jede Entscheidung im Nachhinein nachvollziehen, was sowohl für interne Reviews als auch für Auskünfte gegenüber Betroffenen die Grundlage liefert.

Zusammen mit der lokalen Verarbeitung ergibt sich ein Sicherheitsmodell, das Datenschutz nicht als nachträglich angeklebte Schicht behandelt, sondern in jeden Verarbeitungsschritt einbaut.