Accès RDP et SSH sans agent avec Sophos Protected Browser

Sophos Protected Browser permet d’accéder à des hôtes RDP et SSH internes sans agent ZTNA sur l’appareil de l’utilisateur. Sophos répertorie ces deux cas d’utilisation sous Agentenlose RDP-Anwendungen et Agentenlose SSH-Anwendungen. L’accès reste limité à Protected Browser : une connexion créée en tant que ressource RDP ou SSH sans agent ne peut pas être ouverte avec un client RDP ou SSH classique.

La procédure sécurisée est identique pour les deux protocoles : préparez d’abord l’identité, la passerelle et la connectivité, puis créez une stratégie ZTNA sans agent et une ressource par hôte. Dans Protected Browser, ajoutez cette ressource à un groupe d’applications et autorisez-la au moyen d’une stratégie Internet. Effectuez ensuite les tests avec un groupe restreint d’utilisateurs.

Exigences, licence et rôles

Les points suivants doivent être respectés avant la configuration :

Le Protected Browser est installé sur un appareil Windows ou macOS pris en charge. L’exemple ci-dessous utilise un appareil Windows avec un état de santé vert.
Les utilisateurs et les groupes sont synchronisés, un fournisseur d’identité est mis en place et une passerelle ZTNA est opérationnelle.
La passerelle peut atteindre l’hôte RDP ou SSH interne. Cette connexion est vérifiée avant la création de la ressource.
Le plus petit groupe d’utilisateurs possible existe pour la ressource. Un objet partagé pour tous les employés ne convient pas à l’accès administratif.
La personne chargée de la procédure peut gérer les stratégies et les ressources sous Meine Produkte > ZTNA, ainsi que les objets de stratégie et les stratégies Internet sous Meine Produkte > Protected Browser.

Les informations produit publiées pour ce processus ne spécifient pas de nom de rôle spécifique ni de référence SKU de licence distincte. Par conséquent, ne déduisez pas une autorisation de la seule présence d’un menu et n’accordez pas de droits généraux de super-administrateur. Avant d’effectuer la modification, vérifiez dans votre propre locataire si ZTNA et Protected Browser sont disponibles et si le compte administrateur utilisé est autorisé à créer les objets mentionnés. Si une page ou un bouton est manquant, demandez à la personne responsable de vérifier les licences et les rôles dans le locataire avant de continuer à travailler.

Local Gateway et Sophos Cloud Gateway sont deux modes de déploiement ZTNA possibles. Leur mise en service, la synchronisation des utilisateurs et des identités, les domaines, les certificats et le DNS font partie du socle ZTNA commun. L’ordre à respecter est décrit dans Configuration de Sophos ZTNA. Ce guide ne reprend volontairement pas ces procédures communes.

Vérifier au préalable le DNS et les certificats

Le domaine de la passerelle, le certificat ainsi que la résolution DNS publique et interne requise doivent déjà fonctionner. Le responsable ZTNA met en place ce socle commun conformément au guide ZTNA indiqué ; il n’est ni reproduit ni modifié ici.

Les ressources RDP et SSH décrites ici utilisent toutefois un formulaire spécifique : saisissez l’adresse dans Interner FQDN/IP-Adresse der Ressource ; l’ajout d’un Externen FQDN n’est pas possible. Par conséquent, les exemples DNS généraux pour les applications Web ZTNA ne doivent pas être copiés dans ce champ. Les domaines et les certificats sont préparés par le propriétaire ZTNA avant la création de la ressource RDP ou SSH.

Préparer des exemples de valeurs

Les noms suivants rendent les objets associés reconnaissables. Ils ne constituent pas une spécification de produit et doivent être adaptés à votre propre convention de dénomination :

Politique ZTNA : Agentenloser Zugriff
Ressource RDP : Agentenloses RDP
Ressource SSH : Agentenloses SSH
État de l’appareil : Grünes Windows
Groupe d’applications : Agentenlose RDP-Gruppe ou Agentenlose SSH-Gruppe
Politique Internet : Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität ou la variante SSH
Hôte interne : par exemple rdp01.intern.example ou ssh01.intern.example

Un FQDN est plus facile à gérer qu’une adresse IP changeante, mais il doit être résolu correctement depuis la passerelle. Pour tester les deux protocoles, créez des ressources et des groupes d’applications distincts afin de conserver la traçabilité des affectations, de la validation et de la mise hors service.

Ajouter une stratégie ZTNA sans agent

