OPC-UA-Sicherheit: Was jeder OT-Ingenieur wissen sollte

Warum OPC-UA-Sicherheit einen genaueren Blick verdient

Als Ingenieur für Betriebstechnik (OT) wissen Sie, wie viel von industriellen Systemen abhängt. OPC UA (Open Platform Communications Unified Architecture) ist heute das Protokoll, das diese Systeme miteinander verbindet: SPS, Sensoren, Antriebe, SCADA und Historian-Systeme, die nie dafür ausgelegt waren, ein gemeinsames Netz zu nutzen. Die gute Nachricht ist, dass OPC UA von Anfang an mit Blick auf Sicherheit entworfen wurde. Die schlechte ist, dass dieses Modell mehrschichtig und optional ist, was bedeutet, dass die meisten Installationen im Feld nur einen Teil davon aktivieren, oder gar nichts. Genau zu wissen, was das Protokoll bietet und welche Einstellung was bewirkt, macht den Unterschied zwischen einem gehärteten Endpunkt und einer offenen Tür.

Dieser Leitfaden geht das OPC-UA-Sicherheitsmodell so durch, wie die Spezifikation es tatsächlich strukturiert, und zeigt anschließend die Fehler, die im Feld am häufigsten auftreten.

Das mehrschichtige Sicherheitsmodell

OPC-UA-Sicherheit ist keine einzelne Funktion, die man einschaltet. Das Dokument OPC Foundation Part 2 Security Model beschreibt sie als drei zusammenwirkende Schichten, von denen jede ein eigenes Problem löst:

1. Transportschicht. Das ist die zugrunde liegende Verbindung, die die Bytes zwischen Client und Server überträgt. Für das gängige opc.tcp-Binding ist der Transport ein einfacher TCP-Socket. Für die HTTPS- und WebSocket-Bindings (opc.https, opc.wss) ist der Transport TLS.
2. Kommunikationsschicht (der SecureChannel). Hier stellt OPC UA die Vertraulichkeit und Integrität der Kommunikation her, unabhängig vom Transport. Über opc.tcp wird diese Schicht durch UA-SecureConversation bereitgestellt, definiert in OPC Foundation Part 6 Mappings. Sie handelt Schlüssel aus, signiert Nachrichten und verschlüsselt sie optional.
3. Anwendungsschicht (die Session). Eine Session läuft auf einem SecureChannel und ist der Ort, an dem die Benutzerauthentifizierung und -autorisierung stattfinden. Ein einzelner SecureChannel kann eine Session tragen, und Sessions können einem neuen Kanal neu zugeordnet werden, wenn die zugrunde liegende Verbindung abbricht.

Das Entscheidende, das Sie verinnerlichen sollten: Über opc.tcp ist die Sicherheit, die Ihre Daten schützt, der SecureChannel, nicht TLS. Häufig wird angenommen, dass eine Verbindung, die «verschlüsselt aussieht», zwangsläufig TLS verwendet, doch opc.tcp erledigt seine eigene Signierung und Verschlüsselung über UA-SecureConversation. TLS kommt erst ins Spiel, wenn Sie die Bindings opc.https oder opc.wss verwenden. Diese Unterscheidung ist wichtig, sobald Sie überlegen, was eine Firewall, ein Paketmitschnitt oder ein TLS-terminierender Proxy sehen kann, und was nicht.

MessageSecurityMode: None, Sign, SignAndEncrypt

Wenn ein Client einen SecureChannel öffnet, wählt er einen MessageSecurityMode. Es gibt drei Werte, und sie entsprechen direkt dem Schutz, den Ihr Datenverkehr tatsächlich erhält:

• None. Keine Signierung, keine Verschlüsselung. Nachrichten werden im Klartext übertragen, und nichts prüft, ob sie unterwegs verändert wurden. Das entspricht dem Betrieb des Protokolls mit ausgehängten Türen.
• Sign. Jede Nachricht wird signiert, sodass der Empfänger Manipulationen erkennen und bestätigen kann, dass die Nachricht vom Inhaber des ausgehandelten Schlüssels stammt. Der Inhalt bleibt im Netz lesbar, kann aber nicht unbemerkt verändert werden.
• SignAndEncrypt. Nachrichten werden sowohl signiert als auch verschlüsselt. So erhalten Sie Integrität und Vertraulichkeit zusammen, und dies ist der Modus, den Sie für alles wählen sollten, was Sollwerte, Prozesswerte oder Anmeldedaten überträgt.

Für OT-Datenverkehr in der Produktion sollte SignAndEncrypt die Standardeinstellung sein. Sign allein hat einen begrenzten Platz, wenn Vertraulichkeit wirklich keine Rolle spielt, Integrität aber schon. None hat in der Produktion praktisch keinen Platz, was uns zum häufigsten Fehler im Feld führt.

Die None-Falle

