Ein vom Anbieter gehaltener Schlüssel bedeutet, dass der Anbieter die Designdatei lesen kann.

Jeder Plattformanbieter für Hersteller behauptet, Konstruktionsdateien seien verschlüsselt. Diese Aussage verschleiert jedoch das entscheidende Detail für den Schutz: Wer besitzt den Schlüssel? Liegt der Schlüssel beim Anbieter, schützt die Verschlüsselung vertrauliche Konstruktionsdaten nur vor Dritten – nicht aber vor dem Anbieter selbst oder vor Behörden, die den Anbieter per Gerichtsbeschluss zur Entschlüsselung zwingen können.

Für Hersteller, die CAD-Dateien, Stücklisten und Lieferantendaten weltweit austauschen, ist das keine theoretische Sorge. Ein Tresor ist wertlos, wenn der Anbieter einen Ersatzschlüssel besitzt und ihn bei Anfrage sofort herausgibt. Dieser Artikel beleuchtet, was die Schlüsselverwaltung für Hersteller tatsächlich verändert, warum dieses Detail in Sicherheitsprüfungen oft übersehen wird und was echtes, kundeneigenes Schlüsselmanagement in der Praxis erfordert – bis hin zu der Frage, wer den Schlüssel wann rotieren kann.

Executive Summary

Sicherheitsprüfungen von Plattformen für technische Daten enden oft bei Verschlüsselungsalgorithmus und Schlüssellänge, als würde AES-256 automatisch für sicheren Schutz sorgen. Das stimmt nicht. Entscheidend ist, wer den Schlüssel kontrolliert – denn wer den Schlüssel kontrolliert, kontrolliert auch die Daten, unabhängig von der Verschlüsselung. Generiert, speichert und verwaltet der Anbieter den Schlüssel für den Hersteller, kann der Anbieter die Konstruktionsdateien jederzeit auslesen – aus beliebigen Gründen, auch ohne Wissen oder Zustimmung des Herstellers. Kundeneigenes Schlüsselmanagement, abgesichert durch Hardware, schließt diese Möglichkeit vollständig aus. Für Verantwortliche aus Technik und IT wird Verschlüsselung so von einer Anbieterbehauptung zu einer überprüfbaren architektonischen Tatsache.

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 Schutz der Konstruktionsdaten vom guten Willen des Anbieters ab – nicht von der Verschlüsselung selbst.
2. Bring-your-own-key-Modelle entziehen dem Anbieter die Möglichkeit zur Entschlüsselung vollständig. Ein vom Anbieter verwalteter Schlüssel lässt diese Möglichkeit uneingeschränkt bestehen, unabhängig vom Algorithmus oder dessen Vermarktung.
3. Ein Hardware Security Module macht den Schlüsselbesitz zu einer physischen Tatsache, nicht zu einer Richtlinie. Ein im HSM des Herstellers generierter und gespeicherter Schlüssel kann von der Plattform, die die Daten hostet, selbst bei administrativem Zugriff nicht extrahiert werden.
4. On-Demand-Schlüsselrotation ist Teil echten Eigentums. Ein Hersteller, der den Schlüssel nicht nach eigenem Zeitplan rotieren kann, hat keine vollständige Kontrolle über seine Geschäftsgeheimnisse.
5. Die Stärke der Verschlüsselung ist irrelevant, wenn die falsche Partei den Schlüssel besitzt. Für Geschäftsgeheimnisse zählt nur, wer entschlüsseln kann – nicht, wie stark der Algorithmus ist.

Warum Verschlüsselungsstärke für Konstruktionsdaten 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 – und gehen am Kern vorbei.

Verschlüsselte Daten haben immer einen Schlüsselbesitzer

Jede verschlüsselte Konstruktionsdatei hat genau eine Hürde bis zur Klartextansicht: 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 besser vor dem Anbieter geschützt als eine Datei mit schwächerer Verschlüsselung – denn in beiden Fällen bleibt der Anbieter in der Lage, die Datei zu lesen, wenn er es will oder dazu verpflichtet wird.

Warum Anbieter diesen Unterschied selten hervorheben

In der Anbieterdokumentation klingt Verschlüsselung oft umfassend: „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 generiert hat, wo er gespeichert wird oder ob die Infrastruktur des Anbieters darauf zugreifen kann. Ein Hersteller, der sich nur auf diese Aussage verlässt, hat für die Sicherheitsprüfung seiner Lieferanten keine echte Antwort.

Was echtes kundeneigenes Schlüsselmanagement 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 Herstellers über den Schlüssel theoretisch statt praktisch.

Bring Your Own Key versus Anbieter-verwalteter Schlüssel

