OPC UA ist sicher konzipiert. Die meisten Installationen sind es nicht.
Das Protokoll bringt Signatur, Verschlüsselung, zertifikatsbasierte Anwendungsidentität und benannte Benutzerauthentifizierung mit. Alles davon ist optional, und die Standardwerte sind offen. Dieser Leitfaden zeigt, was das Sicherheitsmodell wirklich leistet, welche Einstellung was verändert, und wie Sie Server schützen, die sich nicht umkonfigurieren lassen.
Zuletzt aktualisiert:
Was ist OPC-UA-Sicherheit, und warum ist sie meist abgeschaltet?
OPC-UA-Sicherheit ist ein dreischichtiges Modell im Protokoll: ein Transport, ein SecureChannel, der jede Nachricht signiert und verschlüsselt, und eine Session, die die Benutzeridentität trägt. Alle drei Schichten sind optional, und die meisten Produkte kommen mit SecurityPolicy None, MessageSecurityMode None und aktivem anonymem Zugriff, um den ersten Start zu erleichtern. Fast jede OPC-UA-Schwäche im Feld ist eine Konfigurationslücke und kein Protokollfehler, und genau das macht sie behebbar.
OPC UA ist das Protokoll, das einen Industriebestand zusammenhält: SPSen, Antriebe, Sensoren, SCADA und Historians, die nie dafür gebaut wurden, miteinander zu sprechen. Anders als Modbus wurde es von Anfang an mit Sicherheit im Blick entworfen, und das Modell ist wirklich gut. Der Haken: Es ist geschichtet und optional. Ein Server kann starke Verschlüsselung anbieten und trotzdem eine anonyme Klartextsitzung auf demselben Port annehmen, weil die meisten Produkte genau so ausgeliefert werden.
Warum bleiben die meisten OPC-UA-Server ungesichert?
Vier Standardeinstellungen erklären den Großteil dessen, was eine Bewertung in der Fertigung findet. Keine davon ist eine Schwachstelle der Spezifikation. Alle sind der Zustand, in dem ein Server steht, wenn die Inbetriebnahme endete und niemand mehr zurückkam.
SecurityMode None im Produktivbetrieb
Ein Server, der auf SecurityPolicy None mit MessageSecurityMode None steht, nimmt Klartextsitzungen von jedem an, der TCP 4840 erreicht. Der Adressraum lässt sich durchsuchen, Prozesswerte live lesen und sehr oft auch Sollwerte schreiben. Die OPC Foundation sieht None für Discovery und Tests vor, nicht für echte Daten. Wenn Sie dieses Quartal nur eine Sache prüfen, dann diese. Bei SecurityPolicy None gibt es auch keinen Schlüssel, mit dem sich das Identitätstoken verschlüsseln ließe: Eine UserName-Anmeldung schickt das Passwort als UTF-8-Klartext über die Leitung (OPC UA Part 4, 7.40).
Anonymer Benutzerzugriff bleibt aktiv
Anwendungs- und Benutzerauthentifizierung sind getrennt. Ein Kanal kann kryptografisch einwandfrei sein, mit gültigen Zertifikaten auf beiden Seiten, und trotzdem eine anonyme Sitzung darüber zulassen. Die Leitung zu verschlüsseln sagt nichts darüber, wer am anderen Ende sitzt.
Nicht vertrauenswürdige Zertifikate werden automatisch akzeptiert
Zertifikate automatisch zu akzeptieren ist während der Inbetriebnahme bequem und wird häufig nie wieder abgeschaltet. Der Schalter heißt AutoAcceptUntrustedCertificates im Stack der OPC Foundation, in Hersteller-Oberflächen oft als Trust-on-First-Use bezeichnet, obwohl er schwächer ist, als dieser Name nahelegt: Er vertraut jedem Zertifikat, jedes Mal, nicht nur dem ersten. Ein Server in diesem Zustand hat überhaupt keine Anwendungsauthentifizierung, was auch immer der Sicherheitsmodus behauptet.
Veraltete Policies aus Kompatibilitätsgründen
Basic128Rsa15 und Basic256 beruhen auf SHA-1 und schwachem RSA-Padding, und die OPC Foundation hat sie aus dem empfohlenen Satz entfernt. Meist bleiben sie angeboten, damit ein alter Client weiterläuft, und alte Clients wählen sie dann weiter.
Was kann ein Angreifer mit einem offenen OPC-UA-Server anfangen?
OPC UA ist bewusst reichhaltig: Ein Client kann den gesamten Adressraum entdecken, Live-Werte abonnieren und Methoden aufrufen. Genau diese Reichhaltigkeit macht einen nicht authentifizierten Endpunkt für Angreifer wertvoll.
Aufklärung des Adressraums
Der Browse-Dienst ist auf Selbstbeschreibung ausgelegt. Ein nicht authentifizierter Client kann jeden Knoten, seinen Datentyp und oft den lesbaren Namen des gesteuerten Prozesses auflisten und so eine Karte der Anlage erstellen, ohne ein einziges bösartiges Paket zu senden.
Unbefugte Schreibzugriffe auf Sollwerte
Wo der Server beschreibbare Knoten anbietet und keine Benutzeridentität verlangt, kann dieselbe Sitzung, die einen Wert liest, ihn auch ändern. Nichts im Protokoll unterscheidet einen Ingenieur von jedem anderen, der den Port erreicht hat.
Stiller Rückfall auf Klartext
Manche Clients fallen auf SecurityMode None zurück, wenn der sichere Handshake scheitert, statt die Verbindung abzulehnen. Ein Angreifer, der den Handshake bricht, bekommt Klartext, und der Betreiber sieht eine funktionierende Verbindung.
Mitlesen im flachen Netz
Über opc.tcp mit reinem Sign laufen die Nutzdaten lesbar. Prozesswerte, Tag-Namen und die Form des Prozesses sind für alles im selben Segment sichtbar. Passwörter sind die Ausnahme: Die Spezifikation verlangt, dass der Server das Benutzeridentitätstoken separat verschlüsselt, sobald der Kanal nicht SignAndEncrypt ist. Das Klartext-Passwort-Problem gehört damit zu SecurityPolicy None und nicht zu Sign.
Wie funktioniert das OPC-UA-Sicherheitsmodell?
OPC-UA-Sicherheit ist kein Schalter. Die Spezifikation beschreibt drei zusammenwirkende Schichten, und zu wissen, zu welcher eine Einstellung gehört, ist der größte Teil der Arbeit.
- 01
Transport
Die Verbindung, die Bytes bewegt. Beim üblichen opc.tcp-Binding ist das ein reiner TCP-Socket. Bei den Bindings opc.https und opc.wss ist es TLS.
- 02
Kommunikation: der SecureChannel
Hier entstehen Vertraulichkeit und Integrität, unabhängig vom Transport. Über opc.tcp ist das UA-SecureConversation: Es handelt Schlüssel aus, signiert Nachrichten und verschlüsselt sie optional.
- 03
Anwendung: die Session
Läuft auf einem SecureChannel und trägt Benutzerauthentifizierung und Autorisierung. Eine Session kann einem neuen Kanal zugeordnet werden, wenn die Verbindung abbricht.
Was ist der Unterschied zwischen None, Sign und SignAndEncrypt?
Beim Öffnen eines SecureChannel wählt der Client einen von drei Modi. Sie entsprechen unmittelbar dem Schutz, den der Verkehr bekommt.
| Modus | Integrität | Vertraulichkeit | Wo es hingehört |
|---|---|---|---|
| None | Keine. Nichts erkennt Manipulation. | Keine. Klartext auf der Leitung. | Nur Discovery und Tests. Auf einem Produktivendpunkt fehl am Platz. |
| Sign | Jede Nachricht signiert. Manipulation ist erkennbar. | Keine. Nutzdaten lesbar auf der Leitung. | Enger Fall: wenn Integrität zählt und Vertraulichkeit wirklich nicht. |
| SignAndEncrypt | Jede Nachricht signiert. | Vollständig. Nutzdaten verschlüsselt. | Der Standard im Produktivbetrieb. Alles mit Sollwerten, Prozesswerten oder Anmeldedaten. |
Welche OPC-UA-SecurityPolicy sollten Sie verwenden?
Eine SecurityPolicy ist der benannte Satz an Algorithmen, den ein SecureChannel verwendet, sobald Sign oder SignAndEncrypt gewählt ist. Die Policy zu wählen heißt, die kryptografische Stärke zu wählen.
| Policy | Algorithmen | Status |
|---|---|---|
| Aes256_Sha256_RsaPss | AES-256, SHA-256, RSA-PSS-Signaturen | Aktuelle Empfehlung. Bevorzugen Sie sie überall dort, wo beide Seiten sie unterstützen. |
| Aes128_Sha256_RsaOaep | AES-128, SHA-256, RSA-OAEP | Aktuell, leichter. Vertretbar, wo AES-128 die Anforderung erfüllt. |
| Basic256Sha256 | AES-256, SHA-256, RSA-PKCS#1-v1.5-Signaturen | Weit verbreitet und weiterhin akzeptabel. Sinnvoll, wenn die neueren Policies nicht auf beiden Seiten verfügbar sind. |
| Basic256 | AES-256, SHA-1, RSA-OAEP | Von der OPC Foundation als veraltet eingestuft. Das Padding ist solide, aber SHA-1 ist nicht mehr akzeptabel. Ihr Vorhandensein ist ein Befund. |
| Basic128Rsa15 | AES-128, SHA-1, RSA-PKCS#1-v1.5-Verschlüsselung | Von der OPC Foundation als veraltet eingestuft. Schwaches Padding und gebrochener Hash. Ihr Vorhandensein ist ein Befund. |
Ein konkreter Prüfschritt
Jeder OPC-UA-Server veröffentlicht seine unterstützten Endpunkte über den Discovery-Dienst. Listen Sie sie auf, prüfen Sie, ob der Server eine starke Policy mit SignAndEncrypt anbietet, und ob die veralteten Policies deaktiviert sind oder zumindest nicht die sind, die Clients tatsächlich wählen. Eine Endpunktliste ist die schnellste ehrliche Antwort auf „ist das abgesichert“.
Welche Authentifizierungsmethoden bietet OPC UA?
OPC UA authentifiziert auf zwei getrennten Ebenen, und sie zu vermischen ist eine häufige Quelle falscher Sicherheit. Die eine fragt, ob die Software am anderen Ende bekannt ist. Die andere fragt, wer sie benutzt.
Anwendungsauthentifizierung
Findet auf der SecureChannel-Ebene statt und beantwortet: „Sind diese Client- und diese Serveranwendung, wer sie zu sein behaupten?“ Jede Anwendung hält ein X.509-Instanzzertifikat, und beide Seiten tauschen und prüfen Zertifikate beim Aufbau des Kanals. Vertrauen wird über eine Zertifikats-Vertrauensliste verwaltet: Sie entscheiden, welche Zertifikate oder welche ausstellende CA Sie akzeptieren. Das verhindert, dass eine unbekannte Anwendung überhaupt einen Kanal aufbaut.
Benutzerauthentifizierung
Findet auf Session-Ebene statt und beantwortet: „Welcher Mensch oder Dienst ist am anderen Ende?“ OPC UA kennt mehrere Identitätstoken: Anonymous, das im Produktivbetrieb nichts zu suchen hat, UserName mit Passwort und X.509-Benutzerzertifikate. Ein Kanal kann auf Anwendungsebene kryptografisch einwandfrei sein und trotzdem einen anonymen Benutzer darüber zulassen.
Ein richtig abgesicherter Endpunkt macht beides: Er prüft das Zertifikat der Gegenanwendung gegen eine gepflegte Vertrauensliste und verlangt eine benannte Benutzeridentität. Diese Zertifikate auszustellen, zu verteilen, zu vertrauen und zu rotieren ist die operative Arbeit, die daraus Realität macht, und genau daran sparen die meisten Teams.
Wo bricht OPC-UA-Sicherheit im Feld?
Die meisten OPC-UA-Vorfälle gehen auf Konfiguration zurück, nicht auf Protokollfehler. Diese fünf machen den Großteil dessen aus, was eine Bewertung zutage fördert.
SecurityMode None im Produktivbetrieb
Mit Abstand das dominierende Problem und das erste, das zu prüfen ist.
Nicht vertrauenswürdige Zertifikate automatisch akzeptieren
AutoAcceptUntrustedCertificates dauerhaft aktiv, was die Anwendungsauthentifizierung vollständig aushebelt.
Anonymer Zugriff neben einem verschlüsselten Kanal
Der Kanal ist solide, die Sitzung steht weit offen, und Dashboards melden den Endpunkt als abgesichert.
Veraltete Policies weiterhin angeboten
Aus Rückwärtskompatibilität behalten und dann genau von den alten Clients gewählt, um die es ging.
Stiller Rückfall auf Klartext
Ein Client, der auf None zurückfällt, wenn der sichere Handshake scheitert, statt die Verbindung schlicht abzulehnen.
Wie verwalten Sie OPC-UA-Zertifikate ohne Global Discovery Server?
Die Anwendungsauthentifizierung von OPC UA hängt an Zertifikaten, und die Antwort der Spezifikation für größere Bestände ist ein Global Discovery Server (GDS, OPC UA Part 12). Viele OT-Anlagen stellen nie einen auf: Es ist ein weiterer Server, der im Prozessnetz betrieben, gepatcht und gesichert werden will, und ein kleiner Bestand rechtfertigt das selten. Die Schichten funktionieren weiterhin, nur die Verteilung ändert sich.
Aus einer lokalen Instanz ausstellen
Eine CA vor Ort oder selbstsignierte Instanzzertifikate, wenn die Anlage klein genug zum Aufzählen ist. Entscheidend ist, dass ein Mensch festgelegt hat, welchen Zertifikaten vertraut wird, nicht dass eine öffentliche CA dafür bürgt.
Vertrauenslisten bewusst befüllen
Jede Anwendung führt ihre eigene Vertrauensliste. Sie bei der Inbetriebnahme zu füllen und danach AutoAcceptUntrustedCertificates abzuschalten, macht aus Zertifikaten statt Dekoration echte Authentifizierung.
Rotation vor dem Ablauf planen
Zertifikate laufen ab, und in einer abgeschotteten Anlage erneuert sie nichts von selbst. Ein Ablaufdatum, das niemand verfolgt hat, wird an einem Sonntag zum Ausfall. Halten Sie Ausstellungs- und Ablaufdaten in demselben Runbook fest, das auch den übrigen Netzzustand führt.
Oder das Problem von den Endgeräten wegnehmen
Wo Zertifikatsarbeit pro Gerät nicht realistisch ist, sorgt das Terminieren der Sitzung an einem protokollbewussten Proxy dafür, dass eine Komponente die PKI hält statt jedes Gerät ein Stück davon.
OPC-UA-Härtungscheckliste: was zu prüfen ist
OPC-UA-Sicherheit läuft auf eine kurze, prüfbare Liste hinaus. Das meiste davon ist Nachweis, nicht Aufbau. All das setzt eines voraus: dass Sie den Endpunkt ändern dürfen. Wo das nicht der Fall ist, behandelt der nächste Abschnitt den anderen Weg, dieselben Lücken zu schließen.
- 01
Prüfen, dass kein Produktivendpunkt im MessageSecurityMode None läuft.
- 02
SignAndEncrypt für alles verlangen, was Prozessdaten, Sollwerte oder Anmeldedaten trägt.
- 03
Eine aktuelle SecurityPolicy wählen, bevorzugt Aes256_Sha256_RsaPss, und Basic128Rsa15 sowie Basic256 abschalten.
- 04
Instanzzertifikate gegen eine gepflegte Vertrauensliste prüfen und AutoAcceptUntrustedCertificates nach der Inbetriebnahme abschalten.
- 05
Eine benannte Benutzeridentität verlangen. Anonymen Zugriff deaktivieren.
- 06
Prüfen, dass Clients eine Herabstufung verweigern, statt auf Klartext zurückzufallen.
- 07
Daran denken: Über opc.tcp schützt der SecureChannel, während opc.https und opc.wss auf TLS aufsetzen. Prüfen Sie das Binding, bevor Sie überlegen, was ein Proxy oder ein Mitschnitt sehen kann.
Diese Maßnahmen entsprechen der Identifizierung und Authentifizierung nach IEC 62443 (FR1) und der Nutzungskontrolle (FR2), NIST SP 800-82r3 für OT-Systeme und den Zugriffskontrollmaßnahmen, die NIS2 Artikel 21 von wesentlichen und wichtigen Einrichtungen verlangt.
Verwendet OPC UA TLS?
Über opc.tcp schützt der SecureChannel Ihre Daten, nicht TLS. Eine Verbindung, die verschlüsselt aussieht, nutzt nicht zwangsläufig TLS, denn UA-SecureConversation signiert und verschlüsselt selbst. TLS kommt erst mit den Bindings opc.https und opc.wss ins Spiel. Das zählt in dem Moment, in dem Sie überlegen, was eine Firewall, ein Mitschnitt oder ein TLS-terminierender Proxy sehen kann und was nicht.
Wie sichern Sie einen OPC-UA-Server, den Sie nicht umkonfigurieren können?
Die Checkliste setzt voraus, dass Sie den Endpunkt ändern können. Oft können Sie das nicht: Der Hersteller verbietet es, es gibt kein Wartungsfenster, oder der Server ist älter als die Teile der Spezifikation, die Sie durchsetzen wollen. Die Alternative ist, den Schutz vor das Gerät zu legen, auf Netzebene, sodass der ungesicherte Endpunkt nie direkt erreichbar ist.
In einen transparenten Tunnel hüllen
Das Access Gate betreibt eine eigene PKI und stellt Endzertifikate im laufenden Betrieb aus. Der Kanal zum Gate ist TLS 1.3 mit Post-Quanten-Schlüsselaustausch (ML-KEM-768), geprüft gegen diese PKI, vor einem Server, der nichts davon spricht, und ohne Zertifikatsarbeit pro Gerät.
Default-Deny nach Identität und Protokoll
Einem Benutzer OPC-UA-Zugriff auf ein Asset zu geben, gibt ihm sonst nichts. Jedes Protokoll auf jedem Asset ist eine ausdrückliche Erlaubnis, also genau die Durchsetzung, die die anonyme Sitzung des Servers nicht leisten kann.
Den Server aus dem flachen Netz halten
Der Endpunkt sitzt in einer segmentierten Enclave und behält seine eigene IP. Am Gerät ändert sich nichts, und nichts erreicht TCP 4840, ohne vorher die Policy zu passieren.
Festhalten, wer sich womit verbunden hat
Derselbe Proxy, der den Kanal kontrolliert, protokolliert die Sitzung: welche Identität, welches Asset, welches Protokoll. Das ist der Zugriffsnachweis, den IEC 62443, NIST SP 800-82r3, NIS2 und CMMC am Ende verlangen.
Einen OPC-UA-Server unter Kontrolle bringen, ohne ihn anzufassen
Wenn Ihr Bestand Server enthält, die sich nicht umkonfigurieren lassen, oder Zertifikatsarbeit, die pro Gerät unrealistisch ist, gehen wir gemeinsam durch, wie das Kontrollieren des Kanals in Ihrem Netz aussieht.
OPC-UA-Zugriff konfigurieren
Die Schritt-für-Schritt-Anleitung: einen ungesicherten Server in eine Enclave holen und den Kanal dann per TLS, Message Security oder kontrolliertem Tunnel absichern.
Am eigenen Bestand sehen
Ein Durchgang an Ihrer Topologie: welche Endpunkte offen liegen, wie die Durchsetzung aussieht und was die Einführung erfordert.
Fragen zur OPC-UA-Sicherheit
Der Standard-TCP-Port von OPC UA. Ein Endpunkt, der hier im SecurityMode None lauscht, ist lesbar und oft beschreibbar für alles, was ihn routen kann.
Nur bei manchen Bindings. Die Bindings opc.https und opc.wss setzen auf TLS auf. Das übliche opc.tcp-Binding nicht: Es nutzt UA-SecureConversation, die protokolleigene Signatur und Verschlüsselung auf der SecureChannel-Ebene. Eine Verbindung kann vollständig verschlüsselt sein, ohne dass TLS beteiligt ist, was zählt, sobald Sie überlegen, was ein TLS-terminierender Proxy oder ein Mitschnitt sehen kann.
Nein. Das Sicherheitsmodell ist stark, aber jede seiner Schichten ist optional, und die meisten Produkte kommen mit SecurityPolicy None, MessageSecurityMode None und aktivem anonymem Zugriff, um den ersten Start zu erleichtern. Ein Server ist nur sicher, wenn ihn jemand nach der Inbetriebnahme so konfiguriert hat.
Sign liefert Integrität: Jede Nachricht ist signiert, Manipulation ist also erkennbar, aber die Nutzdaten bleiben auf der Leitung lesbar. SignAndEncrypt ergänzt Vertraulichkeit, die Nutzdaten sind zusätzlich verschlüsselt. Für produktiven OT-Verkehr sollte SignAndEncrypt der Standard sein; Sign hat nur einen engen Platz, wenn Vertraulichkeit wirklich keine Rolle spielt.
Aes256_Sha256_RsaPss, wo beide Seiten sie unterstützen, und Basic256Sha256 als vertretbaren Rückfall. Basic128Rsa15 und Basic256 sind veraltet: Sie beruhen auf SHA-1 und schwachem RSA-Padding, und die OPC Foundation hat sie aus dem empfohlenen Satz entfernt. Bietet ein Server sie noch an, behandeln Sie das als Befund und nicht als zu erhaltende Einstellung.
Legen Sie den Schutz davor. Holen Sie den Server in eine segmentierte Enclave, damit er nicht direkt erreichbar ist, und terminieren Sie die Sitzung an einem protokollbewussten Proxy, der Identität und Policy anwendet, bevor er die Verbindung zum Asset wieder aufbaut. Das Gerät behält IP, Firmware und Konfiguration, und Verschlüsselung, Zugriffskontrolle und Protokollierung passieren am Kontrollpunkt statt am Endpunkt.
