Sicherheit

Netzwerksicherheit

Die Sandbox-Isolierung wird in jedem Deployment-Modus auf Netzwerkebene durchgesetzt.

Kubernetes (Produktion)

16+ Kubernetes NetworkPolicy-Ressourcen erzwingen Pod-Level-Verkehrsregeln über 7 Namespaces hinweg. Sandbox-A-Pods können keine Verbindungen zu Sandbox-B-Pods herstellen und umgekehrt. Jeder Service hat explizite Ingress- und Egress-Regeln — Default-Deny-Policies blockieren allen nicht explizit erlaubten Verkehr. Der Gateway ist der einzige Service, der mit beiden Sandboxes kommuniziert, und leitet in einer einzelnen Anfrage nie Identitäts- und Token-Daten an denselben nachgelagerten Service weiter.

Docker (Entwicklung)

14 isolierte Docker-Bridge-Netzwerke erzwingen dieselbe Sandbox-Grenze wie in Produktion. Sandbox A und Sandbox B teilen sich nie ein Netzwerk. Servicespezifische Spoke-Netzwerke für Audit, Witness und Bridge-AI-Verbindungen stellen sicher, dass selbst Hilfsdienste die beiden Zonen nicht überbrücken können. Die Invariante wird auf Docker-Netzwerkebene durchgesetzt, nicht im Anwendungscode.

Formale Verifikation

Die zentrale Isolationsinvariante von The Veil ist nicht nur getestet — sie ist mathematisch bewiesen.

Wir pflegen eine TLA+-Formalspezifikation, die jeden vom System erreichbaren Zustand modelliert. Der TLC Model Checker verifiziert, dass eine einzelne Invariante über alle Zustände gilt:

Keine Nachricht mit Identitätsdaten kann die KI-Verarbeitungs-Sandbox erreichen. Dies wird auf Spezifikationsebene verifiziert — bevor Code geschrieben wird, bevor Tests laufen, bevor das Deployment erfolgt.

Kein Wettbewerber im Bereich KI-Datenschutz bietet formale Verifikation seiner Isolationsgrenze. Tests prüfen die Pfade, an die man gedacht hat. Formale Verifikation prüft alle.

Datenverschlüsselung

• GespeichertAES-256-Spaltenverschlüsselung für alle PII-Felder in Sandbox A. Verschlüsselungsschlüssel werden über HashiCorp Vault, AWS KMS oder Azure Key Vault verwaltet, je nach Deployment-Ziel. Verschlüsselung auf Datenbankebene (LUKS / dm-crypt) bildet eine zweite Schicht.
• Bei ÜbertragungDie gesamte Inter-Service-Kommunikation nutzt gRPC über TLS. Externer Verkehr terminiert am Gateway mit erzwungenem TLS 1.2+. Die Zertifikatsrotation ist automatisiert.
• SitzungenSession-Tokens werden mit AES-256-GCM verschlüsselt. Tokens sind zeitlich begrenzt und auf einzelne Verarbeitungsanfragen beschränkt. Keine langlebigen Credentials werden clientseitig gespeichert.

Audit Trail

Entscheidungsdatensätze werden an eine kryptographische Hash Chain angehängt. Die Anwendungsrolle hat nur INSERT- und SELECT-Rechte. Löschungen sind ausschließlich für DSGVO-Art.-17-Löschanträge und Retention-Ablauf zulässig und werden über auditierte SECURITY-DEFINER-Funktionen ausgeführt, die neben jeder Löschung einen signierten Löschnachweis in ein separates Append-only-Log schreiben.

• •Jeder Logeintrag enthält einen SHA-256-Hash des vorherigen Eintrags und bildet so eine verifizierbare Kette.
• •Alle Re-Linkage-Anfragen, Token-Rotationen, Datenzugriffsereignisse und administrative Aktionen werden aufgezeichnet.
• •Prüfer können die Kettenintegrität unabhängig verifizieren, ohne Zugriff auf die zugrunde liegenden Daten.

Zugriffskontrolle

Die Rückverknüpfung eines pseudonymen Tokens mit einer realen Identität ist die sensibelste Operation der Plattform. Sie wird durch mehrere Kontrollschichten gesteuert:

