Agentenloser RDP- und SSH-Zugriff mit Sophos Protected Browser

Mit Sophos Protected Browser lassen sich interne RDP- und SSH-Hosts ohne ZTNA-Agent auf dem Benutzergerät erreichen. Sophos führt diese beiden Anwendungsfälle unter Agentenlose RDP-Anwendungen und Agentenlose SSH-Anwendungen. Der Zugriff bleibt dabei auf den Protected Browser beschränkt: Eine als agentenlose RDP- oder SSH-Ressource angelegte Verbindung lässt sich nicht mit einem gewöhnlichen RDP- oder SSH-Client öffnen.

Der sichere Ablauf ist für beide Protokolle gleich: Zuerst stellt man Identität, Gateway und Erreichbarkeit bereit, danach erstellt man eine agentenlose ZTNA-Richtlinie und je Host eine Ressource. Im Protected Browser fasst man diese Ressource in einer Anwendungsgruppe zusammen und erlaubt sie über eine Internetrichtlinie. Erst dann testet man mit einer kleinen Benutzergruppe.

Voraussetzungen, Lizenz und Rollen

Vor der Konfiguration müssen folgende Punkte erfüllt sein:

• Der Protected Browser ist auf einem unterstützten Windows- oder macOS-Gerät installiert. Das Beispiel unten verwendet ein Windows-Gerät mit grünem Integritätsstatus.
• Benutzer und Gruppen sind synchronisiert, ein Identitätsanbieter ist eingerichtet und ein ZTNA-Gateway ist betriebsbereit.
• Das Gateway kann den internen RDP- beziehungsweise SSH-Host erreichen. Diese Verbindung wird vor dem Anlegen der Ressource geprüft.
• Für die Ressource existiert eine möglichst kleine Benutzergruppe. Ein gemeinsames Objekt für alle Mitarbeitenden ist für administrative Zugänge ungeeignet.
• Die ausführende Person kann unter Meine Produkte > ZTNA Richtlinien und Ressourcen sowie unter Meine Produkte > Protected Browser Richtlinienobjekte und Internetrichtlinien verwalten.

Die für diesen Ablauf freigegebenen Produktinformationen nennen keine konkrete Rollenbezeichnung und keine separate Lizenz-SKU. Deshalb sollte man weder aus einem sichtbaren Menü allein eine Berechtigung ableiten noch pauschal Super-Admin-Rechte vergeben. Vor der Änderung prüft man im eigenen Tenant, ob ZTNA und Protected Browser verfügbar sind und ob das verwendete Administratorkonto die genannten Objekte anlegen darf. Fehlt eine Seite oder Schaltfläche, lässt man Lizenzierung und Rollen im Tenant durch die zuständige Person prüfen, bevor man weiterarbeitet.

Lokales Gateway und Sophos Cloud Gateway sind mögliche ZTNA-Einsatzmodi. Deren Bereitstellung, Benutzer- und Identitätssynchronisation, Domänen, Zertifikate sowie DNS gehören zur gemeinsamen ZTNA-Grundlage. Die richtige Reihenfolge erklärt Sophos ZTNA einrichten. Diese Anleitung wiederholt diese gemeinsamen Verfahren bewusst nicht.

DNS und Zertifikate vorab abgrenzen

Gateway-Domäne, Zertifikat sowie die erforderliche öffentliche und interne DNS-Auflösung müssen bereits funktionieren. Diese gemeinsame Grundlage richtet der ZTNA-Owner gemäss der verlinkten ZTNA-Anleitung ein; sie wird hier weder dupliziert noch verändert.

Für die hier beschriebenen RDP- und SSH-Ressourcen gilt jedoch die speziellere Eingabemaske: Man trägt Interner FQDN/IP-Adresse der Ressource ein und kann keinen Externen FQDN hinzufügen. Allgemeine DNS-Beispiele für ZTNA-Webanwendungen dürfen deshalb nicht in dieses Feld kopiert werden. Domänen und Zertifikate werden vom ZTNA-Owner vorbereitet, bevor die RDP- oder SSH-Ressource angelegt wird.