Une stratégie sans agent existante et correctement délimitée peut être réutilisée. Une stratégie pilote dédiée réduit toutefois le risque d’affecter involontairement les ressources de production.

Ouvrez Meine Produkte > ZTNA > Richtlinien.
Cliquez sur Richtlinie hinzufügen.
Sous Richtlinie hinzufügen, sélectionnez le type Agentenlos. Dans d’autres vues ZTNA, ce type est appelé Ohne Agent. L’invite Agent anfordern concerne le parcours avec agent ; cette stratégie ne nécessite aucun agent.
Sur Neue Richtlinie, saisissez un nom, par exemple Agentenloser Zugriff.
Ouvrez Richtlinie durchgesetzt et activez Richtlinie wird durchgesetzt.
Cliquez sur Speichern.

Le type de politique ZTNA Agent et ses tunnels ne font pas partie de ce flux. De plus, le Zeitüberschreitung wegen Inaktivität des Agent-Tunnels global s’applique au tunnel de l’agent et n’est pas un minuteur de session RDP ou SSH pour le Protected Browser. Le propriétaire du ZTNA doit toujours connaître le Mindestzeit, bevor die Geräte-Integrität eine Regel auslöst global si l’intégrité du périphérique est utilisée dans l’environnement global.

Ajouter une ressource RDP ou SSH

Ouvrez Meine Produkte > ZTNA > Ressourcen und Zugriff, puis cliquez sur Ressource hinzufügen. Renseignez le formulaire selon le protocole choisi.

Ressource RDP

Par exemple, saisissez Agentenloses RDP sous la forme Ressourcenname. Une description est facultative.
Choisissez la passerelle capable d’atteindre rdp01.intern.example.
Sous Zugriffsmethode, sélectionnez la valeur Agentenlos.
Choisissez la stratégie Agentenloser Zugriff.
Pour Ressourcentyp, sélectionnez RDP. Le port 3389 et le type de port d’accès TCP sont définis automatiquement et ne peuvent pas être modifiés dans ce formulaire.
Dans Interner FQDN/IP-Adresse der Ressource, saisissez l’hôte interne. Aucun FQDN externe ne peut être ajouté pour ce type de ressource.
Sous Benutzergruppen zuweisen, déplacez uniquement le groupe pilote requis de Verfügbar vers Zugewiesen.
Cliquez sur Speichern.

Ressource SSH

Pour SSH, utilisez le même flux avec ces valeurs spécifiques au protocole :

Ressourcenname : par exemple Agentenloses SSH.
Zugriffsmethode : Agentenlos.
Richtlinie : Agentenloser Zugriff.
Ressourcentyp : SSH. Le port 22 et le type de port d’accès TCP sont définis automatiquement et ne peuvent pas être modifiés.
Interner FQDN/IP-Adresse der Ressource : par exemple ssh01.intern.example ; un FQDN externe n’est pas disponible.
Benutzergruppen zuweisen : déplacez uniquement le groupe pilote prévu vers Zugewiesen, puis cliquez sur Speichern.

Les ressources avec agent et les applications Web offrent d’autres possibilités. Par exemple, l’agent peut tenir compte de l’état de l’appareil dans la stratégie d’accès ZTNA et contrôler les applications locales. Dans la procédure décrite ici, la ressource reste Ohne Agent. Si un contrôle supplémentaire de l’appareil est nécessaire, configurez-le dans la stratégie Internet de Protected Browser.

Limiter l’accès au navigateur protégé

Créer un statut de périphérique facultatif

L’ajout d’un état d’appareil est facultatif. Sans cet objet, le groupe pilote doit être particulièrement restreint. Pour l’exemple documenté avec des appareils Windows gérés :

Ouvrez Meine Produkte > Protected Browser > Richtlinienobjekte.
Cliquez sur Objekt hinzufügen > Gerätestatus.
Entrez Grünes Windows comme nom.
Sous OS-Plattform, sélectionnez la valeur Windows.
Sous Endpoint Protection, sélectionnez l’option Prüfen, ob Gerät durch Sophos Endpoint geschützt ist, puis l’état d’intégrité Grün.
Cliquez sur Speichern.

Des contrôles supplémentaires augmentent la sécurité, mais peuvent également exclure davantage d’appareils. Chaque condition supplémentaire est donc d’abord testée auprès du groupe pilote.

Créer un groupe d’applications

Restez dans Meine Produkte > Protected Browser > Richtlinienobjekte.
Cliquez sur Objekt hinzufügen > Anwendungsgruppe.
Saisissez un nom unique, par exemple Agentenlose RDP-Gruppe.
Développez ZTNA-Ressourcen.
Sous Verfügbar, sélectionnez la ressource créée précédemment et déplacez-la vers Zugewiesen.
Cliquez sur Speichern.

