OPC-UA-Authentifizierung in air-gapped Umgebungen

OPC-UA-Authentifizierung in air-gapped Umgebungen verstehen

Ein air-gapped Netz kann weder eine externe Zertifizierungsstelle erreichen noch eine Zertifikatsperrliste (CRL) aus dem Internet herunterladen. Wie betreibt man also OPC-UA mit ordentlicher Authentifizierung, wenn die gesamte Public-Key-Infrastruktur (PKI) innerhalb der Enklave liegen muss? Genau diese Herausforderung behandelt dieser Beitrag: die Umsetzung der OPC-UA-Authentifizierung in air-gapped Netzen, in denen die cloudgebundenen Muster, von denen die meiste Dokumentation ausgeht, schlicht nicht existieren.

Zunächst sollte klar sein, dass OPC-UA auf zwei getrennten Ebenen authentifiziert, und sie zu verwechseln ist die häufigste Ursache für Fehlkonfigurationen. Das Protokoll trennt die Anwendungsauthentifizierung, die das Vertrauen zwischen einem Client-Prozess und einem Server-Prozess herstellt, von der Benutzerauthentifizierung, die die Identität der Person oder des Dienstkontos hinter einer Sitzung feststellt. Beide Ebenen sind im Sicherheitsmodell der OPC Foundation definiert. Sehen Sie OPC UA Part 2: Security Model für die normative Beschreibung ihres Zusammenspiels, einschließlich des Bedrohungsmodells, für das der Standard entworfen wurde.

Ebene eins: Anwendungsauthentifizierung mit Instanzzertifikaten

Jede konforme OPC-UA-Anwendung, ob Client oder Server, besitzt ein Anwendungsinstanzzertifikat (Application Instance Certificate). Dabei handelt es sich um ein X.509-Zertifikat, das einen öffentlichen Schlüssel an eine bestimmte Software-Instanz bindet, identifiziert über ihre ApplicationUri. Wenn ein Client einen SecureChannel zu einem Server öffnet, tauschen beide Anwendungen ihre Zertifikate aus, und jede entscheidet, ob sie der anderen vertraut. Diese Entscheidung wird nicht durch Abfrage eines Online-Verzeichnisses getroffen. Sie wird lokal getroffen, gegen eine Trust-List (Vertrauensliste).

Eine Trust-List ist die auf dem Datenträger gespeicherte Menge von Zertifikaten, die eine Anwendung akzeptiert. Sie ist in zwei Speicher unterteilt. Der Vertrauensspeicher enthält entweder die Leaf-Zertifikate der Gegenstellen, denen Sie ausdrücklich vertrauen, oder die CA-Zertifikate, deren ausgestellten Zertifikaten Sie über die Kette vertrauen. Der Ausstellerspeicher enthält die Zwischen- und Stamm-CA-Zertifikate, die nur zur Vervollständigung der Kettenvalidierung benötigt werden, sowie die CRLs. Die Mechanik dieser Validierung und der Aufbau der Trust-List selbst sind in OPC UA Part 6: Mappings festgelegt, das die Dateiformate und die Validierungsschritte definiert, die ein Stack ausführen muss, bevor er einen Kanal akzeptiert.

In einer vernetzten Bereitstellung automatisiert ein Global Discovery Server (GDS) die Verteilung der Trust-Lists und die Zertifikatsregistrierung über die gesamte Anlage hinweg. In einer air-gapped Bereitstellung ist kein GDS erreichbar, sodass die Verwaltung der Trust-Lists zu einem bewussten, manuellen Vorgang wird. Das ist der zentrale architektonische Unterschied, und aus ihm folgt der Rest dieses Beitrags.

Ebene zwei: Benutzerauthentifizierung und Identitäts-Tokens

Sobald zwei Anwendungen einander vertrauen und ein SecureChannel besteht, öffnet der Client eine Session und legt ein Benutzeridentitäts-Token (user identity token) vor. OPC-UA definiert drei Token-Typen in aufsteigender Vertrauenswürdigkeit:

1. Anonym: es wird keine Benutzeridentität behauptet. Die Sitzung erbt nur die Rechte, die der Server nicht authentifizierten Aufrufern gewährt. Nur für nicht sensible Daten im Nur-Lese-Zugriff akzeptabel und in der Produktion vorzugsweise vollständig deaktiviert.
2. Benutzername/Passwort: der Client sendet einen Benutzernamen und ein Passwort, verschlüsselt mit dem öffentlichen Schlüssel des Servers. Das ist unkompliziert, übernimmt jedoch alle betrieblichen Schwächen gemeinsamer Geheimnisse: Rotation, Speicherung und das Risiko der Wiederverwendung von Anmeldedaten über Systeme hinweg.
3. X.509-Zertifikat: der Benutzer legt ein Zertifikat vor und weist den Besitz des privaten Schlüssels nach. Das liefert eine kryptografische Identität pro Benutzer, Sperrbarkeit und einen sauberen Prüfpfad, zum Preis der Verwaltung einer zweiten Zertifikatspopulation neben den Anwendungszertifikaten.

