Elektronische Schlüssel und Zertifikate

Lebenszyklusphasen: In jedem Schritt sind Security-Anforderungen zu beachten, die mit technischen und ­organisatorischen Mitteln zu erfüllen sind.

© Phoenix Contact

Wie bereits erläutert, umfasst OPC UA in aktuellen Versionen die grundlegenden Mechanismen zur sicheren Nutzung der Architektur. Die sichere Einbindung von OPC UA in ein lokales Netzwerk ist im Diskussionspapier ‚Sichere Implementierung von OPC UA für Betreiber, Integratoren und Hersteller‘ der Plattform Industrie 4.0 betrachtet worden. Dabei wurden alle Aspekte des Lebenszyklus einer Komponente von der Inbesitznahme beim Integrator bis zur Außerbetriebnahme untersucht. In der Analyse kristallisierte sich heraus, dass die größten Schwierigkeiten in der Verwaltung von elektronischen Schlüsseln und Zertifikaten liegen. Insbesondere betrifft dies die Unterstützung der Inbetriebnahme durch ein Herstellerzertifikat als Echtheits-Nachweis, die Erstinstallation von elektronischen Schlüsseln und Zertifikaten sowie die Verwaltung mehrerer Zertifikate für verschiedene Anwendungen.

Für den Echtheits-Nachweis ist beispielsweise als Reaktion auf die oben genannte Analyse eine herstellerübergreifende Standardisierung durch die OPC Foundation gerade erst in Arbeit. Ebenso werden die Mechanismen zum Verwalten und Diagnostizieren der Zuordnung von unterschiedlichen Zertifikaten zu den möglicherweise gleichzeitig vorhandenen Kommunikations-Endpunkten eines Gerätes weiter ausgearbeitet. Mehrere Kommunikations-Endpunkte sind notwendig, damit ein und dasselbe Gerät mit verschiedenen Domänen kommunizieren kann, die unter unterschiedlichen Sicherheitsaspekten verwaltet werden. Als Beispiel sei hier genannt, dass ein Gerät sowohl mit der IT eines Betreibers, der mit der Maschine produziert, als auch mit der IT eines Wartungsdienstleisters kommunizieren muss, welcher den Verschleiß überwacht (Condition Monitoring), um rechtzeitig Ersatzteile zu versenden. Sowohl Betreiber als auch Wartungsdienstleister können verschiedene rechtliche Einheiten sein und deshalb unabhängig voneinander jeweils ihre eigenen Zertifikate zur Absicherung der Kommunikation erzeugen und auch verwalten wollen. Last but not least ist in bestehenden Anwendungen bislang häufig nicht der letzte Stand der Spezifikationen implementiert, sodass die aktuellen Security-Mechanismen in der Praxis noch nicht vollständig einsetzbar sind.

Beispiel einer ­automatischen Zertifikatsversorgung per Certificate Management: eine wesentliche Maßnahme, ohne die ein skalierbarer Einsatz kaum ­realisierbar ist.

© Phoenix Contact

Seit dem Start des OPC-UA-Standards dienen Zertifikate der Authentisierung von OPC-UA-Applikationen. In der Automatisierung wird der Umgang mit elektronischen Schlüsseln und Zertifikaten allerdings als Herausforderung empfunden. Während Zertifikate in der traditionellen IT inzwischen seit mehreren Jahrzehnten genutzt werden, ist die Kenntnis ihrer Handhabung in der Automatisierungstechnik noch nicht weit verbreitet. Dies, weil zunächst keine weite Vernetzung bestand und zudem viele Feldgeräte erst jetzt leistungsfähig genug werden, um die mit Zertifikaten verbundenen Rechenaufwände zu bewältigen. Teil 12 des OPC-UA-Standards beschreibt einen herstellerunabhängigen Weg, wie OPC-UA-Anwendungen weitgehend automatisch mit Zertifikaten beliefert werden können, damit sich der Handhabungsaufwand reduziert und an vielen Stellen Kenntnisse über Zertifikate weitgehend überflüssig macht. Bei diesem als ‚Certificate Management‘ bezeichneten Vorgehen erfordert lediglich das Aufsetzen der Vertrauensbeziehung zwischen dem Zertifikatsaussteller und der Applikation etwas manuelle Arbeit.

