Die Governance von technischen Daten darf nicht beim Filesharing-Login enden

Die meisten Hersteller verfügen nicht über eine einzige Data-Governance-Richtlinie. Sie haben mehrere: eine für das PLM-System, eine andere für E-Mails, eine weitere für Filesharing und oft gar keine klare Richtlinie für die neuesten Kanäle wie KI-gestützte Engineering-Tools oder Lieferantenintegrationen. Jede dieser Richtlinien wurde von einem anderen Team, zu einer anderen Zeit und auf Basis unterschiedlicher Anforderungen entwickelt. Für sich genommen erscheint jede Richtlinie sinnvoll. Zusammengenommen entstehen jedoch Lücken, die niemand absichtlich geschaffen hat und die kaum jemand erkennt.

Diese Lücken bleiben nicht lange theoretisch. Eine als proprietär klassifizierte Konstruktionsdatei im PLM-System kann als E-Mail-Anhang ungehindert weitergegeben werden, weil die Richtlinie des PLM-Systems die Datei nicht verlässt. Ein Datensatz, der in einem System für die externe Weitergabe gesperrt ist, kann über eine Lieferantenintegration das Unternehmen verlassen, die niemand abgedeckt hat. Dieser Artikel zeigt, warum die getrennte Steuerung einzelner Kanäle bei Herstellern zwangsläufig zu solchen Lücken führt – und was tatsächlich nötig ist, um sie zu schließen.

Executive Summary

Data Governance, die bei Herstellern kanalweise aufgebaut wurde, führt zwangsläufig zu inkonsistentem Schutz, weil die Tools für jeden Kanal unabhängig voneinander entwickelt und konfiguriert wurden – oft von unterschiedlichen Teams, die jeweils akute Probleme gelöst haben. Das Ergebnis ist nicht eine Reihe akzeptabler Einzelrisiken, sondern ein kombiniertes Risiko, das dem schwächsten Kanal entspricht. Denn Konstruktionsdaten bewegen sich regelmäßig zwischen den Kanälen und eine Richtlinie, die an der Kanalgrenze endet, bietet keinen Schutz mehr, sobald die Daten diese Grenze überschreiten. Für Engineering- und IT-Verantwortliche bedeutet das: Einzelne Kanäle zu auditieren, deckt dieses Risiko nicht auf. Entscheidend ist, was mit einer bestimmten Konstruktionsdatei passiert, wenn sie von einem Kanal in den nächsten wechselt.

wichtige Erkenntnisse

1. Fragmentierte Governance bedeutet, dass dieselbe Konstruktionsdatei in einem Kanal geschützt und in einem anderen ungeschützt sein kann. Eine Klassifizierung oder Zugriffsregel in einem System wird beim Wechsel der Daten in ein anderes System selten übernommen.
2. Anhänge sind der häufigste Punkt, an dem eine Richtlinie stillschweigend nicht mehr gilt. Eine Datei, die im PLM-System streng geregelt ist, kann als E-Mail-Anhang verschickt werden – ohne dass die Beschränkungen des Systems erhalten bleiben.
3. Jeder zusätzliche Kanal, auch Lieferantenintegrationen, ist eine weitere Stelle, an der sich eine Richtlinienlücke verbergen kann – und eine Lücke reicht aus.
4. Klassifizierung muss eine Eigenschaft der Daten selbst sein, nicht des Systems, in dem sie sich gerade befinden. Ein Tag schützt Konstruktionsdaten nur dann konsistent, wenn er beim Wechsel zwischen Kanälen – auch zu Lieferanten – erhalten bleibt.
5. Eine zentrale Policy-Engine, die alle Kanäle umfasst, schließt die Lücke, die kanalbezogene Tools nicht schließen können. Die Durchsetzung muss unabhängig vom jeweiligen Kanal nach denselben Kriterien bewertet werden.

Warum kanalbezogene Governance der Standard war – und warum sie für Hersteller nicht funktioniert

Die meisten Hersteller sind durch eine Reihe einzeln sinnvoller Entscheidungen zu fragmentierter Governance gelangt, nicht durch einen einzigen Fehler. Ein PLM-System wurde ausgewählt und abgesichert, dann wurde E-Mail separat eingeführt und gesichert – jedes Projekt mit eigenem Budget, Verantwortlichen und Zieldefinition.

Jedes Tool löst nur seinen eigenen Kanal, nicht die gesamte Datenreise

Die Zugriffskontrollen eines PLM-Systems regeln, wer innerhalb dieses Systems eine Datei öffnen, herunterladen oder teilen darf. Was mit der Datei passiert, wenn sie als E-Mail-Anhang verschickt, in ein anderes System kopiert oder über eine Lieferantenintegration abgerufen wird, entzieht sich seiner Kontrolle. Jedes Tool wurde entwickelt, um seinen eigenen Kanal gut zu steuern – keines wurde dafür gebaut, die Daten nach dem Verlassen des Kanals weiter zu begleiten.

