OPC UA sicher betreiben: So gelingt Vertrauen im industriellen Maßstab
Zertifikate, Trust Lists und Verschlüsselung gibt es in OPC UA von Haus aus. Warum das allein nicht reicht – und wie sich Vertrauensbeziehungen auch in großen Anlagen skalierbar und effizient verwalten lassen.
Stellen Sie sich eine Fabrikhalle vor: Steuerungen, Sensoren, Maschinen, dazu Software, die Daten sammelt, auswertet und weiterreicht. Alle Komponenten sollen miteinander kommunizieren, möglichst herstellerunabhängig und ohne Dolmetscher. Genau dafür gibt es OPC UA (Open Platform Communications Unified Architecture). Der Standard hat sich in der Fertigungs- und Prozessindustrie als gemeinsame Sprache etabliert, und seine Bedeutung wächst weiter, je mehr Geräte und Sensoren sicher vernetzt sein müssen.
Das Schöne daran: Sicherheitsfaktoren sind von Anfang an vorhanden. Allerdings ist damit noch nicht die Frage gelöst, wie sie in den Betriebsablauf reibungslos integriert werden können. Und genau darum geht es in diesem Beitrag.
OPC UA bringt ein Sicherheitsmodell mit – aber wer pflegt es?
OPC UA stützt sich auf drei Bausteine: X.509-Zertifikate, mit denen sich Anwendungen identifizieren, kryptografisch geschützte Kommunikationskanäle und Trust Lists, die festlegen, wem eine Anwendung überhaupt vertraut. Das ist ein solides Fundament.
In der Umsetzung wird allerdings deutlich: Die Mechanismen sind da, aber um sie dauerhaft sicher und zuverlässig zu betreiben, reichen die Bordmittel nicht aus. Die Verwaltung ist eine große Herausforderung: Wie halte ich Vertrauensbeziehungen und digitale Identitäten aktuell, wenn es nicht fünf, sondern fünfhundert oder noch mehr Teilnehmer gibt?
Maschinenidentitäten: Wer spricht da eigentlich mit mir?
Im Zentrum des Sicherheitsmodells steht die eindeutige Identität einer Anwendung. Sie wird über ein Application Instance Certificate auf Basis des X.509-Standards abgebildet. Dieses Zertifikat verbindet die Anwendung mit einem kryptografischen Schlüsselpaar: Der öffentliche Schlüssel darf verteilt werden, der private muss geschützt auf dem jeweiligen System bleiben. Wer ihn verliert oder kopiert, gefährdet die Identität der Anwendung.
Die Maschinenidentität ist mehr als ein generisches Maschinenzertifikat. OPC UA verknüpft Zertifikat und Anwendung unter anderem über die ApplicationUri sowie weitere Angaben zu Anwendung und Endpunkt. Vertrauen entsteht dann über eine vertrauenswürdige Certificate Authority und die zugehörigen Trust- und Revocation-Informationen.
Damit wird das Zertifikat zu einer Non-Human Identity, die genau charakterisiert, welche Maschine, Anwendung oder Softwareinstanz tatsächlich mein Kommunikationspartner ist. Dies ist die Voraussetzung für eine sichere Kommunikation in vernetzten Systemen.
Whitepaper
»Sichere Maschinenidentitäten für IoT und OT«
Erfahren Sie mehr über Maschinenidentitäten in unserem Whitepaper.
Warum manuelle Trust-Verwaltung nicht skaliert
In kleinen OPC-UA-Umgebungen ist es üblich, selbstsignierte Zertifikate zu verwenden und sie manuell zwischen den Kommunikationspartnern auszutauschen. Das funktioniert, solange die Anlage überschaubar bleibt. Jeder Teilnehmer muss dabei die Zertifikate seiner Partner kennen und ausdrücklich als vertrauenswürdig einstufen.
Mit wachsender Zahl von Anwendungen steigt die Zahl der Vertrauensbeziehungen überproportional. Ein kleines Rechenbeispiel zur Veranschaulichung: Sollen 50 Anwendungen alle miteinander kommunizieren, muss jede die Zertifikate der 49 anderen pflegen. Das sind insgesamt 2.450 Einträge in den Trust Stores – und bei jedem erneuerten Zertifikat müssen die betroffenen Einträge wieder angepasst werden.
Die Folgen sind in vielen Anlagen bekannt:
- Hoher Administrationsaufwand, der wertvolle Zeit von OT- und IT-Teams bindet.
- Falsch gepflegte Trust Stores, in denen veraltete oder fehlende Einträge die Kommunikation stören.
- Abgelaufene Zertifikate, die im schlimmsten Fall Verbindungen unterbrechen.
- Abgeschwächte Sicherheit: Wenn der Betrieb Vorrang hat, wird die Zertifikatsprüfung abgeschwächt oder gleich ganz deaktiviert. Damit ist das Sicherheitsmodell zwar vorhanden, aber nicht mehr wirksam.
Wie entsteht eine belastbare Vertrauensarchitektur?
Diese Komplexität lässt sich allerdings deutlich reduzieren, wenn die Architektur auf einer Certificate Authority (CA) basiert. Die Teilnehmer müssen dann nicht mehr jedem einzelnen Zertifikat vertrauen, sondern nur noch einem definierten Trust Anchor. Aus einem Geflecht bilateraler Einzelbeziehungen wird so eine kontrollierbare und skalierbare PKI-Struktur, die sich zentral verwalten lässt.
Viele Unternehmen haben dafür sogar schon eine Grundlage: eine zentrale Enterprise-PKI. Sie stellt Zertifikate aus und setzt unternehmensweite Zertifikatsrichtlinien durch. Für OPC UA fehlt ihr normalerweise aber der Anwendungskontext. Eine klassische PKI weiß nicht automatisch, welche ApplicationUri zu welcher Maschine gehört, welche Anwendungen miteinander kommunizieren sollen oder welche Trust List auf einem bestimmten OPC-UA-Server erforderlich ist.
Hier fehlt die Verbindung zwischen IT-Security und OT-Welt: Die eine Seite beherrscht das Zertifikatsmanagement, die andere kennt die Anlagen und Anwendungen. Zusammen fehlt ihnen häufig noch die gemeinsame Sprache.
Weitere Artikel
Lesen Sie weitere spannende Artikel über Cybersecurity, Maschinenidentitäten und PKI .
Der Global Discovery Server als Vermittler
Genau für diese Lücke hat die OPC Foundation das Konzept des Global Discovery Servers (GDS) definiert. Er vermittelt zwischen der Fabrikhalle, also den OPC-UA-Anwendungen, und der Enterprise-PKI. Zu seinen Aufgaben gehören unter anderem:
- die Registrierung und Discovery von OPC-UA-Anwendungen,
- das Zertifikatsmanagement,
- die Verwaltung und Verteilung von Trust Lists und Revocation Lists,
- die automatisierte Zertifikatserneuerung.
Am Markt verfügbar ist zum Beispiel der OPC UA Global Discovery Server von Unified Automation (UaGDS). Er kann als zentrale Instanz für Discovery, Registrierung und Zertifikatsanforderungen fungieren.
Von der Zertifikatausstellung zum überwachten Lifecycle
Ein GDS regelt die OPC-UA-spezifischen Abläufe und kann selbst Zertifikate im begrenzten Umfang (z. B. für Testaufbauten) zur Verfügung stellen. Für ein durchgängiges, automatisiertes Lifecycle-Management von Zertifikaten, das auch Governance- und Compliance-Anforderungen erfüllt, ist aber eine vollständige PKI (Public Key Infrastructure) notwendig. Sie setzt oberhalb der OPC-UA-spezifischen Ebene an und übernimmt gemeinsam mit dem UaGDS im Hintergrund die Rolle einer Industrial-Identity- und Trust-Management-Instanz. Unternehmen können ihre Sicherheitsrichtlinien zentral definieren und konsistent über alle OPC-UA-Teilnehmer hinweg durchsetzen.
Verwendet man die ECOS TrustManagementAppliance (TMA) zur Umsetzung der PKI und als Zertifikatsmanagementsystem, erhält man ein vollständig aufeinander abgestimmtes System mit tiefer Integration.
Der Vorteil liegt im Zusammenspiel: Zertifikate werden nicht mehr isoliert betrachtet. Die TMA kann Zertifikatsstatus, Policys, Anwendungen, Trust Lists und die zugrunde liegende Auslieferungskette gemeinsam überwachen. Die Integration umfasst insbesondere erweitertes Certificate Policy Management sowie Monitoring und Reporting, außerdem die Überwachung des Trust-List-Status.
Aus der reinen Zertifikatsaustellung wird damit ein überwachter und automatisierter Lifecycle:
Discover → Deploy → Renew → Revoke
Dabei ist die Arbeitsteilung klar: Der UaGDS setzt die OPC-UA-nativen Mechanismen gegenüber den Anwendungen um, die TMA liefert die übergeordnete Steuerungs- und Transparenzebene. Der praktische Effekt: OT-Teams arbeiten weiter mit den OPC-UA-Strukturen, die sie kennen, während Security- und PKI-Verantwortliche zentrale Policys und Monitoring-Funktionen erhalten, die Governance- und Complianceanforderungen entsprechen. Niemand muss die Welt des anderen komplett übernehmen.
Praxisbeispiel: Wenn Sperrlisten zum Problem werden
Ein gutes Praxisbeispiel dafür, dass industrielles Certificate Lifecycle Management weit über klassische PKI-Administration hinausgeht, ist die Größe von Certificate Revocation Lists (CRL), also Zertifikatsperrlisten, die festhalten, welche Zertifikate nicht mehr gültig sind.
In vielen Organisationen werden im Laufe der Jahre zahlreiche Zertifikate widerrufen, etwa weil Geräte ausgetauscht oder Schlüssel kompromittiert wurden. Die CRL wächst dadurch stetig. Für IT-Systeme mit ausreichend Ressourcen ist das meist gut beherrschbar. Auf ressourcenbeschränkten Steuerungen oder Feldgeräten können große CRLs dagegen zum echten Problem werden: Sie brauchen Speicher und Rechenzeit, die dort knapp sind.
Die Integration von TMA und UaGDS berücksichtigt diesen Lifecycle-Aspekt. Neben automatisierter Erneuerung und kurzen Zertifikatslaufzeiten kann bei Bedarf eine Issuing CA ersetzt werden, wenn deren CRL einen kritischen Schwellenwert erreicht. Das Beispiel macht den Unterschied deutlich zwischen reinem Zertifikatsmanagement und einer Trust-Infrastruktur, die für industrielle Umgebungen ausgelegt ist: Es geht nicht nur um kryptografische Sicherheit, sondern ebenso um Ressourcen, Lebenszyklen, Wartungsfenster und Betriebsfähigkeit.
Fazit: Zwei Ebenen, eine Trust-Architektur
Mit dem UaGDS und der ECOS TMA bilden zwei komplementäre Ebenen eine gemeinsame Trust-Architektur:
- Der UaGDS stellt die OPC-UA-nativen Mechanismen für Registrierung, Zertifikate, Certificate Groups, Trust Lists und deren Verteilung bereit.
- Die TMA ergänzt sie um zentrale PKI-Integration, Policys, Monitoring, Reporting und übergreifendes Certificate Lifecycle Management.
Das Ergebnis ist eine zentral steuerbare Trust-Infrastruktur für Maschinenidentitäten, die sowohl Enterprise-Security-, Governance- und Compliance-Anforderungen als auch die besonderen Betriebsbedingungen industrieller OT-Umgebungen berücksichtigt.
Wie ist Ihre Anlage aufgestellt?
Dieser Beitrag basiert auf einem Fachartikel erschienen in “Computer & Automation” im September 2026.
Neugierig geworden?
Vereinbaren Sie ein kostenloses Beratungsgespräch mit uns oder abonnieren Sie unseren IT-Security-Newsletter.