Beispielwerte vorbereiten

Die folgenden Namen machen zusammengehörige Objekte erkennbar. Sie sind keine Produktvorgabe und müssen an die eigene Namenskonvention angepasst werden:

• ZTNA-Richtlinie: Agentenloser Zugriff
• RDP-Ressource: Agentenloses RDP
• SSH-Ressource: Agentenloses SSH
• Gerätestatus: Grünes Windows
• Anwendungsgruppe: Agentenlose RDP-Gruppe oder Agentenlose SSH-Gruppe
• Internetrichtlinie: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität beziehungsweise die SSH-Variante
• Interner Host: zum Beispiel rdp01.intern.example oder ssh01.intern.example

Ein FQDN ist gegenüber einer wechselnden IP-Adresse leichter kontrollierbar, muss aber aus Sicht des Gateways korrekt auflösbar sein. Testet man beide Protokolle, legt man getrennte Ressourcen und Anwendungsgruppen an. Dadurch bleiben Zuweisungen, Validierung und spätere Ausserbetriebnahme nachvollziehbar.

Agentenlose ZTNA-Richtlinie hinzufügen

Eine vorhandene, passend abgegrenzte agentenlose Richtlinie kann wiederverwendet werden. Eine eigene Pilot-Richtlinie verringert jedoch das Risiko, produktive Ressourcen unbeabsichtigt zu beeinflussen.

1. Man öffnet Meine Produkte > ZTNA > Richtlinien.
2. Man klickt auf Richtlinie hinzufügen.
3. Unter Richtlinie hinzufügen wählt man den Typ Agentenlos. In anderen ZTNA-Ansichten wird dieser Typ als Ohne Agent bezeichnet. Eine angezeigte Aufforderung Agent anfordern betrifft den agentenbasierten Pfad; für diese Richtlinie muss man nicht auf einen Agenten warten.
4. Auf Neue Richtlinie gibt man einen Namen ein, zum Beispiel Agentenloser Zugriff.
5. Man öffnet Richtlinie durchgesetzt und aktiviert Richtlinie wird durchgesetzt.
6. Man klickt auf Speichern.

Der ZTNA-Richtlinientyp Agent und dessen Tunnel sind nicht Teil dieses Ablaufs. Auch die globale Zeitüberschreitung wegen Inaktivität des Agent-Tunnels gilt für den Agent-Tunnel und ist kein RDP- oder SSH-Sitzungstimer für den Protected Browser. Die globale Mindestzeit, bevor die Geräte-Integrität eine Regel auslöst sollte der ZTNA-Owner trotzdem kennen, wenn Geräteintegrität in der Gesamtumgebung verwendet wird.

RDP- oder SSH-Ressource hinzufügen

Man öffnet Meine Produkte > ZTNA > Ressourcen und Zugriff und klickt auf Ressource hinzufügen. Die Maske füllt man abhängig vom Protokoll aus.

RDP-Ressource

1. Als Ressourcenname gibt man zum Beispiel Agentenloses RDP ein. Eine Beschreibung ist optional.
2. Man wählt das Gateway, das rdp01.intern.example erreichen kann.
3. Unter Zugriffsmethode wählt man den Wert Agentenlos.
4. Man wählt die Richtlinie Agentenloser Zugriff.
5. Als Ressourcentyp wählt man den Wert RDP. Port 3389 und Access-Port-Typ TCP werden automatisch gesetzt und lassen sich in dieser Maske nicht ändern.
6. Bei Interner FQDN/IP-Adresse der Ressource trägt man den internen Host ein. Ein externer FQDN kann für diesen Ressourcentyp nicht hinzugefügt werden.
7. Unter Benutzergruppen zuweisen verschiebt man nur die benötigte Pilotgruppe von Verfügbar nach Zugewiesen.
8. Man klickt auf Speichern.

SSH-Ressource

Für SSH verwendet man denselben Ablauf mit diesen protokollspezifischen Werten:

