Industrial Security in a nutshell: Kommt mit OPC UA Zero Trust in die Fabrik?

Wie mit dem OPC UA Standard 10000-21 mehr Automatisierung in vertrauensvolle Automatisierungstechnik kommt

Industrielle Automatisierungskomponenten können bis zu ihrem eigentlichen Einsatzort mehrere Stufen durchlaufen. Vom ursprünglichen Komponentenhersteller über einen Integrator, vielleicht noch einen Anlagenbauer bis hin zum eigentlichen Betreiber. Doch wie können die verschiedenen Parteien einem Gerät vertrauen und wie kann sich dieses Gerät im jeweiligen Netzwerk authentifizieren? Die OPC Foundation hat mit dem neuen Standard zum „Device Onboarding“ eine mögliche Lösung vorgeschlagen, die diese Herausforderung lösen soll.

Technisch basiert Device Onboarding auf zwei Komponenten: Digitale Identitäten, wie sie in IEEE 802.1 AR beschrieben sind und Tickets, die parallel ein „Product“ oder ein „Composite“ (eine Integration, eine Maschine oder eine Anlage) beschreiben.

Die Grundidee basiert einerseits darauf, dass eine Komponente ein vom Hersteller ausgestelltes Zertifikat (sog. Birth-Certificate oder IDevID) besitzt, mit dem diese Komponente eindeutig identifizierbar ist. Gleichzeitig sollen Tickets die Verwaltung der Geräte in einem Maschinen- oder Fabriknetz erleichtern. Wie das im Detail funktioniert, wird im folgenden Artikel beschrieben. Der folgende Artikel ist Teil einer Serie, die den Lebenszyklus von Geräteidentitäten im industriellen Umfeld beschreibt.

Digitale Identitäten

Sichere Geräteidentitäten sind die Grundlage für Vertrauen im Lebenszyklus einer Komponente. Das Secure Onboarding von OPC UA basiert auf einem IEEE Standard. Das Konzept hinter IEEE 802.1 AR basiert auf sogenannten DevIDs. Diese stellen digitale Identitäten und Zertifikate nach dem Standard X.509v3 dar, die eine Komponente eindeutig identifizieren. Es wird zwischen IDevIDs und LDevIDs unterschieden. IDevIDs oder auch Initial Device Identifiers geben einer Komponente eine initiale Identität, anhand derer sie über ihren gesamten Lebenszyklus identifiziert werden kann. Wird für eine bestimmte Anwendung wie z.B. einen OPC UA Server ein Zertifikat benötigt, so definiert die Spezifikation diese als LDevIDs (Locally Significant Device Identifiers). Anhand der LDevIDs kann ein Betreiber oder Integrator jederzeit die Authentizität einer Komponente überprüfen.

Tickets

Tickets liefern Metainformationen über einzelne Geräte oder Maschinen. Um die verschiedenen Konstellationen zu beschreiben, werden im Standard DeviceIdentityTickets und CompositeIdentityTickets aufgeführt. Dabei handelt es sich um JSON-codierte Informationen des Geräteherstellers (DeviceIdentityTickets) oder eines Integrators, Distributors oder Maschinen- bzw. Anlagenbauers (CompositeIdentityTickets). Tickets werden von der jeweiligen Instanz signiert und zur Verfügung gestellt. Die Bereitstellung an sich ist nicht spezifiziert, könnte aber per Mail, Webservice oder Blockchain-basierten Verfahren erfolgen. Die Signatur basiert auf einem Zertifikat, das von einer vertrauenswürdigen CA ausgestellt wurde. Die Grundstruktur des Tickets listet verschiedene Informationen auf, die die Komponente oder das Composite eindeutig identifizieren, wie manufacturerName, modelName, modelVersion, serialNumber oder Authorities (CAs), die zur Validierung der ausgestellten Device Identities dienen. Das DeviceIdentityTicket enthält auch eine ProductInstanceUri aus dem SubjectAlternativeName der Device Identity. Die CompositeInstanceUri ist ebenfalls Bestandteil eines Zertifikats.

Workflow

Um eine Komponente oder Maschine in ein Netzwerk zu integrieren, müssen nun sowohl die Geräteidentität als auch das Ticket validiert werden. Eine zentrale Komponente für diese Integration ist ein sogenannter Registrar. Dabei handelt es sich um einen Server im Netzwerk, der verschiedene Aufgaben innerhalb des Registrierungsprozesses übernimmt, wie z.B. die Kommunikation mit Drittsystemen wie einem ERP, die Kommunikation mit Clients und Servern, die Validierung von Identitäten und Tickets oder die Übermittlung von Trustlists.

Die Integration beginnt mit der Validierung des Tickets (Device oder Composite). Dazu wurde das Ticket entweder über ein Drittsystem bezogen oder es wird mit dem physischen Produkt ausgeliefert und über eine Konnektivität der Komponente übertragen. Nun muss sowohl das zur Signatur verwendete Zertifikat als auch die Signatur selbst verifiziert werden.

Nun werden alle Geräteidentitäten der Komponente oder Maschine ausgelesen. Stimmt die in einer Geräteidentität angegebene ProductInstanceUri oder CompositeInstanceUri mit einem zugehörigen Ticket überein, wird über das zugehörige Zertifikat eine sichere Verbindung zum Gerät aufgebaut und dem Gerät ein sogenanntes „DCA Application Instance Certificate“ ausgestellt, das die Autorisierung des Geräts im Netzwerk bescheinigt. Je nachdem, ob es sich bei dem Endgerät um einen Client oder Server handelt, wendet der Registrar ein sogenanntes Push-Management (Server) oder Pull-Management (Client) an.

Fazit

Die OPC Foundation geht in die richtige Richtung und versucht, die bisher überwiegend manuellen Prozesse zu automatisieren und ein Zertifikatsmanagement in der Maschine und Fabrik zu ermöglichen. Als ganzheitlicher Ansatz wird sich das System aber nur durchsetzen, wenn auch andere Anwendungen unterstützt werden. Was ist mit IPSec, Modbus, MQTT, Profinet und Co? Sollen wir um jedes Protokoll und jede Anwendung, die X.509-Zertifikate verwendet, Silos bauen? Es bleibt zu hoffen, dass sich die verschiedenen Verbände untereinander austauschen und einheitliche Standards schaffen.

Sie haben Fragen zu dem beschriebenen Konzept? Dann melden Sie sich gerne bei