Was der Schutz von CUI tatsächlich in Bezug auf die Schlüsselverwaltung erfordert

Jeder Plattformanbieter, der Verteidigungsauftragnehmer bedient, behauptet, CUI sei verschlüsselt. Diese Aussage verschleiert das entscheidende Detail für den Schutz: Wer besitzt den Schlüssel? Liegt der Schlüssel beim Anbieter, schützt die Verschlüsselung kontrollierte Daten nur vor externen Dritten – nicht aber vor dem Anbieter selbst oder vor jeder Instanz, die den Anbieter rechtlich zur Entschlüsselung zwingen kann.

Für Auftragnehmer, die exportkontrollierte technische Daten über Plattformen von Drittanbietern übertragen, ist dies kein theoretisches Problem. Ein verschlossener Aktenschrank nützt nichts, wenn der Anbieter einen Ersatzschlüssel aufbewahrt und diesen auf Anfrage einer ausländischen Behörde herausgibt. Dieser Artikel beleuchtet, was Schlüsselverwaltung für Verteidigungsauftragnehmer tatsächlich verändert, warum dieses Detail in vielen Sicherheitsprüfungen übersehen wird und was echte, kundeneigene Schlüsselverwaltung in der Praxis erfordert – bis hin zu der Frage, wer den Schlüssel rotieren kann und in welchem Zeitrahmen.

Executive Summary

Sicherheitsprüfungen von Plattformen, die CUI verarbeiten, enden oft bei Verschlüsselungsalgorithmus und Schlüssellänge – als würde AES-256 automatisch alle Exportkontrollanforderungen erfüllen. Das ist nicht der Fall. Entscheidend für den Schutz ist, wer den Schlüssel kontrolliert, denn wer den Schlüssel kontrolliert, kontrolliert die Daten – unabhängig von der Verschlüsselung. Wenn ein Anbieter den Schlüssel im Auftrag des Auftragnehmers erzeugt, speichert und verwaltet, behält er jederzeit die technische Möglichkeit, auf kontrollierte technische Daten zuzugreifen – aus jedem beliebigen Grund, auch ohne Zustimmung oder Wissen des Auftragnehmers. Kundeneigene Schlüsselverwaltung, gestützt durch Hardware, entzieht dem Anbieter diese Möglichkeit vollständig. Für Programm-Sicherheitsverantwortliche wird Verschlüsselung damit von einem Dokumentationspunkt zu einer konkreten, überprüfbaren architektonischen Tatsache, die ein Prüfer direkt im Rahmen einer CMMC– oder Exportkontrollprüfung verifizieren kann.

wichtige Erkenntnisse

1. Verschlüsselung schützt Daten nur vor Parteien, die den Schlüssel nicht besitzen. Liegt der Schlüssel beim Anbieter, hängt der CUI-Schutz von dessen Bereitschaft ab – nicht von der Verschlüsselung selbst.
2. Bring-your-own-key-Modelle entziehen dem Anbieter die Möglichkeit zur Entschlüsselung vollständig und unterstützen so direkt Exportkontrollanforderungen. Ein vom Anbieter verwalteter Schlüssel lässt diese Möglichkeit unabhängig vom Algorithmus oder der Beschreibung im Angebot bestehen.
3. Ein Hardware-Sicherheitsmodul macht den Schlüsselbesitz zu einer physischen Tatsache, nicht zu einer Richtlinie. Ein Schlüssel, der in einem vom Auftragnehmer kontrollierten HSM erzeugt und gespeichert wird, kann selbst mit administrativem Zugriff nicht von der Plattform extrahiert werden.
4. On-Demand-Schlüsselrotation ist Teil echten Besitzes. Ein Auftragnehmer, der den Schlüssel nicht nach eigenem Zeitplan rotieren kann, hat keine vollständige operative Kontrolle über kontrollierte technische Daten.
5. Die Stärke der Verschlüsselung ist irrelevant, wenn die falsche Partei den Schlüssel hält. Für CUI zählt, wer entschlüsseln kann – nicht, wie stark der Algorithmus ist.