Das häufigste OPC-UA-Sicherheitsproblem ist kein exotischer Exploit. Es sind Server, die auf SecurityPolicy=None belassen werden, mit MessageSecurityMode=None und anonymem Benutzerzugriff, genau die Konfiguration, in der viele Produkte ab Werk ausgeliefert werden, um den Erststart bequem zu machen. In diesem Zustand kann jeder, der den TCP-Port (häufig 4840) erreicht, den Adressraum durchsuchen, Live-Prozesswerte lesen und oft Sollwerte schreiben, ohne Authentifizierung und ohne Verschlüsselung.

Das ist kein theoretisches Risiko. So laufen tatsächlich ein großer Teil der ins Internet exponierten und in flachen Netzen befindlichen OPC-UA-Server, weil die sicheren Modi nach der Inbetriebnahme nie aktiviert wurden. Die Leitlinien der OPC Foundation im Artikel "Exploring OPC UA Security Concepts" sagen ausdrücklich, dass None für Discovery und Tests gedacht ist, nicht für die Übertragung echter Daten. Wenn Sie in diesem Quartal nur eines prüfen, prüfen Sie Produktionsendpunkte auf den None-Modus.

SecurityPolicies: welche Krypto-Suite im Einsatz ist

Eine SecurityPolicy ist der benannte Satz kryptografischer Algorithmen, der Hash, die symmetrischen und asymmetrischen Chiffren, die Signatur- und Schlüsselableitungsalgorithmen, den ein SecureChannel verwendet, sobald Sign oder SignAndEncrypt gewählt ist. Eine Policy zu wählen heißt, Ihre kryptografische Stärke zu wählen. Diese werden Ihnen begegnen:

• Aes256_Sha256_RsaPss. Die derzeit empfohlene Policy. Sie verwendet AES-256, SHA-256 und RSA-PSS-Signaturen. Bevorzugen Sie sie, wenn beide Seiten sie unterstützen.
• Basic256Sha256. Weit verbreitet und weiterhin als akzeptabel angesehen. AES-256 mit SHA-256 und RSA-PKCS#1-v1.5-Signaturen. Eine vernünftige Wahl, wenn die neuere Policy nicht auf beiden Seiten verfügbar ist.
• Basic128Rsa15 und das ältere Basic256. Diese Policies sind veraltet. Sie stützen sich auf SHA-1 und schwaches RSA-Padding, und die OPC Foundation hat sie aus dem empfohlenen Satz entfernt. Behandeln Sie ihr Vorhandensein als zu behebenden Befund, nicht als beizubehaltende Konfiguration.

Ein praktischer Audit-Schritt: Zählen Sie die Endpunkte auf, die ein Server bekannt gibt (jeder OPC-UA-Server stellt seine unterstützten Endpunkte über den Discovery-Dienst bereit), und prüfen Sie, dass er eine starke Policy mit SignAndEncrypt anbietet und dass die veralteten Policies entweder deaktiviert sind oder von den Clients nicht ausgewählt werden.

Anwendungsauthentifizierung gegenüber Benutzerauthentifizierung

OPC UA authentifiziert auf zwei verschiedenen Ebenen, und beide zu verwechseln ist eine häufige Quelle falscher Sicherheit.

• Die Anwendungsauthentifizierung findet auf der Ebene des SecureChannel statt und beantwortet die Frage: «Sind diese Client-Anwendung und diese Server-Anwendung die, die sie vorgeben zu sein?» Sie beruht auf Anwendungsinstanz-Zertifikaten: Jede Anwendung besitzt ein X.509-Zertifikat, und beide Seiten tauschen ihre Zertifikate aus und validieren sie beim Aufbau des Kanals. Das Vertrauen wird über eine Vertrauensliste für Zertifikate auf jeder Seite verwaltet; Sie entscheiden, welche Zertifikate (oder welche ausstellende CA) Sie akzeptieren. Das hindert eine unbekannte Anwendung daran, überhaupt einen sicheren Kanal aufzubauen.
• Die Benutzerauthentifizierung findet auf der Ebene der Session statt und beantwortet die Frage: «Wer, Mensch oder Dienst, befindet sich am anderen Ende?» OPC UA unterstützt mehrere Arten von Benutzeridentitäts-Token: Anonymous (keine Benutzeridentität, in der Produktion zu vermeiden), UserName/Password und X.509-Benutzerzertifikate. Ein SecureChannel kann auf Anwendungsebene kryptografisch solide sein und dennoch auf Session-Ebene einen anonymen Benutzer zulassen, daher erfordern beide Schichten Aufmerksamkeit.

Die Schlussfolgerung: Ein korrekt gesicherter OPC-UA-Endpunkt validiert das Zertifikat der Gegenstellen-Anwendung gegen eine verwaltete Vertrauensliste und verlangt eine benannte Benutzeridentität statt anonymem Zugriff. Die Zertifikatsverwaltung, das Ausstellen, Verteilen, als vertrauenswürdig Einstufen und Erneuern von Anwendungs- und Benutzerzertifikaten, ist die operative Arbeit, die dies real macht, und sie ist auch der Teil, in den die meisten Teams zu wenig investieren.

Wo sich die realen Stolpersteine häufen

