Die Anforderung an die Luftdichtung
Verteidigungsauftragnehmer, Regierungsgeheimdienste und Betreiber kritischer Infrastrukturen verwalten Netzwerke, bei denen eine externe Internetverbindung physisch unmöglich ist, nicht nur durch Richtlinien verboten. Ein SCIF (Sensitive Compartmented Information Facility) ist ein Raum oder eine Einrichtung, die darauf ausgelegt ist, elektronisches Abhören und die Sammlung von Signals Intelligence zu verhindern – es ist faradaysch abgeschirmt, ohne dass drahtlose Signale ein- oder ausgehen. Ein klassifiziertes Regierungsnetzwerk unter ITAR (International Traffic in Arms Regulations) Kontrolle kann keine geschützten technischen Daten an nicht genehmigte Parteien übertragen – eine Kategorie, die Cloud-Dienstanbieter umfasst, die nicht unter ITAR genehmigt sind.
Für Organisationen in diesen Umgebungen ist "Cloud SaaS" kein Risiko, das verwaltet werden muss – es ist eine technische Unmöglichkeit. Jedes Anonymisierungstool, das eine aktive Netzwerkverbindung benötigt, kann nicht eingesetzt werden. Jedes Tool, das zur Lizenzverifizierung nach Hause telefoniert, ist ein No-Go. Jedes Tool, dessen Erkennungsmodelle Cloud-API-Aufrufe zur Inferenz erfordern, kann nicht funktionieren.
Die Ollama-Community nennt speziell die luftdichte Bereitstellung als das Hauptargument für lokale KI-Tools: "Alle Daten bleiben auf Ihrem Gerät mit Ollama, ohne dass Informationen an externe Server gesendet werden – besonders wichtig für sensible Arbeiten wie Ärzte, die Patientennotizen bearbeiten, oder Anwälte, die Akten prüfen." Dasselbe Argument gilt auf organisatorischer Ebene für klassifizierte und ITAR-kontrollierte Umgebungen.
Der ITAR-Anwendungsfall
Ein Datenwissenschaftler bei einem Verteidigungsauftragnehmer, der Personalakten unter ITAR-Anforderungen verarbeitet, muss Dateien anonymisieren, bevor er sie einem Journalist, der eine FOIA-Anfrage stellt, zur Verfügung stellt. Das Netzwerk des Auftragnehmers ist luftdicht. Die Verarbeitung muss auf der luftdicht abgeschotteten Maschine erfolgen und Ausgaben produzieren, die für die öffentliche Veröffentlichung geeignet sind.
Dieser Anwendungsfall hat keine Cloud-Lösung. Der einzige Weg ist ein Tool, das vollständig auf der lokalen Maschine läuft, Erkennungsmodelle lokal anwendet und anonymisierte Ausgaben ohne externe Kommunikation produziert. Die auf Tauri 2.0 basierende Desktop-Anwendung läuft genau in dieser Konfiguration: Nach dem Download und der Installation werden während der Dokumentenverarbeitung keine Netzwerkaufrufe getätigt. Die spaCy NER-Modelle, die Regex-Muster und die Transformer-Inferenz laufen lokal. Die Verarbeitungsausgabe verlässt die Maschine niemals, es sei denn, sie wird ausdrücklich vom Benutzer exportiert.
Umkehrbare Pseudonymisierung für klassifizierte Operationen
Eine verwandte Anforderung in klassifizierten und staatlichen Kontexten: umkehrbare Pseudonymisierung, die die analytische Nützlichkeit aufrechterhält und gleichzeitig die echten Identitäten schützt. Artikel 4(5) der GDPR erkennt Pseudonymisierung formal als Maßnahme zum Datenschutz an, die das Compliance-Risiko verringert – pseudonymisierte Daten unterliegen im Vergleich zu vollständig identifizierbaren Daten reduzierten Verpflichtungen, vorausgesetzt, die Pseudonymisierungsschlüssel werden getrennt vom pseudonymisierten Datensatz aufbewahrt.
IAPP-Forschung (2024) ergab, dass nur 23 % der Anonymisierungstools echte Umkehrbarkeit bieten – die Fähigkeit, pseudonymisierte Daten mit einem Schlüssel, der getrennt von der Ausgabe aufbewahrt wird, wieder in die ursprünglichen Werte zu entschlüsseln. Die Mehrheit der Tools implementiert permanente Ersetzung (die ursprünglichen Daten werden überschrieben und können nicht wiederhergestellt werden) oder Maskierung (teilweise Anzeige des ursprünglichen Wertes).
Für Regierungsoperationen, bei denen pseudonymisierte Datensätze zwischen Abteilungen teilbar sein müssen – ein Team erhält den pseudonymisierten Datensatz für analytische Arbeiten, ein anderes Team hält den Entschlüsselungsschlüssel für die Re-Identifizierung, wenn dies rechtlich erforderlich ist – ist umkehrbare Verschlüsselung mit Schlüsseltrennung die einzige konforme Architektur.
Der Zero-Knowledge-Ansatz geht noch weiter: Der Verschlüsselungsschlüssel wird clientseitig generiert und niemals übertragen. Selbst wenn der Anbieter des Anonymisierungstools vorgeladen wird, kann er den Entschlüsselungsschlüssel nicht vorlegen, da er ihn niemals erhalten hat. Für klassifizierte Umgebungen, in denen die Beweiskette für Verschlüsselungsschlüssel selbst eine Sicherheitsanforderung ist, bietet diese Architektur die erforderliche Sicherheit.
EDPB-Leitlinien-Compliance
Die EDPB-Leitlinien 05/2022 zur Pseudonymisierung erfordern die Schlüsseltrennung: Der Pseudonymisierungsschlüssel muss von einer anderen Partei gehalten werden als der Partei, die den pseudonymisierten Datensatz erhält, oder mit technischen Kontrollen gespeichert werden, die verhindern, dass die empfangende Partei sowohl auf die Daten als auch auf den Schlüssel gleichzeitig zugreifen kann.
Die Kombination aus clientseitiger Schlüsselgenerierung (der Schlüssel verlässt niemals das Gerät des Benutzers), lokaler Verarbeitung (Daten verlassen niemals die luftdicht abgeschottete Umgebung) und separatem Export von pseudonymisierten Ausgaben und Entschlüsselungsschlüsseln erfüllt die Anforderung der EDPB zur Schlüsseltrennung und erfüllt gleichzeitig die operationale Einschränkung der Luftdichtheit.
Quellen: