15 Oktober 2026

OPC UA Security umfasst die Sicherheitsmechanismen von OPC UA und ihre geeignete Anwendung im Betrieb. Dazu gehören die Prüfung von Kommunikationspartnern, der Schutz übertragener Nachrichten und die Begrenzung erlaubter Zugriffe. Die tatsächliche Schutzwirkung hängt von unterstützten Funktionen, Konfigurationen und dauerhaft gepflegten Vertrauens- und Berechtigungsregeln ab.

Was bedeutet Sicherheit bei OPC UA?

OPC UA ermöglicht den strukturierten Austausch industrieller Informationen. Dabei können Daten nur gelesen, aber je nach Anwendung auch Werte geschrieben oder Methoden aufgerufen werden. Die möglichen Auswirkungen unterscheiden sich erheblich. Ein Zugriff auf Produktionsmeldungen benötigt deshalb eine andere Berechtigung als eine Änderung prozessrelevanter Parameter.

Die OPC-UA-Spezifikation unterscheidet unter anderem Anwendungsauthentisierung, Benutzerauthentisierung und Autorisierung. Zusätzlich stehen Mechanismen für Integrität und Vertraulichkeit der Kommunikation zur Verfügung. Diese Funktionen beantworten unterschiedliche Fragen und müssen passend kombiniert werden.

Ein Produkt mit OPC-UA-Unterstützung ist nicht allein dadurch sicher konfiguriert. Der Betreiber muss prüfen, welche Funktionen tatsächlich vorhanden und aktiviert sind. Das gilt auch für die Verbindung zwischen zwei ansonsten vertrauenswürdigen Systemen: Die gewünschte Aufgabe und ihr zulässiger Umfang bleiben ausdrücklich festzulegen.

Anwendung, Benutzer und Berechtigung unterscheiden

Ebene	Leitfrage	Beispiel
Anwendung	Ist der Kommunikationspartner die vorgesehene Anwendung?	Ein freigegebener Datenerfassungsclient verbindet sich
Benutzer oder technische Identität	Unter welcher Identität erfolgt die Nutzung?	Ein Dienstkonto wird für die Datenerfassung verwendet
Berechtigung	Welche Daten und Funktionen dürfen genutzt werden?	Lesen bestimmter Werte, aber kein Schreiben

Ein akzeptiertes Anwendungszertifikat bedeutet daher nicht automatisch, dass jeder gewünschte Zugriff erlaubt sein soll. Ebenso ersetzt eine erfolgreiche Benutzeranmeldung nicht die Prüfung der konkreten Rechte. Für eine Anwendung sollte nachvollziehbar sein, welche Identität mit welchen Funktionen verknüpft ist.

In der Praxis unterscheiden sich die Konfigurationsmöglichkeiten der Produkte. Einige unterstützen detaillierte Rollen, andere stellen eingeschränktere Modelle bereit. Vor der Auswahl muss deshalb geprüft werden, ob der benötigte Zugriffsumfang tatsächlich abgebildet werden kann.

SecurityMode und SecurityPolicy

Für die klassische Client-Server-Kommunikation kennt OPC UA die SecurityModes None, Sign und SignAndEncrypt. Sign schützt Nachrichten durch Signaturen; SignAndEncrypt ergänzt Verschlüsselung. None bietet auf dieser Ebene keinen entsprechenden Nachrichtenschutz. Die SecurityPolicy beschreibt die verwendeten Sicherheitsverfahren. Ihre Auswahl ist von den unterstützten Profilen und dem Schutzbedarf zu unterscheiden.

Die konkrete Konfiguration muss mit den aktuellen Fähigkeiten beider Anwendungen und den betrieblichen Vorgaben abgeglichen werden. Eine Verbindung sollte nicht nur deshalb dauerhaft mit schwächeren Einstellungen betrieben werden, weil sie damit schneller in Betrieb genommen werden konnte. Nicht benötigte unsichere Endpunkte sind im vorgesehenen Schutzkonzept zu behandeln.

Für OPC UA PubSub gelten eigene Zusammenhänge, etwa hinsichtlich Nachrichten- und Schlüsselverwaltung. Aussagen zu einer Client-Server-Sitzung lassen sich deshalb nicht unverändert auf jede PubSub-Konfiguration übertragen. Bei einer Planung muss zuerst das tatsächlich eingesetzte Kommunikationsmodell feststehen.

