Technische Daten unter Kontrolle – in einer Jurisdiktion Ihrer Wahl

Ein Rüstungsunternehmen, das mit kontrollierten, nicht klassifizierten Informationen arbeitet, kann in der Regel angeben, in welchem Land seine Systeme gehostet werden. Weniger Unternehmen können jedoch beantworten, ob der Betreiber dieser Systeme selbst einer ausländischen Gerichtsbarkeit unterliegt, die unabhängig vom Hosting-Standort Zugriff erzwingen könnte – eine Frage, die direkte Auswirkungen auf die Einhaltung von Exportkontrollvorgaben und die Vertragsfähigkeit mit Hauptauftragnehmern und staatlichen Kunden hat.

Die Speicherung von CUI innerhalb der Region erfüllt lediglich eine Residenzanforderung. Sie beantwortet jedoch nicht die Frage, ob der Betreiber der Infrastruktur durch eine ausländische Anordnung verpflichtet werden könnte, lesbare kontrollierte technische Daten bereitzustellen – unabhängig davon, wo die Server stehen. Dieser Artikel erklärt, warum Datenhoheit für Rüstungsunternehmen und Hersteller, die CUI verarbeiten, eine architektonische Fragestellung ist – kein Häkchen im Hosting-Regionen-Formular – und wie sich die Lücke zwischen Speicherort und tatsächlicher Verfügungsgewalt schließen lässt.

Executive Summary

Rüstungsunternehmen und Hersteller, die CUI und exportkontrollierte technische Daten verarbeiten, unterliegen sowohl vertraglichen als auch regulatorischen Anforderungen an die Datenhoheit. Die Residenz beantwortet nur, wo Daten gespeichert werden. Entscheidend ist jedoch, ob der Plattformanbieter durch eine ausländische Behörde zur Herausgabe dieser Daten gezwungen werden kann – und das hängt von der Gerichtsbarkeit und dem Schlüsselbesitz des Anbieters ab, nicht vom Hosting-Standort. Für Verantwortliche in den Bereichen Programm-Sicherheit und Compliance bestimmt dies die Vertragsfähigkeit – nicht nur die Datensicherheitslage. Ein CMMC-Assessor oder eine Exportkontrollprüfung fragt gezielt nach Gerichtsbarkeit und Schlüsselbesitz, statt sich mit der Adresse eines Rechenzentrums als Nachweis für den Schutz zufriedenzugeben.

Wichtige Erkenntnisse

1. Der Serverstandort bestimmt nicht die rechtliche Zugriffsmöglichkeit auf kontrollierte technische Daten. Die Gerichtsbarkeit des Anbieters entscheidet, was herausgegeben werden kann – unabhängig von Hosting-Geografie oder regionalen Rechenzentrumsangaben des Anbieters.
2. Extraterritoriale Zugriffsgesetze wirken grenzüberschreitend – unabhängig vom Hosting-Standort. Ein Anbieter, der einer ausländischen Gerichtsbarkeit unterliegt, kann zur Herausgabe von CUI gezwungen werden, selbst wenn das Rechenzentrum vollständig außerhalb des Heimatlandes dieser Behörde steht.
3. Multi-Tenant-Infrastrukturen schaffen ein Risiko der Querverletzlichkeit zwischen Programmen. Eine einzige Schwachstelle kann Daten über verschiedene, nicht zusammenhängende Verträge und konkurrierende Hauptauftragnehmer hinweg kompromittieren, die auf derselben geteilten Plattform laufen.
4. Kundenverwaltete Verschlüsselungsschlüssel bedeuten, dass eine ausländische Anordnung nur Chiffretext liefert. Dies unterstützt direkt die Exportkontroll- und CUI-Schutzpflichten, nach denen ein Assessor explizit fragt.
5. Die Wahl des Bereitstellungsmodells ist eine vertragliche und regulatorische Entscheidung – kein Standard des Anbieters. On-Premises, selbst gehostet oder dediziertes Hosting bestimmen die tatsächliche Kontrolle über kontrollierte Daten. Jede Option ist eine bewusste Entscheidung des Auftragnehmers – kein Automatismus.

