OPC UA ist das Protokoll, mit dem industrielle Geräte mit Software kommunizieren, und so wie das Feld es betreibt, ist es fast immer erreichbar, im Klartext und ohne Authentifizierung. Access Gate stellt Identität, Richtlinie und Verschlüsselung vor einen OPC-UA-Server, ohne den Server oder den Client zu ändern. Diese Seite erklärt das Protokoll kurz und führt dann durch einen End-to-End-Leitfaden, der einen exponierten Server nimmt und ihn absichert.
Überblick über OPC UA
OPC UA (Open Platform Communications Unified Architecture) ist das Standardprotokoll, mit dem industrielle Geräte mit Software kommunizieren. Eine SPS, die eine Pumpe steuert, ein Sensor, der einen Tankfüllstand liest, ein Motorantrieb, ein SCADA-System, ein Historian: All das spricht OPC UA, um Daten auszutauschen. Es ist die Lingua franca der Werkshalle, von Wasserwerken, Energieanlagen und OT-Umgebungen im Allgemeinen.
Ein Server, in der Regel auf oder nahe der Anlage (etwa eine KEPServerEX-Instanz), stellt einen Adressraum bereit: einen Baum von Knoten, die reale Werte darstellen. Jeder Tag, etwa Motor1.RPM oder Tank1.Level_pct, ist ein Knoten, den Sie lesen und oft schreiben können. Clients (Engineering-Laptops, SCADA, Dashboards) verbinden sich über TCP, üblicherweise auf Port 4840, um diese Werte zu lesen, Live-Änderungen zu abonnieren oder neue Sollwerte zu schreiben.
Wie OPC UA Datenverkehr verschlüsselt und worin sich seine zwei Sicherheitsmechanismen unterscheiden, lesen Sie unter Die Rolle von TLS bei der Absicherung von OPC UA.
End-to-End-Leitfaden: einen ungesicherten OPC-UA-Server absichern
Dies ist eine stufenweise Demonstration, die einen ungesicherten OPC-UA-Server (KEPServerEX, SecurityPolicy=None, anonym) nimmt und zeigt, wie Access Gate ihn schützt, ohne den Legacy-Server oder -Client zu berühren. Sie läuft in zwei festen Akten ab und verzweigt sich dann in einen von drei Wegen in Akt 3, je nachdem, was Client und Gate unterstützen.
Im gesamten Beispiel verwendete Endpunkte und Tags:
EP_DIRECT = opc.tcp://172.31.144.41:4840/kepware/ (roher Server, Underlay)
EP_GATE = opc.tcp://kepware.bluelab.ts-sec.net:4840/kepware/ (über die Enklave, per Name)
RPM = ns=2;i=2 Motor1.RPM
TEMP = ns=2;i=3 Motor1.Temp_C
TANK = ns=2;i=4 Tank1.Level_pct
ROOT_CA = ~/Downloads/troutzt_root.cert (Trout-Access-Gate-Root)
Akt 1: die Exposition (Underlay, kein Schutz)
Der Server, wie das Feld ihn betreibt: erreichbar, im Klartext, anonym, beschreibbar.
export EP="opc.tcp://172.31.144.41:4840/kepware/"
echo ">>> Server ohne Anmeldedaten durchsuchen"
uabrowse -u "$EP" -v ERROR
echo ">>> Einen Live-Sollwert lesen"
uaread -u "$EP" -n "ns=2;i=4" -v ERROR
echo ">>> Einen neuen Wert ohne Authentifizierung schreiben"
uawrite -u "$EP" -n "ns=2;i=4" 50.0 -v ERROR
uaread -u "$EP" -n "ns=2;i=4" -v ERROR
Jeder, der Port 4840 erreichen kann, liest jeden Wert und verschiebt Sollwerte. Kein Benutzername, kein Zertifikat. Das Protokoll unterstützt Sicherheit; sie ist nur nicht eingeschaltet.
Akt 2: die Enklave erstellen (Overlay)
Bringen Sie den Server in eine Access-Gate-Enklave, sodass er nur über das Overlay erreichbar ist, per Name, für eine autorisierte Identität. Der Legacy-Server bleibt unverändert.
export EPG="opc.tcp://kepware.bluelab.ts-sec.net:4840/kepware/"
echo ">>> Derselbe Server, jetzt über die Enklave per Name erreicht"
uaread -u "$EPG" -n "ns=2;i=2" -v ERROR
uabrowse -u "$EPG" -v ERROR
Nichts an der SPS oder am Server hat sich geändert. Der Server sitzt nun hinter dem Gate, erreichbar über das Overlay statt im flachen Netz. Der Zugriff wird über eine Identität gesteuert und protokolliert.
Akt 3: den Kanal absichern (EINEN Weg wählen)
Die drei Wege unten schließen sich gegenseitig aus. Ein gegebener Client nutzt genau einen, je nachdem, was Client und Gate unterstützen. Entscheiden Sie vorab und führen Sie nur diesen Weg aus.
Weg A: TLS-Tunnel (Client spricht TLS, PQC zeigen)
Verwenden Sie ihn, wenn der Client TLS zum Gate terminieren kann oder Sie einen lokalen TLS-Terminator auf dem Client-Rechner platzieren, sodass das Klartext-Segment den Host nie verlässt.
Prüfen Sie den TLS-Endpunkt des Gate:
openssl s_client -connect kepware.bluelab.ts-sec.net:4840 \
-servername kepware.bluelab.ts-sec.net \
-CAfile ~/Downloads/troutzt_root.cert </dev/null 2>&1 | \
grep -E "Verify return code|Negotiated TLS|Protocol|issuer="
Der Kanal zum Gate ist TLS 1.3 mit Post-Quanten-Schlüsselaustausch (ML-KEM-768), gegen unsere eigene PKI verifiziert, vor einer SPS, die nichts davon spricht. Wie das Gate Zertifikate bereitstellt, Cipher Suites aushandelt und eine „Nur TLS"-Richtlinie erzwingt, lesen Sie unter TLS-Verschlüsselung einrichten. OPC UA definiert im Standard auch eigene TLS-basierte Mappings (opc.https und opc.wss); siehe Die Rolle von TLS bei der Absicherung von OPC UA für den Vergleich.
Wann Weg A: Die Post-Quanten-TLS-Geschichte ist das Aushängeschild, und Sie akzeptieren einen lokalen Terminator (oder haben einen wirklich TLS-fähigen Client).
Weg B: OPC-UA-Nachrichtensicherheit
Verwenden Sie ihn, wenn sich jeder beliebige Standard-OPC-UA-Client sicher verbinden soll, unverändert und ohne Terminator. Hier findet die Verschlüsselung auf der OPC-UA-Nachrichtenebene statt statt in einem TLS-Tunnel, und Access Gate liefert die DNS-Konnektivität, die ACL-Kontrollen und die Protokollierung darum herum.
OPC-UA-Nachrichtensicherheit läuft innerhalb des SecureChannel des Protokolls. Um sie einzuschalten, setzen Sie beide Endpunkte auf eine aktuelle Sicherheitsrichtlinie und einen Nachrichten-Sicherheitsmodus:
- Sicherheitsrichtlinie:
Basic256Sha256(oder eine neuereAes*-Richtlinie, wenn beide Seiten sie unterstützen). Vermeiden Sie die veralteten RichtlinienBasic128Rsa15undBasic256. - Nachrichten-Sicherheitsmodus:
SignAndEncrypt.Signallein belegt die Integrität, lässt die Nutzlast aber lesbar; nurSignAndEncryptbringt Vertraulichkeit. - Zertifikate: Client und Server tauschen X.509-Anwendungsinstanzzertifikate aus und prüfen jeweils das des Gegenübers gegen ihre Trust-Liste, sodass der Kanal beidseitig authentifiziert ist. Vertrauen Sie dem Zertifikat des Gate auf dem Client und dem Zertifikat des Clients auf dem Gate.
Die Verschlüsselung beruht hier auf RSA und AES gemäß der gewählten SecurityPolicy-Suite, standardnativ und beidseitig authentifiziert, nicht auf der Post-Quanten-TLS-Suite aus Weg A.
Wann Weg B: Ihr Server und Ihr Client unterstützen OPC-UA-Nachrichtensicherheit und nicht TLS, und Sie wollen einen standardnativen, beidseitig authentifizierten Kanal ohne Terminator.
Weg C: Klartext-Tunnel über das Gate (Fallback)
Verwenden Sie ihn, wenn der Client kein TLS kann und Client und Server keinen OPC-UA-SecureChannel terminieren können. Das Gate trägt die Session. Der Client spricht Klartext-opc.tcp zum Enklaven-Endpunkt, unverändert.
Selbst ohne jegliche Kryptografie auf Client-Seite oder auf der Nachrichtenebene ist der Server nicht mehr im offenen Netz. Ihn zu erreichen erfordert, eine autorisierte Identität im Overlay zu sein, und jede Session wird gesteuert und protokolliert. Das ist die Mindesthaltung: Zugriffskontrolle und Audit über die Enklave, ohne den Legacy-Client oder -Server zu ändern.
Zusammenfassung
Sie haben einen exponierten OPC-UA-Server genommen, ihn in eine Enklave gebracht, sodass er nur von einer autorisierten Identität über das Overlay erreichbar ist, und dann den Kanal mit einer von drei Optionen abgesichert: einem Post-Quanten-TLS-Tunnel (Weg A), standardnativer OPC-UA-Nachrichtensicherheit (Weg B) oder einem kontrollierten Klartext-Tunnel, der dennoch Zugriffskontrolle und Audit liefert (Weg C). Der Legacy-Server und -Client wurden nie verändert.
Greifen Sie dazu, wenn ein OPC-UA-Server im Netz erreichbar, im Klartext und anonym ist und Sie Identität, Verschlüsselung und Protokollierung davorstellen müssen, ohne die Anlage zu berühren.