Zertifikate und Vertrauenslisten verwalten

Anwendungszertifikate dienen der Zuordnung von Identität und öffentlichem Schlüssel. Eine Vertrauensliste legt fest, welchen Zertifikaten beziehungsweise ausstellenden Stellen vertraut wird. Die Entscheidung, einen Partner aufzunehmen, muss geprüft erfolgen. Das automatische Akzeptieren jedes angebotenen Zertifikats würde den Zweck dieser Vertrauensentscheidung unterlaufen.

OPC UA unterstützt selbstsignierte und von einer Zertifizierungsstelle ausgestellte Anwendungszertifikate. Der Unterschied betrifft wesentlich die Verwaltung des Vertrauens. Eine Zertifizierungsstelle ist nicht allein wegen ihres Vorhandenseins ein Beleg für eine passende Vertrauenskonfiguration. Ihre Zuständigkeit und die zugelassenen Anwendungen müssen zum betrieblichen Konzept passen.

Zertifikate besitzen eine begrenzte Gültigkeit. Erneuerung, Widerruf und die Verteilung notwendiger Vertrauensinformationen müssen deshalb im Betrieb geregelt sein. Bei größeren Installationen können geeignete zentrale Verwaltungsfunktionen unterstützen. Entscheidend ist, dass alle beteiligten Anwendungen den vorgesehenen Ablauf tatsächlich unterstützen.

Private Schlüssel dürfen nicht wie gewöhnliche austauschbare Konfigurationsdateien behandelt werden. Zuständigkeiten und Schutzmaßnahmen müssen ihrer Bedeutung entsprechen. Auch ein Gerätewechsel benötigt einen kontrollierten Umgang mit Identität und Vertrauensbeziehungen.

Praxisbeispiel: Qualitätsdaten lesen, Parameter schützen

Das folgende Beispiel ist fiktiv. Ein Qualitätsdashboard soll Messwerte von einer Anlage auslesen. Es benötigt keine Funktion zum Schreiben von Sollwerten oder zum Starten von Maschinenabläufen. Der Betrieb richtet deshalb eine dafür geeignete technische Identität mit dem vorgesehenen Leseumfang ein.

Client und Server werden mit den festgelegten Sicherheitseinstellungen verbunden. Die Vertrauensbeziehung der Anwendungen wird anhand der vorgesehenen Zertifikate geprüft. Anschließend wird getestet, ob die benötigten Messwerte verfügbar sind und nicht freigegebene Schreiboperationen abgewiesen werden.

Später wird das Clientzertifikat erneuert. Die Verantwortlichen bereiten die Änderung so vor, dass der neue Zustand auf beiden Seiten bekannt ist. Nach der Umstellung prüfen sie die Datenübertragung und die weiterhin gültigen Zugriffsbeschränkungen. Eine vorübergehende allgemeine Freigabe unbekannter Zertifikate gehört nicht zum vorgesehenen Ablauf.

Das Beispiel trennt Verbindungsschutz von fachlichen Rechten. Selbst eine verschlüsselte Verbindung wäre unpassend, wenn das Dashboard damit unbeabsichtigt Prozessparameter ändern dürfte. Umgekehrt schützt eine reine Leseberechtigung vertrauliche Daten nicht automatisch während ihrer Übertragung.

OPC-UA-Sicherheit in Betrieb nehmen

Aufgabe beschreiben: Daten, Methoden und erlaubte Operationen festlegen.
Funktionen abgleichen: Unterstützte Sicherheitsprofile, Identitäten und Rechte prüfen.
Vertrauen einrichten: Kommunikationspartner und Zertifikate nachvollziehbar zuordnen.
Nachrichtenschutz konfigurieren: Geeignete Einstellungen auf beiden Seiten abstimmen.
Positive und negative Tests durchführen: Erlaubte Funktionen müssen funktionieren, unzulässige abgewiesen werden.
Betrieb übergeben: Zuständigkeiten für Erneuerung, Änderungen, Diagnose und Wiederherstellung dokumentieren.

Die Tests sollten auch relevante Fehlerfälle umfassen. Dazu kann gehören, wie sich ein nicht mehr gültiges Zertifikat oder ein nicht erreichbarer Dienst auswirkt. Die Prüfung muss kontrolliert und passend zur Produktionsumgebung erfolgen. Ein unvorbereiteter Test an einer laufenden kritischen Anlage ist kein Ersatz für eine abgestimmte Inbetriebnahme.

