Secrets und Zugangsdaten im OPC Router
Diese Seite fasst zusammen, wo Zugangsdaten und Zertifikate im OPC Router liegen, wie sie geschützt sind und welche Anknüpfungspunkte eine eigene Schlüsselverwaltung hat. Sie richtet sich an IT-Sicherheit und Betrieb und führt die Einzelheiten aus den verlinkten Seiten zu einer Risikobetrachtung zusammen.
Gilt für OPC Router 5.7 und neuer.
Grundprinzip: Geheimnisse sind von der Projektierung getrennt
Zugangsdaten sind im OPC Router keine Felder in der Projektierung, sondern eigenständige Secrets in einem Secret-Store. Die Projektierung verweist nur auf einen Key; der Wert selbst liegt an anderer Stelle. Das hat eine praktische Folge: Der Ort, an dem ein Geheimnis liegt, ist auswechselbar – und er kann vollständig außerhalb des Produkts liegen. Ein Projekt lässt sich damit weitergeben, sichern und zwischen Umgebungen bewegen, ohne dass die Zugangsdaten mitwandern.
Ablage der Zugangsdaten
| Store | Wo | Vom Produkt beschreibbar |
|---|---|---|
internal | Datei im Konfigurationsverzeichnis – unter Windows standardmäßig C:\ProgramData\inray\OPC Router 5\config, im Container unter /data/config | Ja – angelegt und gepflegt über das Web Management |
env | Umgebungsvariablen des Dienstprozesses | Nein – die Quelle ist schreibgeschützt |
Werte im internal-Store legt der OPC Router verschlüsselt ab, siehe Ablage und Verschlüsselung. Entscheidend für die Risikobetrachtung ist dennoch die Ebene darunter: Die Schutzwirkung dieses Stores steht und fällt mit den Zugriffsrechten auf das Konfigurationsverzeichnis.
Behandeln Sie das Konfigurationsverzeichnis wie Geheimnismaterial und beschränken Sie den Zugriff auf das Dienstkonto – es ist die Schutzgrenze, die Sie selbst in der Hand haben.
Eigene Schlüsselverwaltung anbinden
Betreiben Sie einen Secret-Manager – etwa HashiCorp Vault, Kubernetes Secrets, Docker Secrets, systemd-Credentials oder einen Cloud-Tresor –, dann ist der env-Store der dafür gebaute Anschluss: Sie geben den Wert als Umgebungsvariable des Dienstprozesses vor, der OPC Router liest ihn und schreibt ihn nie zurück. Rotation, Auditierung und Zugriffskontrolle bleiben damit vollständig in Ihrer Verwaltung. Wie Umgebungsvariablen in den Container gelangen, steht unter Konfigurierbare Umgebungsvariablen.
Ändert sich der Wert einer Umgebungsvariable am System oder Container, übernimmt der laufende OPC Router ihn nicht automatisch – erst ein Neustart der Dienste liest den neuen Wert ein, siehe Stores.
Zertifikate und private Schlüssel
Zertifikate für die OPC-UA-Kommunikation verwalten Sie über die Zertifikatsverwaltung: eigene Zertifikate, mit denen sich der OPC Router ausweist, und vertrauenswürdige Zertifikate der Gegenstellen. Auf Dateisystemebene liegen sie im Konfigurationsverzeichnis, in getrennten Beständen für eigene Schlüsselpaare, vertrauenswürdige Gegenstellen und Ausstellerzertifikate. Über OPC UA GDS lassen sich Zertifikate zusätzlich automatisch von einem Global Discovery Server beziehen und erneuern (Enterprise-Lizenz erforderlich).
Die eigenen Schlüsselpaare sind Softwareschlüssel im Dateisystem und tragen keinen eigenen Passwortschutz. Ihr Schutz ist der Schutz des Konfigurationsverzeichnisses: Wer es lesen kann, kann sich gegenüber OPC-UA-Gegenstellen als dieser Router ausweisen. Behandeln Sie es deshalb mit derselben Schutzklasse wie Zugangsdaten selbst, einschließlich Sicherungen und Zugriffsprotokollierung.
Eine Bindung des privaten Schlüssels an Hardware – TPM, Smartcard oder einen Schlüsseltresor – steht für die Kommunikationszertifikate des Routers derzeit nicht zur Verfügung.
Anmeldung am Web Management
Die Benutzerverwaltung des Web Managements ist von den Projektgeheimnissen vollständig getrennt und baut auf der Identitätsverwaltung von ASP.NET Core auf.
| Mechanismus | Umsetzung |
|---|---|
| Passwortablage | Kein Passwort wird gespeichert, nur ein Ableitungswert: PBKDF2 mit HMAC-SHA512, 210.000 Iterationen, 128-Bit-Salt je Konto |
| Kontosperre | Nach mehreren Fehlversuchen aktiv, für einen Zeitraum gesperrt |
| Zweiter Faktor | Für lokale Konten steht kein zweiter Faktor bereit. Der Weg dorthin ist die Föderation: Die Mehrfaktor-Vorgabe Ihres Identity Providers greift dann für alle föderierten Anmeldungen |
| Föderation | Microsoft Entra ID sowie Windows-Authentifizierung, siehe Anmeldeoptionen |
| Sitzung | Inaktivitäts-Zeitgrenze zentral konfigurierbar, Gültigkeitsdauer pro Benutzer übersteuerbar, siehe Automatischer Logout |
| Berechtigung | Rollenbasiert über die Benutzerrollen |
Föderieren Sie die Anmeldung an Entra ID. Dann gelten Ihre Passwortrichtlinie, Ihre Mehrfaktor-Vorgaben und Ihr Konten-Lebenszyklus, und der Router hält für diese Konten kein Passwortmaterial. Begrenzen Sie lokale Konten auf einen Notzugang und überwachen Sie dessen Verwendung.
Weitergabe: Sicherung, Export, Redundanz
An drei Stellen können Geheimnisse das System verlassen.
Projektsicherung und Export
Ob Authentifizierungsdaten in die automatische Projektsicherung aufgenommen werden, legen Sie über die Option „Authentifizierungsdaten in Projektsicherung einschließen“ in den Grundeinstellungen fest. Beim Projekt-Export schreibt der OPC Router die Werte referenzierter Secrets nur, wenn Sie das auswählen, wahlweise mit Kennwort verschlüsselt.
Ohne Kennwort bzw. Passphrase stehen die Werte in der Sicherungs- oder Exportdatei im Klartext, siehe Secrets beim Export und Import. Vergeben Sie eines, sobald eine solche Datei den Rechner verlässt, weitergegeben oder abgelegt wird, und behandeln Sie die Datei anschließend wie Geheimnismaterial.
Redundanzabgleich
Primär- und Sekundärsystem authentifizieren sich beim Abgleich über einen Pre-Shared-Key, der wie jedes andere Secret im internal-Store liegt – mit denselben Regeln für Ändern, Löschen, Export und Versionierung. Details stehen unter Gesicherte Redundanz.
Empfohlene Betriebsmaßnahmen
In der Reihenfolge ihrer Wirkung. Die erste Maßnahme hat den größten Hebel: Sie nimmt das Geheimnis aus dem Produkt heraus.
- Zugangsdaten aus einem eigenen Secret-Manager einspeisen – über den
env-Store statt über deninternal-Store. Rotation, Auditierung und Zugriffskontrolle bleiben vollständig in Ihrer Verwaltung. - Konfigurationsverzeichnis härten – Zugriff auf das Dienstkonto und die Administration beschränken, auf Datei- und auf Volume-Ebene. Es wie Geheimnismaterial klassifizieren, auch in der Sicherungsstrategie.
- Zertifikatsverzeichnis wie Zugangsdaten schützen – es enthält die private Identität der Anlage, ohne eigenen Passwortschutz. Zugriff auf das Dienstkonto beschränken, Leseereignisse protokollieren und den Bestand in die Rotationsplanung für Zertifikate aufnehmen.
- Anmeldung über Entra ID – damit Ihre Passwort- und Mehrfaktor-Richtlinie greift. Lokale Konten auf einen Zugang für den Notfall begrenzen.
- Sicherungen und Exporte nur mit Kennwort bzw. Passphrase erzeugen – und die Dateien anschließend mit derselben Schutzklasse behandeln wie die Geheimnisse selbst.
- Protokollstufe im Betrieb nicht auf Debug – Diagnosestufen erzeugen ausführliche Protokolle. Behandeln Sie Protokoll- und Diagnosedateien als potenziell geheimnistragend und beschränken Sie den Zugriff darauf, siehe Logdateien und das Ereignisprotokoll.