Pour SSH, créez Agentenlose SSH-Gruppe et affectez Agentenloses SSH. Des groupes distincts évitent qu’une modification ultérieure de l’accès SSH ne change l’accès RDP à l’insu de l’administrateur.

Ajouter une politique Internet

Ouvrez Meine Produkte > Protected Browser > Internetrichtlinie et sélectionnez l’onglet Richtlinien.
Cliquez sur Richtlinie hinzufügen.
Saisissez un nom unique, par exemple Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
Assurez-vous que Zulassen est sélectionné.
Si utilisé, sélectionnez l’état de l’appareil Grünes Windows.
Sélectionnez le groupe d’applications Agentenlose RDP-Gruppe.
Cliquez sur Speichern.

Pour SSH, créez la stratégie correspondante avec le groupe d’applications SSH. On voit ainsi clairement le protocole et la condition d’appareil couverts par chaque autorisation.

Vérifier la connexion et le résultat attendu

Commencez le test avec un seul utilisateur autorisé et un appareil qui répond à la condition sélectionnée.

Test RDP

Démarrez Sophos Protected Browser et connectez-vous.
En haut de la barre d’outils, cliquez sur l’icône Connexion Bureau à distance puis cliquez sur + Neuer Host.
Attribuez un nom d’affichage et saisissez dans Host le même FQDN interne ou la même adresse IP que dans la ressource ZTNA. Le port 3389 est défini automatiquement.
Saisissez le nom d’utilisateur et le mot de passe du système cible et cliquez sur Verbinden.

Le test réussit si la session de bureau à distance est ouverte dans le Protected Browser. Un client RDP normal ne constitue pas une vérification croisée valide car les ressources RDP sans agent ne sont accessibles que via le Protected Browser.

Test SSH

Démarrez Protected Browser, connectez-vous et cliquez sur SSH-Symbol dans la barre d’outils.
Sélectionnez + Neuer Host, attribuez un nom d’affichage et saisissez la valeur de la ressource SSH dans Host. Le port 22 est défini automatiquement.
Saisissez le nom d’utilisateur et le mot de passe du système cible et cliquez sur Verbinden.

Le test réussit si la session SSH s’ouvre dans le navigateur. Effectuez ensuite un test négatif avec un utilisateur qui n’appartient pas au groupe attribué et vérifiez que l’accès lui est refusé.

Contrôler le transfert de fichiers

Une fois la connexion établie, différents contrôles sont utilisés selon le protocole :

RDP: Développez le menu supérieur et sélectionnez Dateiübertragung > Hochladen pour téléverser un fichier vers l’hôte. Pour télécharger un fichier de l’hôte vers l’appareil, utilisez l’icône de téléchargement de l’entrée voulue.
SSH: Ouvrez la commande inférieure et sélectionnez Dateiübertragung > In Ordner hochladen pour téléverser un fichier vers le dossier de l’hôte. Pour télécharger un fichier de l’hôte vers l’appareil, utilisez l’icône de téléchargement.

Pour le pilote, utilisez uniquement un fichier de test inoffensif ne contenant aucune donnée confidentielle. Les fichiers à téléverser sont analysés et ne sont envoyés vers l’hôte que s’ils sont considérés comme sains. Le téléversement réussit lorsque Datei erfolgreich gescannt s’affiche, puis que le message de téléversement apparaît. Vérifiez séparément le téléchargement depuis l’hôte : il réussit si le fichier sélectionné arrive intégralement sur l’appareil de test et peut y être ouvert.

Dépanner par symptôme

L’action RDP/SSH est manquante ou un hôte créé manuellement ne se connecte pas

Vérifiez les points suivants dans l’ordre :

+ Neuer Host a-t-il été sélectionné à l’aide du symbole RDP ou SSH et du FQDN interne exact ou de l’adresse IP de la ressource associée saisie sous Host ?
L’utilisateur test est-il membre du groupe sélectionné sous Benutzergruppen zuweisen ?
La ressource ZTNA correcte se trouve-t-elle dans le groupe d’applications sous Zugewiesen ?
La politique d’autorisation Internet utilise-t-elle exactement ce groupe d’applications ?
L’appareil de test répond-il à l’état de l’appareil facultatif, en particulier Windows, Sophos Endpoint Protection et l’état de santé Grün ?

