SSH ist das Protokoll für eine sichere Remote-Shell und Dateiübertragung. Es läuft auf einer breiten Palette von Geräten, von Servern und Netzwerktechnik bis zu den Gateways und eingebetteten Controllern, die in OT-Umgebungen üblich sind (in diesem Beispiel ein MOXA-Gateway). Der Kanal ist bereits Ende zu Ende verschlüsselt, daher ist das Problem, das SSH in einem OT-Netzwerk darstellt, selten die Vertraulichkeit. Es sind zwei andere Dinge: flache Erreichbarkeit (alles im LAN kann an Port 22 anklopfen) und die Ausbreitung von Anmeldeinformationen (Geräte, die mit einem einzigen geteilten Schlüssel oder Passwort gesichert sind, das sich schwer rotieren lässt). Access Gate begegnet beidem und bietet zwei unterschiedliche Wege, dies zu tun.
Wie SSH-Sicherheit tatsächlich funktioniert
In jeder SSH-Session sind drei Dinge im Spiel, und sie versagen unabhängig voneinander:
- Host-Key (Identität des Servers). Bei der ersten Verbindung speichert der Client den Host-Key des Servers. Das ist es, was einen Man-in-the-Middle verhindert, und es ist auch das, was die Warnung "der Host-Key hat sich geändert" erzeugt, die Operatoren gewohnt sind wegzuklicken. Das Gate gibt Ihnen, indem es die Session vermittelt, eine einzige konsistente Identität zur Überprüfung statt eines Schlüssels pro Gerät.
- Benutzerauthentifizierung. Der Benutzer weist seine Identität mit einem SSH-Schlüssel (bevorzugt) oder einem Passwort (schwächer, phishbar, oft geteilt) nach. Bei OT-Geräten ist dies häufig eine einzige geteilte Anmeldeinformation, die in einem Runbook hinterlegt ist.
- Verschlüsselter Kanal. Wird automatisch ausgehandelt. Dieser Teil ist bereits solide, weshalb sich die SSH-Sicherheitsarbeit um die ersten beiden Punkte dreht, nicht um die Verschlüsselung.
Das Fazit: SSH braucht keine Hilfe beim Verschlüsseln. Es braucht Hilfe dabei, wer den Port erreichen kann und wer die Anmeldeinformation hält. Die beiden Zugriffsmodelle unten unterscheiden sich genau bei dieser zweiten Frage.
Zwei Wege, SSH zu vermitteln (wählen Sie einen)
Modell A: Berechtigung über den Netzwerkpfad
Das standardmäßige Default-deny-Enklavenmodell. Sie schreiben eine allow-Regel für das ssh-Protokoll (Port 22) von einem Principal zum Asset, und der Operator verbindet sich mit seinem eigenen SSH-Client und Schlüssel. Das Gate setzt Identität und Richtlinie durch und protokolliert die Session, aber die SSH-Anmeldeinformation bleibt zwischen dem Operator und dem Gerät.
- Fügen Sie das Gerät als Asset hinzu und platzieren Sie es in einer Enklave, siehe Ein Asset mit Enklaven schützen.
- Fügen Sie eine
allow-Regel fürsshhinzu (odertcp:{custom_port}, falls SSH nicht auf 22 läuft), beschränkt auf den Benutzer, die Gruppe oder das Peer-Asset, das sich verbinden soll. - Der Operator führt
ssh user@<overlay-name-or-ip>aus. Am Gerät ändert sich nichts.
Verwenden Sie Modell A, wenn Operatoren vertrauenswürdig genug sind, ihre eigenen Schlüssel zu verwalten, wenn ein Machine-to-Machine-Fluss SSH benötigt (ein Automatisierungs-Host, der einen Controller erreicht), oder wenn Sie den schlanksten Weg wünschen, der dennoch Default-deny und Protokollierung bietet. Die Einschränkung: Die Geräte-Anmeldeinformation ist immer noch in Umlauf, sodass der Widerruf des Zugriffs bedeutet, die Berechtigung zu widerrufen und schließlich den Schlüssel zu rotieren.
Modell B: Remote-Access-Proxy
Wenn die Anmeldeinformation des Geräts das Gate nie verlassen soll, verwenden Sie Remote Access: Das Gate speichert den SSH-Schlüssel oder das Passwort, injiziert es beim Login und stellt die Session in einem Browser-Tab bereit. Der Operator authentifiziert sich als er selbst und hält nie die Geräte-Anmeldeinformation.
1. Das Asset und seinen SSH-Dienst erstellen
Fügen Sie das Gerät als Asset hinzu und deklarieren Sie seinen SSH:22-Dienst. Öffnen Sie das Asset, klicken Sie auf Edit Network und geben Sie die Informationen zum Remote-Access-Dienst ein (die Anmeldedaten, die Access Gate beim Login verwendet).
2. Eine Enklave erstellen
Erstellen Sie eine Enklave, die das Asset und den Benutzer oder die Gruppe enthält, der Sie Zugriff gewähren möchten.
3. Remote Access auf der Berechtigung aktivieren
Um Remote Access zu gewähren, eine Proxy-Session, die Access Gate aufrechterhält, wählen Sie die Option Remote Access. Mit dieser Option werden die auf dem Access Gate gespeicherten Anmeldedaten beim Login verwendet, ohne dem Endbenutzer offengelegt zu werden. Gewähren Sie dann den Zugriff.
Auf der Benutzerseite
Der Benutzer authentifiziert sich über einen Access Screen und sieht die Remote-Access-Sessions, die er aktivieren kann.
Ein Klick auf den Link öffnet eine Browser-Session mit Remote Access zur Zielmaschine.
Die Anmeldedaten liegen nicht auf der Maschine des Operators. Die Berechtigung (creds=...) wird serverseitig injiziert, sodass die Person an der Tastatur nie den SSH-Schlüssel oder das Passwort für die MOXA-Box besitzt. Den Zugriff zu widerrufen bedeutet, eine Berechtigung zu widerrufen, nicht eine Geräte-Anmeldeinformation zu rotieren. Für das umfassendere Admin-Session-Modell (RDP, VNC, Session-Aufzeichnung) siehe Privileged Access Management.
Hinweise zur Härtung
- Bevorzugen Sie Schlüssel gegenüber Passwörtern und deaktivieren Sie am Gerät die Passwortauthentifizierung, sobald der Schlüsselzugriff erprobt ist. Bei Modell B ist dies für den Operator unerheblich, das Gate hält die Anmeldeinformation.
- SFTP und SCP nutzen dieselbe Berechtigung. Dateiübertragung ist SSH, daher regelt dieselbe Regel, die den Shell gewährt, auch die Dateibewegung. Grenzen Sie sie bewusst ein, wenn ein Operator einen Shell, aber kein massenhaftes Kopieren von Dateien erhalten soll.
- Der Widerruf unterscheidet sich je nach Modell. Der Widerruf bei Modell A ist auf Netzwerkebene sofort wirksam, aber der Geräteschlüssel besteht weiter, bis er rotiert wird. Der Widerruf bei Modell B entfernt in einem einzigen Schritt den einzigen Pfad zur Anmeldeinformation.
Zusammenfassung
Sie haben zwei Wege, SSH zu vermitteln: eine Berechtigung über den Netzwerkpfad (Modell A), bei der der Operator seinen eigenen Schlüssel besitzt und das Gate Erreichbarkeit und Protokollierung durchsetzt, oder ein Remote-Access-Proxy (Modell B), bei dem das Gate die Anmeldeinformation hält und eine Browser-Session bereitstellt, sodass der Operator nie den Geräteschlüssel berührt. Beide laufen auf Default-deny-Enklaven, und keiner erfordert eine Änderung am Gerät.
Greifen Sie zu Modell A, wenn Operatoren ihre eigenen Schlüssel verwalten oder für Machine-to-Machine-SSH; greifen Sie zu Modell B, wenn eine geteilte oder nicht rotierbare Anmeldeinformation das Gate nie verlassen darf.