Fehler diagnostizieren, ohne Schutzmechanismen aufzugeben

Eine fehlgeschlagene Verbindung kann unterschiedliche Ursachen haben. Neben Erreichbarkeit und unterstützten Einstellungen kommen Zeitabweichungen, Zertifikatsgültigkeit oder fehlende Rechte infrage. Die Diagnose sollte diese Ebenen getrennt untersuchen, statt sämtliche Sicherheitsfunktionen gleichzeitig zu reduzieren.

Aktuelle Dokumentation und verständliche Meldungen helfen, Ursache und Wirkung zu unterscheiden. Wenn eine Anwendung erfolgreich verbunden ist, aber einen Wert nicht lesen darf, liegt das Problem möglicherweise bei den Rechten und nicht bei der Übertragung. Änderungen sollten entsprechend gezielt und nachvollziehbar erfolgen.

OPC UA Security ergänzt Netzwerksegmentierung und weitere Maßnahmen der OT-Security. Sie ersetzt keinen geschützten Anlagenbetrieb und keine Kontrolle anderer Zugangswege. Auch die verwendeten Implementierungen und ihre Aktualisierung bleiben relevant.

Häufige Fragen zu OPC UA Security

Ist OPC UA automatisch verschlüsselt?

Nein. Die tatsächliche Nutzung von Verschlüsselung hängt vom Kommunikationsmodell und der gewählten Konfiguration ab. Bei Client-Server-Verbindungen ist der SecurityMode zu prüfen. Zusätzlich müssen passende Verfahren auf beiden Seiten unterstützt werden. Der bloße Hinweis auf OPC UA in einer Produktbeschreibung genügt nicht als Nachweis einer verschlüsselten Verbindung.

Reicht ein vertrauenswürdiges Zertifikat für Schreibrechte?

Nein. Die Vertrauensentscheidung für eine Anwendung und die Berechtigung zu bestimmten Operationen sind getrennte Aufgaben. Ein freigegebener Client kann beispielsweise nur lesend zugreifen dürfen. Welche Daten und Methoden nutzbar sind, muss anhand des vorgesehenen Identitäts- und Berechtigungsmodells festgelegt und praktisch geprüft werden.

Sind selbstsignierte Zertifikate grundsätzlich unsicher?

Nein. Entscheidend sind unter anderem geeignete Verfahren, der Schutz privater Schlüssel und eine kontrollierte Vertrauensverwaltung. Selbstsignierte Zertifikate können bei überschaubaren Installationen eingesetzt werden. Mit wachsender Zahl von Anwendungen steigt jedoch der Verwaltungsaufwand. Die Wahl sollte sich an den betrieblichen Anforderungen und unterstützten Verwaltungsfunktionen orientieren.

Was passiert bei einem abgelaufenen Zertifikat?

Das konkrete Verhalten hängt von Anwendung und Verbindung ab; die Zertifikatsprüfung kann notwendige Verbindungen verhindern. Deshalb sollten Gültigkeit und Erneuerung rechtzeitig betreut werden. Die Lösung besteht in einem geregelten Austausch und passenden Vertrauensinformationen. Das dauerhafte Abschalten der Prüfung würde die vorgesehene Sicherheitsfunktion aufheben.

Kann eine verschlüsselte Verbindung trotzdem riskant sein?

Ja. Verschlüsselung begrenzt bestimmte Risiken bei der Übertragung, verhindert aber keine zu weitgehenden Rechte oder kompromittierten Endsysteme. Ein berechtigter Kommunikationspartner kann bei unpassender Konfiguration weiterhin unerwünschte Operationen ausführen. Deshalb müssen Nachrichtenschutz, Identitäten, Berechtigungen und der Schutz der beteiligten Systeme gemeinsam betrachtet werden.

Quellen und fachliche Einordnung

OPC Foundation: OPC 10000-2, Security Architecture, Sicherheitsmodi, Authentisierung und Autorisierung.
OPC Foundation: OPC 10000-2, Certificate Management, Zertifikate und Vertrauensverwaltung.
OPC Connect: OPC UA Security, Strengths, and Practical Implementation Considerations, Juni 2025, praktische Konfigurationsaspekte.

Das Dashboard-Beispiel und die betrieblichen Prüffragen sind eigenständige Erläuterungen. Stand: Oktober 2026.