1. Ressourcenname: zum Beispiel Agentenloses SSH.
2. Zugriffsmethode: Agentenlos.
3. Richtlinie: Agentenloser Zugriff.
4. Ressourcentyp: SSH. Port 22 und Access-Port-Typ TCP werden automatisch gesetzt und lassen sich nicht ändern.
5. Interner FQDN/IP-Adresse der Ressource: zum Beispiel ssh01.intern.example; ein externer FQDN ist nicht verfügbar.
6. Benutzergruppen zuweisen: nur die vorgesehene Pilotgruppe nach Zugewiesen verschieben und danach Speichern.

Agentenbasierte Ressourcen und Web-Apps haben andere Möglichkeiten. Beispielsweise kann der Agent den Gerätezustand in der ZTNA-Zugriffsrichtlinie berücksichtigen und lokale Apps steuern. Für den hier gewählten Weg bleibt die Ressource Ohne Agent; die zusätzliche Geräteprüfung wird, falls benötigt, in der Protected-Browser-Internetrichtlinie umgesetzt.

Protected-Browser-Zugriff eingrenzen

Optionalen Gerätestatus anlegen

Das Hinzufügen eines Gerätestatus ist optional. Ohne dieses Objekt sollte die Pilotgruppe besonders eng gewählt sein. Für das dokumentierte Beispiel mit verwalteten Windows-Geräten:

1. Man öffnet Meine Produkte > Protected Browser > Richtlinienobjekte.
2. Man klickt auf Objekt hinzufügen > Gerätestatus.
3. Als Namen gibt man Grünes Windows ein.
4. Unter OS-Plattform wählt man den Wert Windows.
5. Unter Endpoint Protection wählt man die Option Prüfen, ob Gerät durch Sophos Endpoint geschützt ist und danach den Integritätsstatus Grün.
6. Man klickt auf Speichern.

Zusätzliche Prüfungen erhöhen die Sicherheit, können aber auch mehr Geräte ausschliessen. Jede weitere Bedingung wird deshalb zuerst mit der Pilotgruppe getestet.

Anwendungsgruppe anlegen

1. Man bleibt unter Meine Produkte > Protected Browser > Richtlinienobjekte.
2. Man klickt auf Objekt hinzufügen > Anwendungsgruppe.
3. Man gibt einen eindeutigen Namen ein, zum Beispiel Agentenlose RDP-Gruppe.
4. Man erweitert ZTNA-Ressourcen.
5. Unter Verfügbar wählt man die zuvor erstellte Ressource und verschiebt sie nach Zugewiesen.
6. Man klickt auf Speichern.

Für SSH erstellt man entsprechend Agentenlose SSH-Gruppe und weist Agentenloses SSH zu. Die getrennten Gruppen verhindern, dass eine spätere Änderung am SSH-Zugang unbemerkt den RDP-Zugang verändert.

Internetrichtlinie hinzufügen

1. Man öffnet Meine Produkte > Protected Browser > Internetrichtlinie und wählt die Registerkarte Richtlinien.
2. Man klickt auf Richtlinie hinzufügen.
3. Man gibt einen eindeutigen Namen ein, zum Beispiel Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
4. Man stellt sicher, dass Zulassen ausgewählt ist.
5. Sofern verwendet, wählt man den Gerätestatus Grünes Windows.
6. Man wählt die Anwendungsgruppe Agentenlose RDP-Gruppe.
7. Man klickt auf Speichern.

Für SSH legt man die entsprechende Richtlinie mit der SSH-Anwendungsgruppe an. So bleibt sichtbar, welches Protokoll und welche Gerätebedingung eine Freigabe umfasst.

Verbindung und erwartetes Ergebnis prüfen

Zuerst testet man mit genau einem berechtigten Benutzer und einem Gerät, das die gewählte Gerätebedingung erfüllt.

RDP testen

1. Man startet Sophos Protected Browser und meldet sich an.
2. Oben in der Symbolleiste klickt man auf das Symbol für die Remotedesktopverbindung und danach auf + Neuer Host.
3. Man vergibt einen Anzeigenamen und trägt unter Host denselben internen FQDN oder dieselbe IP-Adresse wie in der ZTNA-Ressource ein. Port 3389 wird automatisch gesetzt.
4. Man gibt Benutzername und Kennwort des Zielsystems ein und klickt auf Verbinden.