Richtlinien werden nachträglich selten kanalübergreifend abgestimmt

Hat jeder Kanal erst einmal sein eigenes Governance-Tool und eigene Administratoren, wird das Abgleichen der Richtlinien zu einem Projekt, das niemand verantwortet. Es erfordert, Regelwerke in unterschiedlichen Sprachen, durch verschiedene Systeme und mit überlappenden, aber nicht identischen Kategorien von Konstruktionsdaten zu vergleichen. In der Praxis findet diese Abstimmung selten umfassend statt.

Wo die Lücke für Hersteller tatsächlich sichtbar wird

Das theoretische Risiko fragmentierter Governance wird an bestimmten, vorhersehbaren Punkten konkret – nämlich immer dann, wenn Konstruktionsdaten eine Kanalgrenze überschreiten.

Das Anhang-Problem

Eine Datei im streng geregelten PLM-System ist aus Sicht der meisten E-Mail-Systeme einfach eine Datei, die ein Anwender anhängt. Die Zugriffsregeln, Aufbewahrungsfristen und Freigabebeschränkungen des Systems werden beim Versand per E-Mail nicht übernommen. Nach dem Versand gilt nur noch das – meist weniger strenge – Regelwerk des E-Mail-Systems.

Das Integrations- und Lieferantenportal-Problem

Hersteller vernetzen Systeme ständig – über Lieferantenintegrationen und zunehmend auch über KI-Engineering-Tools, die Konstruktionsdaten im Auftrag des Ingenieurs lesen und zusammenfassen. Jeder dieser Kanäle ist ein potenzieller Weg für proprietäre Daten, gesteuert durch eigene, oft minimale Zugriffskonfigurationen statt durch die eigentliche Datenrichtlinie des Herstellers.

Warum Klassifizierung mit den Daten reisen muss

Um diese Lücken zu schließen, braucht es einen anderen Ansatz: Nicht jeder Kanal soll seine eigene Version einer Richtlinie durchsetzen, sondern die Richtlinie muss unabhängig vom aktuellen Kanal immer gleich bewertet werden.

Tags und Klassifizierung als portable Eigenschaften

Wird eine Datei beim Eintritt in ein System als proprietär getaggt, sollte diese Klassifizierung sie in alle nachfolgenden Kanäle begleiten – auch zu Lieferanten –, damit dieselbe Einschränkung konsistent angewendet werden kann.

Durchsetzung muss den Übergang abdecken, nicht nur die einzelnen Seiten

Der riskanteste Moment für jede Konstruktionsdatei ist der Übergang zwischen Kanälen, nicht die Zeit im ruhenden Zustand in einem System. Ein Governance-Ansatz, der zum Beispiel beim Teilen mit Lieferanten keine Aussage trifft, hat die Lücke nicht geschlossen.

Auditierung auf Fragmentierung statt kanalweise Auditierung

Für Engineering- oder IT-Abteilungen bedeutet der praktische Wandel, nicht mehr zu fragen „Ist unser PLM-System sicher?“ und „Ist unser E-Mail-System sicher?“ als getrennte Fragen, sondern zu prüfen, was mit einer bestimmten, proprietären Konstruktionsdatei passiert, wenn sie von einem System ins andere und zu Lieferanten wechselt.

Wie eine Data Control Plane die Lücke zwischen Kanälen schließt

Um Fragmentierung zu beseitigen, müssen Hersteller nicht jedes kanalbezogene Tool ersetzen. Es genügt, eine Governance-Schicht einzuführen, die über allen Kanälen liegt und dieselbe Richtlinie für dieselben Daten unabhängig vom aktuellen Kanal bewertet.

Die Kiteworks Data Control Plane setzt eine einheitliche, datenbasierte zero-trust-Policy über alle Kanäle hinweg durch, über die vertrauliche Daten laufen – einschließlich E-Mail, Filesharing, APIs und KI-Agents. Klassifizierungen, die beim Eintritt der Daten ins System automatisch vergeben werden, begleiten die Daten, sodass dieselbe Einschränkung, die eine Konstruktionsdatei im PLM-System schützt, auch dann greift, wenn sie jemand an eine E-Mail anhängt oder mit einem Lieferanten teilt. Jede Durchsetzungsentscheidung, kanalübergreifend, wird in einem einzigen fälschungssicheren, uneingeschränkten Audit-Log erfasst, der direkt in SIEM-Tools einfließt.

Hersteller, die wissen möchten, wo ihre eigenen kanalübergreifenden Lücken tatsächlich liegen, können eine individuelle Demo vereinbaren, um zu sehen, wie eine einheitliche Policy über alle Kanäle im Vergleich zum aktuellen, kanalbezogenen Ansatz abschneidet.