Der entscheidende Punkt für das Design in air-gapped Umgebungen ist, dass diese beiden Ebenen unabhängig sind. Sie können die Anwendungssicherheit SignAndEncrypt mit anonymen Benutzer-Tokens betreiben oder einen ungesicherten Anwendungstransport mit Benutzername-Tokens, und beides sind Fehlkonfigurationen. Starke Authentifizierung sichert beide Ebenen gemeinsam: vertrauenswürdige Anwendungszertifikate, die einen verschlüsselten Kanal aufbauen, und darauf ein nicht anonymes Benutzer-Token, das die Nachvollziehbarkeit herstellt.

Sicherheitsrichtlinien und SignAndEncrypt

Der Schutz des SecureChannel selbst wird durch den MessageSecurityMode und die gewählte SecurityPolicy bestimmt. Es gibt drei Sicherheitsmodi: None, Sign und SignAndEncrypt. None bietet keinerlei Schutz und sollte außerhalb eines Labors niemals verwendet werden. Sign gewährleistet Integrität und Authentizität, lässt die Nutzdaten jedoch auf der Leitung lesbar. SignAndEncrypt gewährleistet Integrität, Authentizität und Vertraulichkeit und ist der einzige für produktiven OT-Verkehr geeignete Modus.

Die SecurityPolicy wählt die tatsächliche kryptografische Suite. Ältere Richtlinien auf Basis von SHA-1 und RSA-15, etwa Basic128Rsa15 und Basic256, sind veraltet und sollten deaktiviert werden. Aktuelle Bereitstellungen sollten Aes256_Sha256_RsaPss verlangen oder, wo unterstützt, die ECC-basierten Richtlinien. Der vollständige Katalog der Richtlinien und ihrer kryptografischen Primitive wird in OPC UA Part 2: Security Model geführt. Server fest auf SignAndEncrypt mit einer modernen Richtlinie zu binden und None sowie die veralteten Suiten ausdrücklich abzulehnen, schließt den wichtigsten Downgrade-Pfad, den ein Angreifer andernfalls auszuloten versuchen würde.

Zertifikatsverwaltung ohne Cloud-GDS

Hier weichen air-gapped Bereitstellungen deutlich vom Lehrbuch ab. Ohne eine über das Internet erreichbare Zertifizierungsstelle und ohne einen Online-GDS muss der gesamte Lebenszyklus der Zertifikate als Offline-Arbeitsablauf gestaltet werden.

Eine Offline-Zertifizierungsstelle betreiben

Richten Sie innerhalb der Enklave eine dedizierte, offline betriebene Stamm-CA auf Hardware ein, die niemals ein externes Netz berührt. Halten Sie den Stammschlüssel offline und verwenden Sie ihn ausschließlich zum Signieren einer ausstellenden Zwischen-CA; die Zwischen-CA übernimmt die laufende Ausstellung. Dieses zweistufige Design begrenzt die Exposition des Stammschlüssels und erlaubt es, die Zwischen-CA zu sperren und neu auszustellen, ohne jeden Endpunkt neu aufzubauen. Die NIST-Empfehlungen zur Sicherheit industrieller Steuerungssysteme behandeln eine solche intern verwaltete PKI mit dokumentierter Schlüsselverwaltung als grundlegende Maßnahme für isolierte Netze. Sehen Sie NIST SP 800-82 Rev. 3, Guide to Operational Technology Security.

Trust-Lists manuell verteilen

Da kein GDS erreichbar ist, werden Trust-Lists manuell ausgespielt. Exportieren Sie das CA-Zertifikat und die Anwendungszertifikate je Endpunkt, übertragen Sie sie über die Enklave hinweg auf kontrollierten, geprüften Wechseldatenträgern gemäß Ihrem Verfahren zur Datenträgerhandhabung, und installieren Sie sie in die Vertrauens- und Ausstellerspeicher jeder Anwendung. Behandeln Sie diesen Vorgang als kontrollierte Änderung mit einer dokumentierten Bestandsliste, welches Zertifikat auf welchem Endpunkt liegt, denn diese Bestandsliste ist die einzige Karte, die Ihnen während eines Vorfalls zur Verfügung steht.

Sperrung offline lösen

