Einleitung: Eine Fehlweitergabe offenbart kein Mitarbeiter-, sondern ein Berechtigungsproblem
Eine Werkstatt für additive Fertigung erhielt eine Kundenbeschwerde: Eine Modelldatei, die ausschließlich an den Verantwortlichen des betreffenden Projekts hätte gesendet werden dürfen, war von einem Mitarbeiter, der inzwischen die Position gewechselt hatte, über sein privates E-Mail-Konto an externe Branchenkollegen weitergeleitet worden. Bei der Nachanalyse stellte das Unternehmen fest, dass drei Umstände gleichzeitig vorlagen: Die Zugriffsrechte des Mitarbeiters auf das alte Projekt waren nach seinem Positionswechsel nie entzogen worden; für den Dateidownload war keinerlei Genehmigung erforderlich; und das System enthielt überhaupt keine Aufzeichnungen darüber, wer welche Datei zu welchem Zeitpunkt heruntergeladen hatte. Das Zusammenwirken dieser drei Faktoren machte aus einer eigentlich abfangbaren Handlung einen Datenabfluss, der nicht mehr nachweisbar belegt werden konnte.
Solche Vorfälle sind in 3D-Druckunternehmen nicht selten. Die Branche richtet ihre Aufmerksamkeit häufig auf Verschlüsselung, Vertraulichkeitsvereinbarungen und Wasserzeichen. Tatsächlich bestimmt jedoch das Kontoberechtigungssystem die Datengrenzen: Wer darf was sehen, wer hat den Zugriff genehmigt und welche Spuren hinterlässt der Zugriff? Diese Regeln in einen ausführbaren technischen Ansatz zu überführen, ist wirksamer als zehn weitere Vertraulichkeitsvereinbarungen zu unterzeichnen.
I. Warum die Berechtigungsverwaltung in 3D-Druckunternehmen schwieriger ist als in gewöhnlichen Fertigungsszenarien
Die Datenformen in 3D-Druckunternehmen unterscheiden sich von denen in Unternehmen der Serienfertigung, weshalb die Berechtigungskonzeption zusätzliche Komplexität aufweist. Erstens ist die Datengranularität hoch: Ein Bauteil kann gleichzeitig aus sechs Arten von Assets bestehen – dem ursprünglichen 3D-Modell, der reparierten Netzdatei, der Slicing-Datei, dem Prozessparameterpaket, dem Prüfbericht und Fotos des physischen Objekts. Ihre Schutzstufen sind nicht identisch. Kunden gestatten häufig nur die Nutzung eines Modells für die Produktion, nicht jedoch dessen erneute Bearbeitung oder Weiterleitung an Dritte.
Zweitens gibt es viele Beteiligte. Neben den internen Rollen für Konstruktion, Prozesstechnik, Druck, Nachbearbeitung, Qualitätsprüfung und Auslieferung gibt es externe Auftragsverarbeiter, Remote-Wartungspersonal von Geräteherstellern, Prüfer auf Kundenseite und sogar temporär an Projekten beteiligte externe Prüforganisationen. Der erforderliche Datenumfang, die Gültigkeitsdauer und die zulässigen Aktionen unterscheiden sich für jede externe Rolle. Dies mit einem einzigen internen Kontosystem abzudecken, führt zwangsläufig zum Kontrollverlust.
Drittens sind die Systeme verteilt. Modelldateien liegen auf Dateiservern oder in Objektspeichern, Slicing-Parameter in lokaler Software des Geräteherstellers, Prüfdaten auf separaten Arbeitsstationen von Messmitteln oder CT-Geräten und Bestellinformationen im Geschäftssystem. Berechtigungen werden in vier Systemen jeweils separat verwaltet. Bei einem Positionswechsel müssen sie an vier Stellen geändert werden; wird nur eine davon übersehen, bleibt eine Sicherheitslücke bestehen.
II. Rollendefinition: Zuerst die Organisationsstruktur in Datenobjekte übersetzen
Der häufigste Fehler bei Berechtigungssystemen besteht darin, das Organigramm direkt zu übernehmen. Eine Stelle ist ein organisatorisches Konzept, eine Berechtigung ein Datenkonzept; zwischen beiden ist eine Übersetzungsebene erforderlich. Ein praktikabler Ansatz besteht darin, zuerst ein Verzeichnis der Datenobjekte zu erstellen, dann Rollen zu definieren und schließlich Stellen diesen Rollen zuzuordnen.
Datenobjekte sollten nach Projekten und nicht nach Abteilungen organisiert werden. Ein Projektverzeichnis enthält die vier Teilbereiche Modell, Prozess, Prüfung und Auslieferung. In jedem Teilbereich werden wiederum vier Aktionstypen unterschieden: nur lesen, bearbeiten, herunterladen und extern weitergeben. So definierte Berechtigungen enthalten von Natur aus Projektgrenzen und verhindern, dass Mitarbeiter, die an Projekt A arbeiten, nebenbei Dateien aus Projekt B sehen.
Die Anzahl der Rollen sollte begrenzt bleiben. Als Erfahrungswert sollten interne Rollen auf sechs bis acht beschränkt werden: Projektverantwortlicher, Konstruktionsingenieur, Prozessingenieur, Produktionsmitarbeiter, Qualitätsprüfer, Auslieferung, Systemadministrator und Auditor. Zu viele Rollen führen dazu, dass niemand mehr weiß, was jede Rolle darf, und das System letztlich dazu degeneriert, dass jeder Administratorrechte beantragt. Der Auditor muss eine unabhängige Rolle sein und darf keine Berechtigung zur Datenänderung besitzen, da andernfalls Protokolle selbst gelöscht werden könnten.
III. Prinzip der minimalen Rechte: Standardmäßig verweigern, bedarfsgerecht und temporär freigeben
Minimale Rechte sind kein Schlagwort; sie benötigen drei überprüfbare Regeln. Die erste lautet standardmäßige Verweigerung: Ein neu erstelltes Konto kann vor einer expliziten Freigabe kein Projekt sehen. Viele Systeme sind standardmäßig auf „Leserechte für alle“ eingestellt; im 3D-Druckszenario bedeutet dies, Kundenmodelle faktisch halböffentlich zu machen.
Die zweite Regel lautet, dass Berechtigungen zeitlich befristet sein müssen. Berechtigungen für reguläre Stellen werden vierteljährlich überprüft, projektbezogene Rechte werden an das Enddatum des Projekts gebunden, und temporäre externe Zugriffe werden taggenau festgelegt. Nach Ablauf zieht das System die Berechtigung automatisch zurück und benachrichtigt den Projektverantwortlichen zur Bestätigung, statt darauf zu warten, dass jemand daran denkt, den Zugriff zu sperren. Die dritte Regel ist die Trennung von Aktionen: Download und externe Weitergabe sind zwei unterschiedliche Berechtigungen. Eine Datei für die Produktion herunterladen zu dürfen, bedeutet nicht, sie extern versenden zu dürfen; die externe Weitergabe muss gesondert genehmigt und protokolliert werden.
Für hochsensible Daten empfiehlt sich eine Vier-Augen-Freigabe. Bei drei Arten von Vorgängen – Export ursprünglicher Kundenmodelle, vollständiger Export von Prozessparameterpaketen und Massendownloads oberhalb eines Schwellenwerts – ist vor der Ausführung eine Prüfung durch eine zweite Person erforderlich. Der Wert der Vier-Augen-Regel liegt nicht darin, Insider zu verhindern, sondern die Wahrscheinlichkeit versehentlicher Fehlbedienungen durch Einzelpersonen zu senken und nachträglich einen zweiten Zeugen zu haben.
IV. Kontolebenszyklus: Dreistufige Kontrolle bei Eintritt, Positionswechsel und Austritt
Personelle Veränderungen sind ein besonders häufiger Auslöser für den Verlust der Berechtigungskontrolle. Beim Eintritt müssen Berechtigungsanträge formal dokumentiert werden: Der Projektverantwortliche beantragt die benötigten Datenbereiche und Aktionen; nach Genehmigung konfiguriert der Administrator die Rechte, und das Konfigurationsergebnis wird als Nachweis in den Antrag zurückgeschrieben. Mündliche Berechtigungsanträge sind zu untersagen.
Der Positionswechsel ist die wichtigste und zugleich am leichtesten übersehene Phase. Die richtige Reihenfolge lautet: Zuerst die Rechte der alten Position entziehen, danach die Rechte der neuen Position vergeben – nicht beides addieren. In der Praxis ist es sicherer, am Tag des Positionswechsels sämtliche Projektberechtigungen des Kontos einzufrieren und den Verantwortlichen der neuen Position einen neuen Berechtigungsantrag stellen zu lassen. Nicht beantragte Bereiche dürfen grundsätzlich nicht mehr sichtbar sein. Muss der Mitarbeiter weiterhin an historischen Projekten mitwirken, ist dies separat als Projektmitglied zu beantragen und mit einem Enddatum zu versehen.
Am Austrittstag müssen drei Dinge abgeschlossen werden: Das Konto wird deaktiviert statt gelöscht, damit die Verknüpfung mit Protokollen erhalten bleibt; die Projektmitgliedschaften werden gesammelt entfernt; und sämtliche Berechtigungen zur externen Weitergabe sowie Freigabelinks werden unwirksam. Das Löschen eines Kontos zerstört die Zuordnung des Ausführenden in Protokollen und macht eine spätere Nachverfolgung unmöglich – ein Fehler, den viele Unternehmen bereits gemacht haben.
V. Protokollierung von Vorgängen: Protokolle müssen fünf Fragen beantworten können
Protokollierung dient nicht dem bloßen Speichern von Logs, sondern der nachträglichen Rekonstruktion von Tatsachen. Ein qualifiziertes Zugriffsprotokoll muss mindestens beantworten können: Wer hat wann an welchem Datenobjekt welche Aktion ausgeführt und mit welchem Ergebnis? Neben Benutzerkennung, Zeitstempel, Objektkennung, Aktionstyp und Ergebnisstatus sollten auch das verwendete Endgerät und der Netzwerkstandort erfasst werden, um Zugriffe vom Arbeitsplatz in der Werkstatt von ungewöhnlichen Zugriffen aus der Ferne unterscheiden zu können.
Die Protokolle selbst müssen manipulationssicher sein. Nach dem Schreiben dürfen sie weder geändert noch gelöscht werden; auch Administratorkonten dürfen keine Löschberechtigung besitzen. Die Aufbewahrungsdauer darf nicht kürzer sein als die vertraglich mit dem Kunden vereinbarte Verjährungsfrist für Streitfälle; üblicherweise wird eine Speicherung von mindestens zwölf Monaten empfohlen. Auch die Protokolldateien selbst benötigen eine Zugriffskontrolle: Wer Protokolle eingesehen hat, muss ebenfalls erfasst werden.
Protokolle ohne Prüfung sind gleichbedeutend mit keinen Protokollen. Es empfiehlt sich, drei Arten automatischer Warnungen einzurichten: Massendownloads außerhalb der Arbeitszeit, ein Downloadvolumen eines einzelnen Kontos pro Tag von mehr als dem Dreifachen des historischen Basiswerts sowie Zugriffe externer Konten auf nicht autorisierte Projektbereiche. Warnungen müssen nicht sofort als Verstoß eingestuft werden, aber sie müssen innerhalb eines Arbeitstags bearbeitet und mit einer dokumentierten Maßnahme versehen werden.
VI. Grenzen für externe Konten und Freigabelinks
Kundenprüfer, externe Auftragsverarbeiter und Wartungspersonal von Geräteherstellern sollten externe Konten in einem separaten Namensraum verwenden und nicht mit dem internen Kontosystem vermischt werden. Externe Konten dürfen standardmäßig nur auf ausdrücklich freigegebene Objekte zugreifen, weder die Struktur von Projektverzeichnissen sehen noch über Links andere Dateipfade erraten können. Freigabelinks sollten nicht aufzählbare zufällige Kennungen verwenden und an eine Gültigkeitsdauer sowie eine maximale Anzahl von Zugriffen gebunden sein.
Die Remote-Wartung durch Gerätehersteller ist der Zugangskanal, der am häufigsten unbeachtet bleibt. Wartungskonten besitzen in der Regel weitreichende Rechte im Gerätesteuerungssystem. Werden sie mit dem Dateisystem des Produktionsnetzes verbunden, eröffnet dies Externen einen Nebenweg, der das Berechtigungssystem umgeht. Der richtige Ansatz besteht darin, die Wartungsverbindung über einen unabhängigen Netzwerkkanal zu führen und auch Dateiexportvorgänge während der Wartung in Genehmigung und Protokollierung einzubeziehen.
VII. Checkliste für die Umsetzung
Unternehmen können anhand der folgenden Punkte eine Selbstprüfung durchführen: Ist bei neu angelegten Konten standardmäßig kein Projekt sichtbar? Lassen sich innerhalb von fünf Minuten sämtliche aktuell bestehenden Berechtigungen eines Mitarbeiters auflisten? Sind alle Berechtigungen befristet? Gibt es im Prozess bei Positionswechseln ein überlappendes Verhalten nach dem Muster „erst gewähren, dann entziehen“? Sind Download und externe Weitergabe zwei unabhängige Berechtigungen? Enthalten Protokolle Angaben zum Quellendgerät und sind sie nicht löschbar? Sind externe von internen Konten getrennt? Sind Freigabelinks an eine Gültigkeitsdauer und eine maximale Anzahl von Zugriffen gebunden? Werden Links zur externen Weitergabe am Austrittstag unwirksam? Wurde im vergangenen Quartal tatsächlich eine Berechtigungsüberprüfung durchgeführt? Wenn drei oder mehr dieser zehn Fragen nicht beantwortet werden können, muss das Berechtigungssystem neu aufgebaut werden.
Fazit
Die Grenzen der Datenassets eines 3D-Druckunternehmens werden letztlich durch das Kontoberechtigungssystem definiert, nicht durch die Stärke der Verschlüsselung oder Vertraulichkeitsvereinbarungen. Wenn Stellen in Rollen übersetzt, Rollen an befristete Datenobjekte gebunden, die Standardrichtlinie auf Verweigerung gesetzt und sämtliche Zugriffe als prüfbare Aufzeichnungen festgehalten werden, lassen sich die meisten Datenabflussereignisse vor ihrem Eintritt abfangen oder danach eindeutig nachweisen. Berechtigungsverwaltung ist keine einmalige Veröffentlichung einer Regelung, sondern ein technischer Mechanismus, der vierteljährlich überprüft und mit Veränderungen in Projekten fortlaufend angepasst werden muss.
Reichen Sie ein Modell, eine Zeichnung, ein Bild oder schriftliche Notizen ein. Ingenieure prüfen Material, Verfahren, Endbearbeitung und Lieferung basierend auf der tatsächlichen Anwendung.