Die seit 1996 von der OPC Foundation entwickelten Spezifikationen stellen längst unverzichtbare Schnittstellen für einen herstellerübergreifenden Datenaustausch in der Automatisierung bereit. Deren erste Generation zur Übertragung von Echtzeitdaten, Alarmen und Ereignissen sowie historischen Daten (OPC DA, A/E und HDA) wird heute unter der Bezeichnung OPC Classic zusammengefasst. Sie war und ist an die Microsoft-Windows-Betriebssysteme und an deren Schnittstelle DCOM (Distributed Component Object Model) zum Dienst RPC (Remote Procedure Call) gebunden, denen sie wie später erläutert wird, einige problematische Eigenschaften verdankt. Um neuen Anforderungen nach Service-orientierten Architekturen (SOA), besserer Datenmodellierung und Sicherheit gerecht zu werden, wurde als zweite Generation die OPC Unified Architecture (OPC UA) entwickelt. Neben der Fähigkeit, alle bisherigen Funktionen von OPC Classic abbilden zu können, wurden dabei insbesondere die Plattformunabhängigkeit, die Skalierbarkeit, ein zukunftssicheres eigenes Security-Modell und eine Erweiterbarkeit ohne Beeinträchtigung bestehender Anwendungen als Design-Ziele verfolgt. Von eingebetteten Systemen der Automatisierung bis zu Business Systemen der Unternehmens-IT und darüber hinaus via Internet zu Geschäftspartnern und Cloud-basierten Diensten soll OPC UA unabhängig von den jeweils eingesetzten Betriebssystemen eine sichere, standardisierte industrielle Kommunikation ermöglichen. Es gilt damit heute als wesentlicher Ansatz für eine Kommunikationsschicht im industriellen Internet der Dinge und die Vision Industrie 4.0.
Security-Modell von OPC UA
Die ersten Spezifikationen für OPC UA wurden 2008 veröffentlicht und 2010 als Norm IEC62541 verabschiedet. Während OPC Classic sich auf die in Microsoft Windows und DCOM vorhandenen Sicherheitsmechanismen verließ, wird gleich im zweiten Teil der neuen Norm ein eigenes Security-Modell für OPC UA beschrieben. Es umfasst Konzepte für die Authentifizierung und Autorisierung von Anwendungen und Benutzern, die Integrität und Vertraulichkeit der Kommunikation, Firewall-freundliche Transport-Mechanismen, das Sequencing von Nachrichten gegen Replay-Attacken sowie die Protokollierung von Benutzer- und Systemaktivitäten zu Revisionszwecken.
- Authentifizierung und Autorisierung von Anwendungen: Client- und Server-Anwendungen in OPC UA identifizieren sich über Software- und Applikationsinstanzzertifikate. Damit wird es möglich, verschiedenen Typen von Anwendungen bzw. verschiedenen Installationen dieser Anwendungen unterschiedliche Zugriffsrechte einzuräumen und nur als jeweils gegenseitig vertrauenswürdig betrachtete Anwendungen miteinander kommunizieren zu lassen. Selbst entfernt vergleichbare Restriktionen findet man in OPC-Classic-Installationen nur selten umgesetzt, da entsprechende RPC- und Firewall-Konfigurationen zu aufwändig oder gar nicht möglich waren.
- Authentifizierung und Autorisierung von Benutzern: OPC UA kennt drei Optionen für die Identifizierung des Benutzers einer Anwendung: Benutzernamen mit Passwort, Kerberos-Tokens oder X.509-Zertifikate. Damit werden die gängigen Systeme zur Benutzerverwaltung abgedeckt. Die Zugriffsrechte, etwa für das Browsen des Adressraums oder das Lesen und Schreiben einzelner Werte, können von einer Anwendung auf Basis der Benutzer-Identität feingranular definiert werden. OPC Classic kennt vergleichbare Zugriffsrechte auf Basis der Windows Benutzer-Identität als wesentliches Instrument der Autorisierung. Allerdings machen die meisten Classic-Anwendungen nur sehr grobgranular Gebrauch davon, indem sie einem Benutzer jeweils nur Lese- oder Lese- und Schreibrecht auf einen gesamten Server einräumen.
- Integrität und Vertraulichkeit: Zur Sicherung der Integrität übermittelter Nachrichten werden in OPC UA kryptografische Signaturen eingesetzt, die den Empfänger eventuelle Manipulationen erkennen lassen. Soll auch die Vertraulichkeit der Nachrichten gewährleistet bleiben, werden diese kryptografisch so verschlüsselt, dass nur der legitime Empfänger sie wieder entschlüsseln kann. Die Server-Konfiguration entscheidet darüber, welche dieser Optionen dem Client für eine Verbindung angeboten werden: keine, nur Signieren oder Signieren und Verschlüsseln; letztere ist der Default. Auch für OPC Classic kann der Einsatz von Signaturen und Verschlüsselung auf Ebene von DCOM mit etwas Mühe konfiguriert werden. Allerdings ist er in DCOM per Default nicht aktiviert.
- Transportprofile und Firewalls: OPC UA erlaubt mehrere Transportprofile zum Datenaustausch zwischen Anwendungen mit unterschiedlichen Anforderungen. Heute definiert sind ein für Geschwindigkeit und Durchsatz optimiertes binäres Transportprofil UA Binary mit UA TCP über den dafür registrierten Port TCP 4840 und ein optionales Web Services Profil UA XML mit SOAP und HTTP[S] über die TCP Ports 80 bzw. 443. Beiden gemeinsam ist, dass Verbindungen grundsätzlich nur vom Client zum Server initiiert werden und nur einen Zielport nutzen. Sie sind daher – anders als OPC Classic – mit konventionellen Firewalls effizient zu filtern.
Beispiel Dragonfly: Bessere Absicherung tut Not
Trotz aller genannten Vorzüge von OPC UA wird insbesondere in langlebigen Bestandsanlagen auch OPC Classic noch viele Jahre weiter genutzt werden. Wie dringend notwendig eine bessere Absicherung solcher Anlagen ist, zeigen beispielhaft die 2014 unter dem Namen Dragonfly bekannt gewordenen Cyber-Angriffe. In deren Rahmen wurden u.a. mehrere hundert Betreiber und Zulieferer der Pharmaindustrie vermutlich zu Spionagezwecken mit dem Remote Access Trojaner (RAT) Havex infiziert. Zu den Modulen, welche die Angreifer Havex nach erfolgreicher Infektion nachladen ließen, gehörte auch ein OPC- Scanner, der gezielt nach OPC Classic Servern suchte und deren Daten an die Angreifer zurück meldete. Besonders prekär daran: Während die Angreifer im konkreten Fall nur lesend auf die Server zugriffen, wäre es für sie oder andere nun ein Leichtes, auch destruktivere OPC Calls in den Code dieses Angriffsmoduls zu integrieren und etwa manipulierte Werte in die entdeckten Prozessdatenbanken zu schreiben. Unbefugte Server-Zugriffe mit Firewalls zu unterbinden, ist bei OPC Classic leider nicht so einfach, wie bei OPC UA. Das hat mit den besagten Windows-Grundlagen DCOM und RPC seiner Client/Server-Kommunikation zu tun. Mit der gängigen RPC-Standard-Konfiguration verwendet OPC Classic nämlich dynamisch zugewiesene Ports und sogenannte Callbacks vom Server zum Client. Ein OPC-Classic-Dialog besteht damit nach seiner Eröffnung über den DCOM Port TCP 135 aus mehreren Verbindungen in wechselnder Richtung zwischen Client und Server mit vorher nicht statisch bekannten Ports. Das macht es bei herkömmlichen Stateful Inspection Firewalls unmöglich, wirksame Regeln zur Filterung der OPC-Kommunikation zu definieren. Entsprechend ist die installierte OPC-Classic-Basis geprägt von fehlenden oder notgedrungen zu weit geöffneten Firewalls, die bestenfalls nach den IP-Adressen der bekannten Clients und Server filtern.
Deep Packet Inspection (DPI)
Konventionelle Firewalls untersuchen nur die Header von TCP/IP-Paketen für die Filterung und das sogenannte Connection Tracking, d.h. für die Prüfung, ob eine neu zu eröffnende Verbindung zulässig oder ein Paket Bestandteil einer bereits als zulässig erkannten Verbindung ist. Bei OPC Classic scheitern sie an genau diesem Connection Tracking, da Client und Server in den zwischen ihnen ausgetauschten Nutzdaten vereinbaren, wie sie dynamisch Ports und Verbindungsrichtung wechseln werden. Lässt man die Firewall hingegen mit einer Deep Packet Inspection (DPI) genannten Technik auch die Nutzdaten der Pakete auswerten, wird ein Connection Tracking möglich. Die Absprachen zwischen Client und Server nach Eröffnen einer zulässigen Verbindung werden von der Firewall verfolgt und zu deren Abwicklung dann dynamisch entsprechende weitere Ports geöffnet und wieder geschlossen.