Erfolgreich ist der Test, wenn die Remotedesktop-Sitzung im Protected Browser geöffnet wird. Ein normaler RDP-Client ist kein gültiger Gegencheck, weil agentenlose RDP-Ressourcen nur über den Protected Browser zugänglich sind.

SSH testen

1. Man startet den Protected Browser, meldet sich an und klickt in der Symbolleiste auf das SSH-Symbol.
2. Man wählt + Neuer Host, vergibt einen Anzeigenamen und trägt unter Host den Wert der SSH-Ressource ein. Port 22 wird automatisch gesetzt.
3. Man gibt Benutzername und Kennwort des Zielsystems ein und klickt auf Verbinden.

Der Test ist erfolgreich, wenn sich die SSH-Sitzung im Browser öffnet. Danach prüft man mit einem Benutzer ausserhalb der zugewiesenen Gruppe, dass dieser keinen Zugriff erhält.

Dateiübertragung kontrollieren

Nach hergestellter Verbindung verwendet man je nach Protokoll unterschiedliche Bedienelemente:

• RDP: Das obere Menü erweitern und für den Upload Dateiübertragung > Hochladen wählen. Für einen Download beim gewünschten Eintrag das Download-Symbol verwenden.
• SSH: Das Bedienelement unten öffnen und für den Upload Dateiübertragung > In Ordner hochladen wählen. Für einen Download das Download-Symbol verwenden.

Für den Pilotbetrieb testet man ausschliesslich mit einer harmlosen Testdatei ohne vertrauliche Daten. Hochgeladene Dateien werden gescannt und nur hochgeladen, wenn sie sauber sind. Der Upload ist erfolgreich, wenn Datei erfolgreich gescannt und anschliessend die Upload-Meldung erscheint. Den Download prüft man separat: Er ist erfolgreich, wenn die gewählte Datei vollständig auf dem Testgerät ankommt und sich dort öffnen lässt.

Troubleshooting nach Symptom

RDP-/SSH-Aktion fehlt oder ein manuell angelegter Host verbindet nicht

Man prüft in dieser Reihenfolge:

1. Wurde über das RDP- beziehungsweise SSH-Symbol + Neuer Host gewählt und unter Host exakt der interne FQDN beziehungsweise die IP-Adresse der zugehörigen Ressource eingetragen?
2. Ist der Testbenutzer Mitglied der unter Benutzergruppen zuweisen ausgewählten Gruppe?
3. Ist die richtige ZTNA-Ressource in der Anwendungsgruppe unter Zugewiesen?
4. Verwendet die erlaubende Internetrichtlinie genau diese Anwendungsgruppe?
5. Erfüllt das Testgerät den optionalen Gerätestatus, insbesondere Windows, Sophos-Endpoint-Schutz und Integritätsstatus Grün?

Änderungen an einer ZTNA-Benutzergruppe können bis zu einer Stunde benötigen, bis sie am Gateway sichtbar sind. Man sollte deshalb nicht sofort neue Objekte anlegen, solange nur die Gruppenänderung aussteht.

Stimmt der manuell eingetragene Host, prüft man danach die Erreichbarkeit des Zielhosts aus Sicht des ausgewählten Gateways. RDP verwendet fest TCP 3389, SSH fest TCP 22; ein Dienst auf einem abweichenden Port passt nicht zu diesen Ressourcentypen.

Bleibt der Fehler bestehen, geht die Diagnose an den ZTNA-Owner. Die Ablaufzeit für Support-Tokens wird in den globalen ZTNA-Einstellungen konfiguriert. Das Token Sophos-Support für Gateway-Instanz erzeugt man für die betroffene Instanz unter Gateway > Gateway-Einstellungen. Ein Support-Token wird nur für einen konkreten Fall und mit bewusst kurzer Ablaufzeit freigegeben.

Zugriff scheitert nur mit aktiviertem Gerätestatus

