Privileged Access Management in Access Gate ist ein browserbasiertes Remote-Access-Schema: 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-Schema 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 (z. B.
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 — eine Rolle für ein definiertes Zeitfenster gewähren; 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-Schema für Ihr Asset konfigurieren
- Navigieren Sie zu Assets → [Ihr Asset] →
- Klicken Sie auf das Stift-Symbol und dann auf Netzwerk bearbeiten.
- Geben Sie das Remote-Access-Schema 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-Schema 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 Zugriffsbildschirm ist so konfiguriert, dass er Zugriff für einen bestimmten Zeitraum gewährt und ein bestimmtes Verzeichnis verwendet.
- Speichern.
Zum Ablaufzeitpunkt wird der Eintrag automatisch deaktiviert; kein Eingriff des Operators erforderlich.
Session-Aufzeichnung und Überprüfung
Jede proxied Session landet in der Änderungshistorie der Enklave mit:
- Principal (IdP-Benutzer)
- Ziel-Asset
- Protokoll und Zeitstempel
- Session-Ergebnis (normales Schließen, Timeout, vom Operator beendet)
Die Log-Pipeline überträgt dieselben Ereignisse an Ihr SIEM, sofern Log-Weiterleitung konfiguriert ist — sodass Ermittler einen Erkennungsalarm einer bestimmten Session zuordnen können, ohne in die Access Gate-UI wechseln zu müssen.
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 | Privileged Access Management (diese Seite) |
| Alltäglicher Anwendungsverkehr von einem Remote-Laptop | Remote Zero Trust Access |
Beide Flows koexistieren — Sie können beide auf derselben Enklave aktivieren und die Rolle des jeweiligen Benutzers entscheiden lassen, welchen er tatsächlich erhält.