Im Anbieter-verwalteten Modell generiert und speichert die Plattform den Verschlüsselungsschlüssel als Teil ihrer Infrastruktur – der Hersteller sieht den Schlüssel oft nie. Im kundeneigenen Modell kontrolliert der Hersteller die Schlüsselgenerierung und -speicherung, meist über ein Hardware Security Module, das er administriert oder zu dem er exklusiven Zugang hat. Der Unterschied: Der Anbieter kann im ersten Fall technisch immer entschlüsseln, im zweiten Fall nicht – unabhängig von den Werbeaussagen zur Verschlüsselungsstärke.

Warum Hardware Security Module wichtiger sind als der Name vermuten lässt

Ein Hardware Security Module ist ein dediziertes physisches Gerät, das Kryptoschlüssel so generiert, speichert und verwaltet, dass eine Extraktion selbst bei administrativem Zugriff auf das System verhindert wird. Die Integration des Schlüsselmanagements mit einem HSM – statt Schlüssel in der Software neben der Anwendung zu speichern – macht den Schlüsselbesitz zu einer physischen Einschränkung statt zu einer Konfigurationseinstellung. Ein korrekt integriertes HSM schließt eine stille Umkehrung technisch aus – nicht nur durch Richtlinien.

Warum Rotation und Cipher-Kontrolle über echten Besitz entscheiden

Den Schlüssel einmal zu besitzen, ist nicht dasselbe wie ihn dauerhaft zu kontrollieren. Zwei operative Details unterscheiden echten Schlüsselbesitz von einer Behauptung, die auf dem Datenblatt gut aussieht, aber in der Praxis versagt.

On-Demand-Schlüsselrotation

Vermutet ein Hersteller, dass ein Schlüssel kompromittiert wurde – etwa durch gestohlene Zugangsdaten, einen ausscheidenden Mitarbeiter oder einen vermuteten Vorfall –, ist die sofortige Rotation des Schlüssels ohne Warten auf den Anbieter entscheidend für die tatsächliche Kontrolle.

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 weitere Form der Kontrolle. Auch sie sollte der Hersteller nach eigenem Zeitplan ausüben können – nicht nach dem des Anbieters.

Schlüsselverwaltung in die Anbieterauswahl integrieren

Für Technik- oder IT-Teams, die einen Anbieter bewerten, ist die praktische Änderung einfach zu beschreiben und wird unter Zeitdruck dennoch oft übersehen: Fragen Sie, wer den Schlüssel generiert, wo er gespeichert wird, ob ein HSM im Einsatz ist und wer ihn wann rotieren kann. Ein Anbieter, der alle vier Fragen klar beantwortet und dem Hersteller die Kontrolle über jeden Schritt gibt, hat ein belastbares Schlüsselverwaltungsmodell. Ein Anbieter, der nur Algorithmus und Schlüssellänge nennt, sagt nichts darüber aus, wer die Konstruktionsdaten nach der Verschlüsselung tatsächlich kontrolliert.

Wie eine Data Control Plane Schlüsselbesitz architektonisch garantiert

Kundeneigenes Schlüsselmanagement hält nur dann, was es verspricht, wenn es in die Architektur der Plattform integriert ist – nicht als Zusatzfunktion, 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, Konstruktionsdateien zu entschlüsseln – über alle Kanäle hinweg, in denen Daten bewegt werden, einschließlich E-Mail, Filesharing, APIs und KI-Agents.

Die Kiteworks Data Control Plane integriert kundeneigene Verschlüsselungsschlüssel über ein Hardware Security Module und unterstützt gängige HSM-Anbieter, sodass Schlüsselgenerierung und -speicherung außerhalb der Reichweite von Kiteworks erfolgen. Hersteller behalten die Möglichkeit, Schlüssel nach Bedarf zu rotieren, zu steuern, welche Cipher und TLS-Versionen aktiviert sind, und auf einer Single-Tenant-Architektur zu arbeiten, in der die Schlüsselverwaltung nicht mit anderen Kundenumgebungen geteilt wird. Darauf aufbauend steuern datenbewusste zero-trust-Kontrollen jede Übertragung, Freigabe und jeden Zugriff über alle Kanäle, und jede Aktion wird in einem fälschungssicheren, ungedrosselten Audit-Log erfasst, der direkt in SIEM-Tools einfließt. So wird die Schlüsselverwaltungszusage durch überprüfbare Protokolle statt durch eine Zeile im Datenblatt belegt.

Hersteller, die das Schlüsselverwaltungsmodell ihres aktuellen Anbieters an diesem Standard messen möchten, können eine individuelle Demo anfordern, um zu sehen, wie die Integration eines kundengesteuerten HSM auf ihre eigenen Konstruktionsdaten und Anforderungen in der Lieferkette angewendet wird.