CRL-Verteilungspunkte und OCSP-Responder setzen beide eine erreichbare Infrastruktur voraus, sodass keiner von beiden über eine Enklave hinweg standardmäßig funktioniert. Sie haben zwei realistische Optionen. Entweder erzeugen Sie die CRLs auf der Offline-CA und verteilen sie im selben kontrollierten Takt wie die Trust-Lists, wobei die Sperrlatenz Ihrem Verteilungsintervall entspricht, oder Sie behandeln, für die robusteste Haltung, die Trust-List selbst als maßgebliche Instanz: ein kompromittiertes Zertifikat wird direkt aus jedem Vertrauensspeicher entfernt. Sowohl NIST SP 800-82 als auch die umfassenderen Empfehlungen des NIST SP 800-57 zur Schlüsselverwaltung betonen, dass ein Sperrprozess existieren und getestet sein muss, nicht nur entworfen, bevor man sich auf die PKI verlässt.

Erneuerung um Wartungsfenster planen

Zertifikate laufen ab, und ein abgelaufenes Anwendungszertifikat unterbricht stillschweigend einen SecureChannel. Verfolgen Sie das Gültigkeitsfenster jedes Zertifikats zentral, planen Sie die Rotation vor dem Ablauf, und üben Sie die Rotation während eines geplanten Wartungsfensters ein, statt die Abhängigkeit im laufenden Betrieb zu entdecken. Die Offline-Erneuerung ist ein manueller Zyklus aus Neuausstellung und Neuverteilung, daher muss im Wartungskalender Vorlaufzeit eingeplant werden.

Die Ebenen zusammenführen

Eine verteidigungsfähige air-gapped OPC-UA-Bereitstellung sieht in der Praxis so aus. Server verlangen den MessageSecurityMode SignAndEncrypt mit einer modernen SecurityPolicy und lehnen alles Schwächere ab. Anwendungsinstanzzertifikate werden von der Offline-Zwischen-CA ausgestellt und sind auf beiden Seiten vorhanden, mit Trust-Lists, die nur die Zertifikate enthalten, die dort hingehören. Das anonyme Benutzer-Token ist deaktiviert, und Sitzungen authentifizieren sich per Benutzername oder, vorzugsweise, per X.509-Benutzerzertifikat, sodass jede Aktion einer Identität zugeordnet ist. Sperrung und Erneuerung laufen in einem dokumentierten Offline-Takt, gestützt auf einen getesteten Prozess.

Häufige Herausforderungen meistern

Altsysteme

Ältere Endpunkte unterstützen mitunter nur veraltete Richtlinien oder gar keine Nachrichtensicherheit. Statt die gesamte Anlage zu schwächen, um sie aufzunehmen, stellen Sie diese Geräte hinter ein Gateway, das stellvertretend einen sicheren Kanal terminiert, oder in eine eng begrenzte Enklave, die einschränkt, wer sie erreichen kann. Ziel ist es, das schwache Glied einzudämmen, nicht das Niveau für alles andere abzusenken.

Konformität und Normen

Eine intern verwaltete PKI, eine dokumentierte Schlüsselverwaltung und ein getesteter Sperrprozess entsprechen unmittelbar den Kontrollen, die Rahmenwerke wie NIS2 und CMMC erwarten, sowie den OT-spezifischen Empfehlungen aus NIST SP 800-82. Den Offline-Lebenszyklus bewusst zu gestalten, ist auch das, was später ein sauberes Audit möglich macht.

Schulung und Sensibilisierung

Die manuelle Verteilung von Trust-Lists und die Offline-Erneuerung sind Verfahren, und Verfahren scheitern, wenn die ausführenden Personen nicht verstehen, warum jeder Schritt existiert. Investieren Sie in die Runbooks und die zugehörige Schulung, denn in einer air-gapped PKI ist der menschliche Prozess die Kontrolle.

Fazit

Die zentrale Erkenntnis: in air-gapped Umgebungen sind Ihre Offline-Zertifizierungsstelle und die Disziplin Ihrer manuellen Trust-List-Verteilung die kritischsten Sicherheitskomponenten. Beherrschen Sie die Schlüsselverwaltung der Offline-CA, das Verteilungsverfahren der Trust-Lists, den Sperrpfad und den Erneuerungsplan, bevor Sie die OPC-UA-Authentifizierung in der gesamten Anlage ausrollen. Binden Sie jeden Server fest an SignAndEncrypt mit einer modernen Richtlinie, deaktivieren Sie den anonymen Zugriff und authentifizieren Sie Benutzer per Zertifikat, wo immer es möglich ist. Testen Sie die Zertifikatsrotation während eines Wartungsfensters, nicht im laufenden Betrieb. Sobald die Offline-PKI solide ist, ist das integrierte Sicherheitsmodell von OPC-UA ohne jede Internetverbindung vollständig nutzbar.