• •Vier-Augen-Prinzip — jede Re-Linkage-Anfrage erfordert die Freigabe durch zwei unabhängig autorisierte Personen.
• •Attribut-basierter Zugriff — Genehmigungen gewähren Zugriff auf bestimmte Datenfelder, nicht den gesamten Identitätsdatensatz.
• •Jurisdiktionskontrollen — Re-Linkage kann nach Rechtsordnung eingeschränkt werden, um Datensouveränitätsanforderungen zu erfüllen.
• •Break-Glass-Mechanismus — Notfallzugriff ist möglich, löst aber erweitertes Audit-Logging, verpflichtende Nachprüfung und automatische Benachrichtigung des Datenschutzbeauftragten aus.

Sicherheitstests

Die Plattform wurde einem adversarialen Red-Team-Test unterzogen, der auf die Sandbox-Isolierungsgrenze abzielte. 17 Findings wurden identifiziert und behoben, darunter:

Alle 17 Findings wurden vor dem aktuellen Release geschlossen. Red-Team-Tests werden bei jedem Major Release durchgeführt.

Compliance-Position

The Veil ist darauf ausgelegt, die technischen Anforderungen der EU-Regulierung zu erfüllen. Die folgenden Zuordnungen sind Architektur- und Nachweis-Mappings, keine bestehenden Zertifizierungen.

DSGVO

• Art. 25Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Pseudonymisierung ist der Standard-Verarbeitungsmodus. Die KI-Sandbox kann strukturell nicht auf Identitätsdaten zugreifen, die über das Erforderliche hinausgehen.
• Art. 32Sicherheit der Verarbeitung. Isolation auf Infrastrukturebene, Spaltenverschlüsselung, Append-only Audit-Logs und Zugriffskontrollmechanismen adressieren die geforderten technischen und organisatorischen Maßnahmen.

KI-Verordnung

• Art. 10Data Governance für Hochrisiko-KI-Systeme. Die Split-Knowledge-Architektur stellt sicher, dass Trainings- und Inferenzdaten verarbeitet werden, ohne die Identität betroffener Personen offenzulegen.
• Art. 15Transparenz und Protokollierung. Der kryptographische Audit Trail liefert einen vollständigen, unveränderlichen Nachweis aller KI-Systementscheidungen und Datenflüsse.

Es handelt sich um Architektur- und Nachweis-Mappings, nicht um bestehende Zertifizierungen. Der aktuelle Launch-Fokus ist die ITSM- / ServiceNow-Vertikale; breitere branchenspezifische Testate (DORA, MDR, eIDAS) sind Folgearbeit und werden heute nicht beansprucht.

Deployment-Modell

Rohe Identitätsdaten verlassen Ihre Umgebung nie. In Split-Deployments überschreiten nur bereinigter Text, opake pseudonyme Tokens und Content-Hashes Infrastruktur-Grenzen — Ihre sensiblen Daten bleiben dort, wo sie hingehören. Vollständig lokales / Air-Gapped-Deployment ist der empfohlene Standard für Gesundheit und Behörden.

• •Deployment via Helm Charts auf jedem Kubernetes-Cluster — Cloud, On-Premise oder Air-Gapped.
• •Vollständig lokales / Air-Gapped-Deployment ist der empfohlene Standard für Gesundheits- und Behörden-Workloads: Alle Komponenten, einschließlich LLM-Inferenz über Ollama oder vLLM, laufen innerhalb der Kundengrenze ohne externe Aufrufe.
• •Sovereign-Cloud-kompatibel. Läuft auf nationaler Cloud-Infrastruktur (z. B. OVHcloud, Scaleway, T-Systems) ohne Anpassungen.
• •Split-Deployment leitet nur bereinigten Text, opake pseudonyme Tokens und Content-Hashes an die entfernte Sandbox B weiter — niemals rohe Identitätsinhalte. Sandbox A, der ID-Bridge, der Sanitizer und der Audit-Dienst bleiben in jeder Deployment-Form innerhalb der Kundengrenze.
• •Kein Vendor Lock-in. Basiert auf PostgreSQL, Redis und Standard-Kubernetes-Primitiven.

Sicherheitskontakt

Um eine Sicherheitslücke zu melden oder zusätzliche technische Dokumentation anzufordern, kontaktieren Sie: