Privileged Access Management in Access Gate ist ein browserbasiertes Remote Access Scheme: Ein DBA, Integrator oder Support-Ingenieur öffnet eine URL, authentifiziert sich und erhält eine proxied Session zu einem bestimmten System. Kein VPN-Tunnel, keine dauerhaften Anmeldedaten, keine vorab verteilten SSH-Schlüssel. Jede Session ist an eine namentlich bekannte Person gebunden, zeitlich begrenzt und wird aufgezeichnet.
Was das Remote Access Scheme abdeckt
Das Schema leitet Admin-Protokolle über Access Gate weiter, sodass das Client-Gerät das Zielnetzwerk nie direkt berührt:
| Protokoll | Typisches Ziel | Client-Oberfläche |
|---|---|---|
| RDP | Windows-Server, Engineering-Workstations | Browser, HTML5-Renderer |
| SSH | Linux/Unix-Hosts, Netzwerk-Appliances, Jump-Hosts | Browser, Terminal im Browser |
| VNC | HMI-Panels, Legacy-Workstations | Browser, HTML5-Renderer |
| HTTPS | Admin-Web-UIs, Historians, BMS-Dashboards | Browser, iframe / Weiterleitung |
Das Zielsystem sieht eine Verbindung von Access Gate. Der Benutzer sieht einen Browser-Tab. Beide teilen sich nie einen IP-Pfad.
Warum proxied Sessions für OT und hybride Netzwerke wichtig sind
| Veralteter Ansatz | Entstehende Probleme | Antwort durch proxied Sessions |
|---|---|---|
| Gemeinsame Admin-Konten | Keine Zuordnung von Identität zu Aktion bei Untersuchungen | Jede Aktion ist einem IdP-Benutzer zugeordnet |
| Verteilte SSH-Schlüssel | Schlüssel-Wildwuchs, keine Widerrufsmöglichkeit | Keine Schlüssel verlassen Access Gate |
| Jump-Host mit VPN | Ein Satz Anmeldedaten, großer Wirkungsradius | Pro-Enklave-, pro-Protokoll-Scope |
| Screen-Sharing für Anbieter | Kein Audit-Protokoll | Vollständiges Session-Log + Zeitstrahl |
Wie die Benutzererfahrung aussieht
- Der Benutzer öffnet eine URL, die Sie veröffentlichen (zum Beispiel
acme.tr-sec.net/connect). - Er authentifiziert sich über Ihren Identity Provider (OIDC oder SAML) oder über einen temporären Benutzer, der in Access Gate erstellt wurde.
- Access Gate listet nur die Systeme auf, die seine Rolle erreichen darf, pro Enklave.
- Er klickt auf ein System; der Browser öffnet eine RDP-, SSH-, VNC- oder HTTPS-Session dazu.
- Am Session-Ende (expliziter Logout, Timeout oder vom Operator ausgelöstes Session-Ende) wird die Verbindung getrennt.
Keine Client-Software. Keine Anmeldedaten an den Remote-Benutzer weitergegeben. Kein privater Zugang ins Netzwerk.
PAM-Kontrollen
Bei Sessions mit hohem Risiko ergänzt derselbe Weg standardmäßige PAM-Verhaltensweisen:
- Identitätsgebundene Sessions: Jede Aktion wird einer namentlich bekannten Person zugeordnet, nie einem gemeinsamen Konto.
- Just-in-Time-Zugriff: Gewähren Sie eine Rolle für ein definiertes Zeitfenster; sie wird automatisch widerrufen.
- Session-Ablauf: Idle-Timeout und maximale Session-Dauer, pro Enklave konfigurierbar.
- Operator-Session-Ende: Jede aktive Session kann über die Admin-UI beendet werden.
- Vollständiger Audit-Trail: Verbindung, Ziel, Principal, Protokolle und Ergebnis landen in der Enklave-Änderungshistorie und der Log-Pipeline.
Einrichtung
1. Remote Access Scheme für Ihr Asset konfigurieren
- Navigieren Sie zu Assets → [Ihr Asset] →
- Klicken Sie auf das Stift-Symbol und dann auf Edit network.
- Geben Sie das Remote Access Scheme und die Anmeldeinformationen an.
- Speichern.
Die Informationen werden in Access Gate gespeichert und im Ruhezustand sowie bei der Übertragung verschlüsselt. Sie müssen keine Anmeldedaten für den Zugriff auf ein bestimmtes System weitergeben.
2. Remote Access Scheme auf einer Enklave aktivieren
- Navigieren Sie zu Enclaves → [Ihre Enklave] → dem Flow, den Sie mit PAM absichern möchten.
- Schalten Sie Remote Access Scheme ein.
- Speichern.
Nur die hier ausgewählten Protokolle sind über den Proxy erreichbar. Die anderen Ports des Zielsystems bleiben innerhalb einer Session unsichtbar.
3. Just-in-Time-Zugriff gewähren (optional)
- Wählen Sie eine Access Agreement aus, die den Besucher authentifiziert.
- Dieser Access Screen ist so konfiguriert, dass er Zugriff für einen bestimmten Zeitraum gewährt und ein bestimmtes Directory verwendet.
- Speichern.
Zum Ablaufzeitpunkt wird der Eintrag automatisch deaktiviert; kein Eingriff des Operators erforderlich.
Wann diese Methode vs. Remote ZT Access verwenden
| Szenario | Verwenden Sie |
|---|---|
| Remote-Ingenieur benötigt HTTPS/Modbus/OPC zu einer Gruppe von Enklave-Systemen | Remote Zero Trust Access |
| Anbieter benötigt einmaligen RDP auf einen Windows-Server | Privileged Access Management (diese Seite) |
| SSH auf einer industriellen Appliance zur Fehlersuche | SSH-Fernzugriff konfigurieren |
| Alltäglicher Anwendungsverkehr von einem Remote-Laptop | Remote Zero Trust Access |
Beide Flows koexistieren, und Sie können beide auf derselben Enklave aktivieren und die Rolle des jeweiligen Benutzers entscheiden lassen, welchen er tatsächlich erhält.
Zusammenfassung
Wir haben ein browserbasiertes Remote Access Scheme konfiguriert, das RDP, SSH, VNC und HTTPS zu einem Ziel proxyt, mit identitätsgebundenen, zeitlich begrenzten und vollständig aufgezeichneten Sitzungen.
Greifen Sie hierzu für administrative Eingriffe: ein einmaliger RDP eines Anbieters auf einen Windows-Server oder SSH-Fehlersuche auf einer Appliance, wenn Sie Just-in-Time-Zugriff und einen vollständigen Sitzungs-Audit-Trail benötigen.