Warum die Stärke der Verschlüsselung für CUI die falsche Frage ist

Sicherheitsprüfungen fragen ständig nach Verschlüsselung, und die Antworten beziehen sich fast immer auf den Algorithmus: AES-256 im ruhenden Zustand, TLS 1.3 während der Übertragung. Diese Angaben sind korrekt, aber im Kern nebensächlich.

Verschlüsselte Daten haben immer einen Schlüsselbesitzer

Jede verschlüsselte CUI-Datei hat genau eine Hürde zwischen ihr und dem Klartext: den Schlüssel. Wer diesen Schlüssel besitzt, kann die Daten lesen, sie für andere entschlüsseln oder zur Entschlüsselung gezwungen werden. Eine Datei mit starkem Algorithmus, aber einem vom Anbieter gehaltenen Schlüssel, ist nicht wesentlich besser vor dem Anbieter geschützt als eine mit schwächerer Verschlüsselung – denn in beiden Fällen ist der limitierende Faktor derselbe: Der Anbieter kann darauf zugreifen, wenn er es will oder dazu verpflichtet wird.

Warum Anbieter diesen Unterschied selten hervorheben

Die Dokumentation von Anbietern beschreibt Verschlüsselung meist so, dass sie umfassend klingt: „Verschlüsselt im ruhenden Zustand und während der Übertragung mit branchenüblichen Algorithmen.“ Das ist korrekt, aber unvollständig. Es sagt nichts darüber aus, wer den Schlüssel erzeugt hat, wo er gespeichert ist oder ob die Infrastruktur des Anbieters Zugriff darauf hat – genau diese Lücke soll eine Exportkontrollprüfung schließen.

Was echte kundeneigene Schlüsselverwaltung erfordert

Schlüsselbesitz ist keine einzelne Funktion, sondern eine Kette von Bedingungen, die alle erfüllt sein müssen. Bricht ein Glied, wird die Kontrolle des Auftragnehmers über den Schlüssel theoretisch statt operativ.

Bring Your Own Key versus Anbieter-verwalteter Schlüssel

Im Anbieter-verwalteten Schlüsselmodell erzeugt und speichert die Plattform den Verschlüsselungsschlüssel als Teil ihrer eigenen Infrastruktur – der Auftragnehmer sieht den Schlüssel möglicherweise nie. Im kundeneigenen Schlüsselmodell kontrolliert der Auftragnehmer die Schlüsselerzeugung und -speicherung, meist über ein Hardware-Sicherheitsmodul, das er selbst administriert oder exklusiv nutzt. Der Unterschied: Ein Anbieter kann technisch CUI entschlüsseln – oder eben nicht, unabhängig davon, was die Marketingunterlagen über die Stärke der Verschlüsselung sagen.

Warum Hardware-Sicherheitsmodule wichtiger sind als der Name vermuten lässt

Ein Hardware-Sicherheitsmodul ist ein dediziertes physisches Gerät, das Schlüssel erzeugt, speichert und verwaltet – so, dass selbst mit administrativem Zugriff keine Extraktion möglich ist. Die Integration der Schlüsselverwaltung mit einem HSM – statt die Schlüssel in Software neben der Anwendung zu speichern – macht den Schlüsselbesitz zu einer physischen Einschränkung statt zu einer Konfigurationseinstellung. Ein rein softwarebasierter Anspruch auf kundeneigenen Schlüsselbesitz kann vom Anbieter mit ausreichendem Zugriff auf die eigene Infrastruktur im Prinzip unbemerkt rückgängig gemacht werden. Ein korrekt integriertes HSM schließt diese Möglichkeit durch das Design aus, nicht durch Richtlinien.

Warum Rotation und Cipher-Kontrolle echten Besitz definieren

Den Schlüssel einmal zu halten, ist nicht dasselbe wie ihn dauerhaft zu kontrollieren. Zwei operative Details unterscheiden echten Schlüsselbesitz von einer Behauptung, die auf dem Papier gut aussieht, aber bei Nachfragen eines Prüfers nicht standhält.