Die rechtliche Realität hinter In-Country-Hosting für kontrollierte Daten

Ein Anbieter, der in seinem Heimatland extraterritorialen Zugriffsgesetzen unterliegt, bleibt diesen Gesetzen unterworfen – unabhängig davon, wo die Daten eines bestimmten Programms gespeichert werden. Für CUI und exportkontrollierte technische Daten ist genau dies das Risiko, das Exportkontrollrahmen verhindern sollen – und ein Hostingvertrag allein macht diesen Unterschied nicht transparent.

Warum die Adresse eines Rechenzentrums nicht die rechtliche Zugriffsmöglichkeit bestimmt

Extraterritoriale Gesetze verpflichten einen Anbieter zur Herausgabe von Daten, die sich in seinem Besitz, seiner Obhut oder Kontrolle befinden – unabhängig davon, wo diese Daten gespeichert sind. Ein Anbieter mit Hauptsitz in einer Gerichtsbarkeit, der für seine Kunden im Verteidigungssektor ein regionales Rechenzentrum betreibt, unterliegt weiterhin den Gesetzen seines Heimatlandes – unabhängig davon, in welcher Region die Server eines bestimmten Programms stehen. Die regionale Kennzeichnung ist eine Marketing- und Betriebsentscheidung, aber keine Änderung der rechtlichen Exponierung.

Wie sich dadurch die Risikobewertung für Programm-Sicherheit verändert

Die Aufgabe von Sicherheitsverantwortlichen endet nicht mit der Bestätigung des Serverstandorts. Die entscheidende Frage ist, ob irgendeine Behörde – egal wo – den Anbieter zur Herausgabe von CUI zwingen kann und ob der Anbieter technisch überhaupt dazu in der Lage wäre. Genau diese Frage wird ein CMMC-Assessor oder eine Exportkontrollprüfung stellen. Ein Beschaffungsprozess, der bei der Geografie stehenbleibt, hat nichts über das tatsächliche Risiko verifiziert.

Warum geteilte Infrastrukturen Querverletzlichkeiten zwischen Programmen schaffen

Multi-Tenant-Plattformen, die mehrere Auftragnehmer und Hauptauftragnehmer bedienen, bedeuten: Eine einzige Schwachstelle kann Daten über verschiedene, nicht zusammenhängende Programme hinweg kompromittieren – auch zwischen konkurrierenden Bietern, die auf derselben geteilten Infrastruktur arbeiten, ohne voneinander zu wissen.

Geteilte Infrastruktur bedeutet geteiltes Schicksal zwischen konkurrierenden Programmen

Wenn mehrere Auftragnehmer auf derselben Multi-Tenant-Plattform arbeiten, kann eine kompromittierte Zugangsdaten, eine falsch konfigurierte Richtlinie oder eine rechtliche Anordnung für diese Plattform weitreichende Folgen haben – weit über die Daten eines einzelnen Auftragnehmers hinaus. Multi-Tenancy ist für den Anbieter effizient, da sie die Betriebskosten auf viele Kunden verteilt, konzentriert das Risiko jedoch genau dort, wo Sicherheitsteams es eigentlich minimieren wollen. Eine Single-Tenant-Architektur eliminiert dieses geteilte Risiko auf Infrastrukturebene vollständig.

Was echte Datenhoheit für Auftragnehmer über den Standort hinaus erfordert

Echte Souveränität basiert auf drei ineinandergreifenden Faktoren: Infrastruktur-Isolierung, Schlüsselbesitz und bewusste Wahl der Gerichtsbarkeit. Der Standort ist nur ein Aspekt der Gerichtsbarkeitswahl – und ohne die beiden anderen bedeutungslos.

Single-Tenant-Architektur als Fundament