Man entfernt die Gerätebedingung nicht unkontrolliert aus einer produktiven Richtlinie. Zuerst vergleicht man Plattform, Endpoint-Schutz und gemeldeten Integritätsstatus des Pilotgeräts mit dem Objekt Grünes Windows. Für einen isolierten Vergleich kann man eine separate Pilot-Internetrichtlinie ohne Gerätestatus verwenden; die Benutzergruppe bleibt dabei eng begrenzt.

Datei wird nicht hochgeladen

Ein Upload erfolgt erst nach erfolgreichem Scan. Fehlt die Meldung Datei erfolgreich gescannt oder wird die Datei nicht als sauber bewertet, gilt der Upload nicht als erfolgreich. Statt den Scan zu umgehen, verwendet man eine harmlose Testdatei und eskaliert den fehlgeschlagenen Scan mit Zeitpunkt, Benutzer, Zielhost und Dateiname.

Sicherer Rückweg und Offboarding

Die freigegebenen Produktinformationen dokumentieren keinen vollständigen Löschablauf für alle beteiligten Protected-Browser-Objekte. Deshalb werden Gateway, DNS, Zertifikate oder gemeinsam verwendete Richtlinien nicht als vermeintlicher Rollback gelöscht.

Für einen unmittelbaren, reversiblen Zugriffsstopp kann man eine dedizierte ZTNA-Richtlinie unter Meine Produkte > ZTNA > Richtlinien öffnen und auf der Registerkarte Richtlinie durchgesetzt auf Richtlinie umgangen stellen. In diesem Zustand können Benutzer nicht auf die von dieser Richtlinie verwalteten Ressourcen zugreifen.

Vorher prüft man, ob wirklich nur die vorgesehenen RDP- oder SSH-Ressourcen dieser Richtlinie zugewiesen sind. Danach testet man mit dem Pilotbenutzer, dass die Verbindung nicht mehr zustande kommt. Als Rückweg stellt man dieselbe dedizierte Richtlinie wieder auf Richtlinie wird durchgesetzt und wiederholt den Verbindungstest. Wird die Richtlinie von weiteren Ressourcen genutzt, stoppt man vor der Änderung und übergibt an den ZTNA-Owner.

Für die dauerhafte Ausserbetriebnahme dokumentiert man zuerst Ressource, Gateway, Richtlinie, Benutzergruppen, Anwendungsgruppe und Internetrichtlinie. Anschliessend entfernt der jeweilige Owner die Zuweisungen und Objekte in Abhängigkeitsreihenfolge. Ohne freigegebenen, produktspezifischen Löschablauf ist die sichere Grenze erreicht, bevor gemeinsam genutzte ZTNA-, DNS- oder Zertifikatsobjekte gelöscht werden.

Betrieb und Lifecycle

Mindestens bei jeder Änderung an Benutzergruppen, Gateways, internen Hostnamen oder Gerätebedingungen wird ein Positiv- und Negativtest wiederholt. Zusätzlich sollte der Owner regelmässig prüfen:

• ob die RDP- und SSH-Hosts aus Sicht des Gateways erreichbar sind;
• ob nur benötigte Gruppen zugewiesen sind;
• ob Ressourcen, Anwendungsgruppen und Internetrichtlinien noch eindeutig zusammengehören;
• ob Domänen und Zertifikate gültig und dem richtigen Gateway zugeordnet sind;
• ob die globale Mindestzeit für Geräteintegritätsregeln zum gewünschten Verhalten passt;
• ob ein erzeugtes Support-Token abgelaufen ist und nicht länger als nötig besteht.

Agentenlose RDP- und SSH-Ressourcen bleiben ein eigener Zugriffspfad. Änderungen an Agent-Tunnel-Timeouts oder am agentenbasierten Rollout ersetzen deshalb keine erneute Prüfung im Protected Browser. Ebenso werden aus dieser Anleitung keine Übergangs-, Abschalt- oder EOL-Termine abgeleitet; bei Produktänderungen prüft der Owner die aktuell im Tenant sichtbaren Einstellungen und führt den Pilotablauf erneut aus.