On-Demand-Schlüsselrotation

Vermutet ein Auftragnehmer, dass ein Schlüssel kompromittiert wurde – etwa durch gestohlene Zugangsdaten, einen ausscheidenden Mitarbeiter oder einen vermuteten Vorfall –, ist die Fähigkeit, den Schlüssel sofort und ohne Rücksicht auf den Zeitplan oder die Warteschlange des Anbieters zu rotieren, entscheidend für die operative Kontrolle über kontrollierte Daten.

Granulare Kontrolle über Cipher und Protokolle

Die Möglichkeit, bestimmte Cipher Suites zu aktivieren oder zu deaktivieren und festzulegen, welche TLS-Versionen erlaubt sind, ist eine verwandte, aber separate Form der Kontrolle. Ein Auftragnehmer sollte dies nach eigenem Zeitplan steuern können – insbesondere, wenn ein abgekündigter Cipher vor einer Prüfung außer Betrieb genommen werden muss.

Schlüsselverwaltung als Teil der Anbieter-Due-Diligence

Für ein Programm-Sicherheitsteam, das einen Anbieter bewertet, ist der praktische Unterschied einfach zu beschreiben und unter Zeitdruck leicht zu übersehen: Fragen Sie, wer den Schlüssel erzeugt, wo er gespeichert wird, ob ein HSM involviert ist und wer den Schlüssel rotieren kann – und in welchem Zeitrahmen. Ein Anbieter, der alle vier Fragen klar beantwortet und dem Auftragnehmer die Kontrolle über jeden Schritt gibt, bietet ein belastbares Schlüsselverwaltungsmodell. Ein Anbieter, der nur die erste Frage nach Algorithmus und Schlüssellänge beantwortet, sagt dem Auftragnehmer nichts darüber, wer tatsächlich die Kontrolle über CUI nach der Verschlüsselung hat.

Wie eine Data Control Plane Schlüsselbesitz architektonisch garantiert

Kundeneigene Schlüsselverwaltung erfüllt ihr Versprechen nur, wenn sie fester Bestandteil der Plattformarchitektur ist – nicht als Zusatzoption, die in den meisten Implementierungen fehlt. Eine Data Control Plane, die Schlüsselverwaltung als grundlegende Eigenschaft behandelt, stellt sicher, dass der Anbieter technisch nicht in der Lage ist, CUI zu entschlüsseln – über alle Kanäle hinweg, durch die Daten fließen, einschließlich E-Mail, Filesharing, APIs und KI-Agents.

Die Kiteworks Data Control Plane integriert kundeneigene Verschlüsselungsschlüssel über ein Hardware-Sicherheitsmodul – einschließlich Unterstützung für weit verbreitete HSM-Anbieter –, sodass Schlüsselerzeugung und -speicherung außerhalb des Zugriffsbereichs von Kiteworks liegen. Auftragnehmer behalten die Möglichkeit, Schlüssel nach Bedarf zu rotieren, zu steuern, welche Cipher und TLS-Versionen aktiviert sind, und auf Single-Tenant-Architektur zu setzen, bei der die Schlüsselverwaltung nicht mit anderen Kundenumgebungen geteilt wird. Auf dieser Basis steuern datenbewusste, zero-trust-Kontrollen jede Send-, Share- und Zugriffsaktion über alle Kanäle hinweg. Jede Aktion wird in einem fälschungssicheren, nicht gedrosselten Audit Log festgehalten, der direkt in SIEM-Tools eingespeist wird. So wird die Schlüsselverwaltungszusage durch tatsächliche Durchsetzung belegt – nicht nur durch eine Zeile im Angebot.

Auftragnehmer, die das Schlüsselverwaltungsmodell ihres aktuellen Anbieters mit diesem Standard vergleichen möchten, können eine individuelle Demo vereinbaren, um zu sehen, wie die Integration eines kundengesteuerten HSM auf ihre eigenen CUI- und Exportkontrollanforderungen angewendet werden kann.