Single-Tenant-Bereitstellung bedeutet, dass Datenbanken, Dateisysteme, Anwendungsumgebung und Betriebssystem eines Auftragnehmers nicht mit anderen Kunden geteilt werden. So kann der Auftragnehmer exakt bestimmen, wo seine dedizierte Infrastruktur betrieben wird – ob On-Premises, selbst gehostet in der eigenen Cloud-Umgebung oder als dedizierte Hosting-Instanz. Der Bereitstellungsstandort ist damit eine bewusste Entscheidung – kein Standard des Anbieters.

Kundenverwaltete Verschlüsselungsschlüssel als rechtliche Absicherung für CUI

Infrastruktur-Isolierung löst die operative Seite der Souveränität, nicht aber die rechtliche – dafür braucht es Schlüsselbesitz. Hält der Auftragnehmer seine eigenen Verschlüsselungsschlüssel – typischerweise über ein Hardware Security Module – liefert eine rechtliche Anordnung an den Anbieter nur Chiffretext, keine verwertbaren technischen Daten. Das ist keine Verweigerung des Anbieters, sondern architektonisch unmöglich: Der Anbieter kann nur Daten übergeben, die er selbst nicht entschlüsseln kann. Dies unterstützt direkt die technischen Schutzmaßnahmen, die Exportkontrollregime verlangen, und macht aus einem rechtlichen Risiko ein Nicht-Ereignis.

Datenhoheit operationalisieren statt voraussetzen

Sicherheitsverantwortliche sollten Datenhoheit architektonisch nachprüfen – nicht auf Basis von Marketingaussagen des Anbieters voraussetzen. Das bedeutet: Klären, welcher Gerichtsbarkeit der Anbieter tatsächlich unterliegt – nicht nur, wo das Rechenzentrum steht; prüfen, ob die Bereitstellung wirklich Single-Tenant ist oder nur ein segmentierter Bereich einer geteilten Plattform; und feststellen, wer die Verschlüsselungsschlüssel tatsächlich hält und unter welchen Bedingungen diese herausgegeben werden könnten. Diese drei Fragen konsequent für jeden Anbieter zu beantworten, der CUI verarbeitet, macht Souveränität für einen Assessor nachweisbar – statt sie als Annahme in einen Unterauftrag einzubetten.

Wie eine Data Control Plane Datenhoheit auf Verteidigungsniveau unterstützt

Das bedeutet nicht, dass Auftragnehmer ihre Infrastruktur von Grund auf selbst bauen müssen, um echte Souveränität zu erreichen. Es bedeutet, eine Plattform zu wählen, bei der Gerichtsbarkeit, Isolierung und Schlüsselbesitz architektonische Eigenschaften sind – keine vertraglichen Versprechen. Das leistet eine Data Control Plane: Eine Governance-Schicht, die sich über alle Kanäle legt, über die Daten fließen – einschließlich E-Mail, Filesharing, APIs und KI-Agents – und steuert, wer sensible Daten von wo, unter welchen Bedingungen senden, teilen oder verschieben darf.

Die Kiteworks Data Control Plane basiert auf einer Single-Tenant-Architektur, die On-Premises, in der eigenen Cloud-Umgebung des Auftragnehmers oder als dedizierte Hosting-Instanz bereitgestellt werden kann – mit kundenverwalteten Verschlüsselungsschlüsseln über ein Hardware Security Module, sodass keine externe Partei, auch nicht Kiteworks, CUI entschlüsseln kann. Darüber hinaus steuern datenbewusste zero-trust-Kontrollen jeden Versand, jede Freigabe und jeden Zugriff über alle Kanäle hinweg. Jede Aktion wird in einem manipulationssicheren, nicht gedrosselten Audit-Log erfasst, der direkt in SIEM-Tools eingespeist wird – und so Auftragnehmern die Nachweise liefert, die ein Assessor tatsächlich verlangt, statt bloßer Zusicherungen im Angebot.

Auftragnehmer, die ihre eigene CUI-Souveränität an diesem Standard messen möchten, können eine individuelle Demo vereinbaren, um zu sehen, wie Single-Tenant-Architektur mit kundenverwalteten Schlüsseln auf ihre Programm-Anforderungen angewendet werden kann.