Vermitteln Sie RDP über Access Gate: erreichen Sie eine HMI-Workstation ohne eingehende RDP-Exposition, sichern Sie den Desktop hinter Identitätsprüfung mit einem Access Screen und begrenzen Sie per Enklave, wer ihn sieht, mit ausgehandeltem TLS/NLA und zentraler Protokollierung.
Was Sie erhalten
- Identitätsgeschützter Desktop. Der Benutzer authentifiziert sich am Access Screen von Access Gate, bevor eine RDP-Session zum HMI vermittelt wird.
- Zugriffsbereich per Enklave/ACL. Nur Assets in der Enklave des Operators sind erreichbar; das HMI wird nie direkt im Netzwerk exponiert. Siehe Zugriffskontrolllisten.
- Zentrales DNS, Authentifizierung und Protokollierung. Jede RDP-Session wird über einen einzigen identitätsbewussten Engpass vermittelt und aufgezeichnet, ohne RDP-Firewallregeln pro Host.
- Keine Client-Installation und keine betriebssystemübergreifende RDP-Software. Die Session läuft im Browser, sodass ein Operator unter macOS, Windows oder Linux sich auf die gleiche Weise verbindet.
Einrichtung
1. Das Asset hinzufügen
Registrieren Sie das HMI (wonderware-hmi, 172.31.144.39:3389, RDP) als Asset und platzieren Sie es in der Enklave. Siehe Ein Asset mit Enklaven schützen.
2. Die Enklave erstellen oder zuweisen
Platzieren Sie das HMI und den Operator in derselben Enklave, damit Access Gate die Verbindung vermittelt.
3. Verbinden
Der Benutzer authentifiziert sich am Access Screen von Access Gate und wählt dann das Gerät aus, das er erreichen möchte.
4. RDP-Session aufgebaut
Wie RDP die Sicherheit aushandelt
RDP wählt während des X.224-Handshakes eine Sicherheitsebene. Der Broker von Access Gate fordert in dieser Reihenfolge an: SSL (TLS), dann HYBRID (NLA/CredSSP), dann RDP (Legacy). Der Server muss eine davon erfüllen können, sonst lehnt der Client mit Server refused connection ab.
Beispiel der relevanten xrdp-Konfiguration (/etc/xrdp/xrdp.ini):
security_layer=negotiate ; bietet TLS/NLA an, fällt auf RDP zurück
crypt_level=high
certificate= ; leer, nutzt standardmäßig /etc/xrdp/cert.pem
key_file= ; leer, nutzt standardmäßig /etc/xrdp/key.pem
ssl_protocols=TLSv1.2, TLSv1.3
Begründung der Härtung: Behalten Sie security_layer=negotiate und crypt_level=high bei, damit der Broker TLS/NLA erhält und nicht Legacy-RDP. Der Haken: xrdp muss seinen privaten TLS-Schlüssel lesen können, sonst stuft es sich stillschweigend herab und der Client lehnt die Session ab.
Zusammenfassung
Mit dem Asset in einer Enklave und dem Access Screen davor ist das HMI nur über Access Gate erreichbar: TLS-ausgehandelt, identitätsgeschützt, vollständig protokolliert, ohne direkte RDP-Exposition.