Les modifications apportées à un groupe d’utilisateurs ZTNA peuvent prendre jusqu’à une heure pour être visibles sur la passerelle. Vous ne devez donc pas créer immédiatement de nouveaux objets pendant que le changement de groupe est en cours.

Si l’hôte saisi manuellement est correct, vérifiez que la passerelle sélectionnée peut atteindre l’hôte cible. RDP utilise TCP fixe 3389, SSH fixe TCP 22 ; un service sur un autre port ne correspond pas à ces types de ressources.

Si l’erreur persiste, le diagnostic est transmis au propriétaire du ZTNA. Le délai d’expiration des jetons de support est configuré dans les paramètres globaux de ZTNA. Le jeton Sophos-Support für Gateway-Instanz est créé pour l’instance concernée sous Gateway > Gateway-Einstellungen. Un jeton de support n’est libéré que pour un cas précis et avec un délai d’expiration volontairement court.

L’accès échoue uniquement avec l’état de l’appareil activé

Ne supprimez pas sans contrôle la condition d’appareil d’une stratégie de production. Commencez par comparer la plate-forme, la protection des points de terminaison et l’état de santé signalé de l’appareil pilote à l’objet Grünes Windows. Pour une comparaison isolée, on peut utiliser une politique Internet pilote distincte sans état de l’appareil ; le groupe d’utilisateurs reste étroitement limité.

Le fichier n’est pas téléversé

Un téléversement n’a lieu qu’après une analyse réussie. Si le message Datei erfolgreich gescannt ne s’affiche pas ou si le fichier n’est pas considéré comme sain, le téléversement n’a pas réussi. Ne contournez pas l’analyse : utilisez un fichier de test inoffensif et transmettez l’échec au support en indiquant l’heure, l’utilisateur, l’hôte cible et le nom du fichier.

Retour arrière sécurisé et mise hors service

Les informations produit approuvées ne décrivent pas de procédure complète pour supprimer tous les objets Protected Browser concernés. Ne supprimez donc pas la passerelle, le DNS, les certificats ou les stratégies partagées sous prétexte d’effectuer un retour arrière.

Pour un arrêt d’accès immédiat et réversible, vous pouvez ouvrir une politique ZTNA dédiée sous Meine Produkte > ZTNA > Richtlinien. Dans l’onglet Richtlinie durchgesetzt, définissez-la sur Richtlinie umgangen. Dans cet état, les utilisateurs ne peuvent pas accéder aux ressources gérées par cette stratégie.

Avant de le faire, vérifiez si seules les ressources RDP ou SSH prévues sont réellement affectées à cette stratégie. Vérifiez ensuite avec l’utilisateur pilote que la connexion ne peut plus être établie. Pour rétablir l’accès, remettez cette même stratégie dédiée sur Richtlinie wird durchgesetzt, puis répétez le test de connexion. Si d’autres ressources utilisent cette stratégie, arrêtez-vous avant la modification et transmettez l’intervention au responsable ZTNA.

Pour mettre définitivement hors service, documentez d’abord la ressource, la passerelle, la stratégie, les groupes d’utilisateurs, le groupe d’applications et la stratégie Internet. Le propriétaire respectif supprime ensuite les affectations et les objets dans l’ordre de dépendance. Sans flux de suppression partagé spécifique au produit, la limite de sécurité est atteinte avant que les objets ZTNA, DNS ou certificat partagés ne soient supprimés.

Fonctionnement et cycle de vie

Après chaque modification des groupes d’utilisateurs, des passerelles, des noms d’hôtes internes ou des conditions d’appareil, répétez au minimum un test positif et un test négatif. Le responsable doit également vérifier régulièrement :

si les hôtes RDP et SSH sont accessibles du point de vue de la passerelle ;
si seuls les groupes requis sont attribués ;
si les ressources, les groupes d’applications et les politiques Internet vont toujours clairement ensemble ;
si les domaines et les certificats sont valides et attribués à la bonne passerelle ;
si la durée minimale globale des règles d’intégrité de l’appareil correspond au comportement souhaité ;
si un jeton de support généré a expiré et n’existe pas plus longtemps que nécessaire.

Les ressources RDP et SSH sans agent restent une voie d’accès distincte. Les modifications des délais d’expiration du tunnel d’agent ou du déploiement avec agent ne remplacent donc pas une nouvelle vérification dans Protected Browser. Ce guide ne fixe par ailleurs aucune date de transition, d’arrêt ou de fin de vie. Après une modification du produit, le responsable doit vérifier les paramètres visibles dans le tenant et relancer le processus pilote.