Die meisten OPC-UA-Vorfälle im Feld gehen auf die Konfiguration zurück, nicht auf Protokollfehler:

• Der None-Modus in der Produktion, wie oben beschrieben, das vorherrschende Problem.
• Das automatische Akzeptieren nicht vertrauenswürdiger Zertifikate. Manche Installationen konfigurieren den Server so, dass er jedem gesehenen Zertifikat vertraut (ein dauerhaft aktiviertes «trust on first use»), was die Anwendungsauthentifizierung vollständig aushebelt.
• Anonymer Benutzerzugriff, der neben einem ansonsten verschlüsselten Kanal aktiviert bleibt.
• Veraltete SecurityPolicies, die aus Gründen der Abwärtskompatibilität verfügbar gehalten und dann von alten Clients ausgewählt werden.
• Klartext-Rückfall, wenn ein Client stillschweigend auf None herabstuft, sobald der sichere Handshake fehlschlägt, statt die Verbindung abzulehnen.

Genau das sind die Schwächen, die umfassendere OT-Sicherheitsleitlinien wie das NIST SP 800-82, Guide to Operational Technology Security zu finden und zu schließen empfehlen: Authentifizierung erzwingen, Daten bei der Übertragung schützen und das Netz segmentieren, damit ein ungesicherter Endpunkt nicht von überall direkt erreichbar ist.

Was Sie dagegen tun können

In der Regel haben Sie zwei sich ergänzende Wege. Der erste besteht darin, die OPC-UA-Sicherheit an den Endpunkten selbst korrekt zu konfigurieren: eine starke SecurityPolicy wählen, SignAndEncrypt verlangen, Anwendungszertifikate gegen eine echte Vertrauensliste validieren und eine benannte Benutzerauthentifizierung verlangen. Der zweite, für Altsysteme und Clients, die Sie nicht umkonfigurieren können, besteht darin, den Schutz auf Netzwerkebene vor das Gerät zu setzen, indem Sie den Server in eine segmentierte Enklave holen und den Kanal über einen kontrollierten Tunnel sichern, sodass der ungesicherte Endpunkt nie direkt exponiert ist.

OPC UA-Endpunkte absichern, die sich nicht selbst absichern können

Dieser zweite Weg ist genau die Lücke, die Trout Access Gate schließen soll. Anstatt auf jedem Endpunkt Zertifikate bereitzustellen und zu pflegen, beendet Access Gate die Sitzung an einem protokollbewussten Proxy, wendet Identität und Richtlinie an und stellt die Verbindung zum Anlagengerät erneut her. Dieser eine Engpass ermöglicht es, Verschlüsselung hinzuzufügen, Zugriff durchzusetzen und den Datenverkehr einzusehen, ohne die Firmware des Geräts anzufassen.

Für einen OPC UA-Server oder jedes Klartext- oder Altprotokoll bedeutet das, dass Sie:

• Ihn in einen transparenten TLS-Tunnel einbinden. Access Gate betreibt eine eigene PKI und stellt Endzertifikate spontan aus, sodass ein Gerät, das im Werk Klartext spricht, ohne geräteweise Zertifikatsarbeit sicher über ein größeres Netzwerk erreichbar wird. Der Leitfaden TLS-Verschlüsselung einrichten beschreibt dies vollständig, und Die Rolle von TLS bei der Absicherung von OPC UA erklärt, wo TLS für OPC UA gilt und wo nicht.
• Standardmäßig nach Identität und Protokoll verweigern. Einem Benutzer OPC UA-Zugriff auf ein Anlagengerät zu gewähren, gewährt nichts anderes; jedes Protokoll auf jedem Gerät ist eine ausdrückliche Freigabe. Siehe Anwendungsfälle der Protokollkonfiguration.
• Segmentieren und beobachten. Derselbe Proxy, der den Kanal kontrolliert, protokolliert, wer sich womit und über welches Protokoll verbunden hat, also genau den Nachweis, den Rahmenwerke wie NIST 800-171, CMMC und NIS2 letztlich verlangen. Das ist der Kern der OT-Netzwerksicherheit.

Fazit

OPC-UA-Sicherheit lässt sich auf eine kurze, überprüfbare Liste herunterbrechen. Bestätigen Sie, dass Produktionsendpunkte nicht im None-Modus laufen. Verlangen Sie SignAndEncrypt mit einer aktuellen SecurityPolicy wie Aes256_Sha256_RsaPss und mustern Sie veraltete Policies wie Basic128Rsa15 aus. Validieren Sie Anwendungsinstanz-Zertifikate gegen eine verwaltete Vertrauensliste und verlangen Sie eine benannte Benutzerauthentifizierung statt anonymem Zugriff. Denken Sie daran, dass über opc.tcp Ihr Schutz der SecureChannel ist, während opc.https und opc.wss auf TLS aufbauen. Nahezu jede OPC-UA-Schwäche, die Sie im Feld finden, ist eine Konfigurationslücke und kein Protokollfehler, was zugleich bedeutet, dass Sie sie beheben können.