Darüber hinaus stellt Teil 12 einen Ansatz für Industriegeräte dar, die OPC-UA-Technologie enthalten. Besonders interessant ist, dass sich die Versorgung mit Zertifikaten nicht nur für das OPC-UA-Protokoll verwenden lässt, sondern ebenfalls für andere Protokolle und Dienste, die ein Gerät oder System bereitstellt. Der in ein Gerät integrierte Webserver lässt sich auf diese Weise ebenso standardisiert und automatisch in regelmäßigen Abständen mit einem neuen Zertifikat beliefern. 

Für OPC-UA-Applikationen definiert Teil 12 mit dem Certificate Management nicht zuletzt, wie sich die Einstellungen zur Vertrauenswürdigkeit von Gegenstellen über sogenannte ‚Trust Lists‘ automatisch pflegen lassen. Zu diesem Zweck werden die jeweiligen Zertifikate und Sperrlisten selbstständig verteilt. Das Certificate Management übernimmt in der Regel ein Global Discovery Server (GDS), dessen Standort nach Bedarf gewählt werden kann. Die Beschreibung des GDS im Standard erlaubt eine kaskadenartige Implementierung oder die Anbindung des Certificate Managements an eine im Unternehmen vorhandene Zertifikatsverwaltung (Certificate Authority). 

Client-Server- oder Publish-Subscribe-Modell?

Unternehmensübergreifende Kommunikation am Modell Betreiber/Dienstleister: Der Kommunikationsweg führt durch mehrere Verantwortungsbereiche und muss mit allen Beteiligten abgestimmt sein.

© Phoenix Contact

Im Rahmen des Zukunftsprojekts Industrie 4.0 wird die unternehmensübergreifende Vernetzung immer wichtiger. Als Architektur erweist sich OPC UA hier als Schlüsselelement. Im ebenfalls von der Plattform Industrie 4.0 initiierten Diskussionspapier ‚Sichere unternehmensübergreifende Kommunikation mit OPC UA‘ ist daher eine entsprechende Nutzung des Standards mit dem Client-Server-Modell betrachtet worden. Für den exemplarischen Fall des Condition Monitoring und einer möglichen Parametrierung wurde das Zusammenwirken eines Betreibers und eines Dienstleisters analysiert.

Als besondere Herausforderung zeigen sich in diesem Zusammenhang die vernünftigerweise anzunehmenden Schutzziele. Zur Datenübertragung über das Internet muss die Verbindung Vertraulichkeit und Integrität sicherstellen. Ist die Kommunikation zwischen der Maschine und dem Dienstleister jedoch komplett von Ende zu Ende verschlüsselt, hat der Betreiber keine Möglichkeit zur Überwachung der Verbindung sowie das Erkennen von unerlaubtem Datenverkehr. Abhilfe könnte das Modell des ‚Aggregating Servers‘ schaffen, über den sämtliche Zugriffe abgewickelt würden. Wenn bei einem Betreiber mehrere Dienstleister auf Maschinen unterschiedlicher Anbieter zugreifen sollen, stellt sich hier allerdings zwangsläufig die Frage der Skalierung. Insgesamt erscheint das Client-Server-Modell für diese Anwendung also nicht optimal. Die kurz vor der Fertigstellung stehende DIN SPEC 92222 (Referenzmodell für die industrielle Cloud Federation) konzentriert sich daher auf das Publish-Subscribe-Modell (PubSub) von OPC UA, das mit Teil 14 der Spezifikation 2018 freigegeben wurde. In der Plattform Industrie 4.0 werden die Vor- und Nachteile der Modelle – Client-Server einerseits, Publish-Subscribe andererseits – sowie weitere Alternativen bereits betrachtet und diskutiert, um der Herausforderung der Frage nach der Skalierbarkeit zu begegnen.

Zusammenfassend lässt sich festhalten: Die Anforderungen an die Security von Kommunikationsbeziehungen müssen sich am Schutzbedarf orientieren. OPC UA bietet verfügbare Mechanismen, für die es Empfehlungen zur Implementierung und Weiterentwicklung gibt, um die Umsetzung in der Breite zu unterstützen. Dabei liegt der Fokus auf der lokalen Anwendung. Der Einsatz von OPC UA in der unternehmensübergreifenden Datenübertragung befindet sich noch in der Entwicklung und wird im Kontext von Industrie 4.0 vorangetrieben.

Autoren:
Torsten Förder ist Senior Specialist Security bei Phoenix Contact Software in Lemgo;
Dr.-Ing. Lutz Jänicke ist Product & Solution Security Officer bei Phoenix Contact in Blomberg.