Intégrer DNS Protection et ZTNA à Sophos Protected Browser

Sophos Protected Browser intègre DNS Protection et ZTNA par deux voies d’exploitation distinctes. DNS Protection ne se configure pas dans le navigateur : Sophos Endpoint intercepte les requêtes DNS des appareils compatibles et les transmet à DNS Protection via HTTPS. Pour les applications privées ou locales, Protected Browser se connecte en revanche à la passerelle ZTNA préparée.

La procédure courte est donc la suivante :

Sous Mes produits > Protected Browser, vérifiez que vous travaillez dans le bon tenant. La page d’intégration ne comporte pas de commutateur DNS/ZTNA commun.
Vérifiez la configuration DNS Endpoint existante à l’aide des points de préparation ci-dessous et testez-la avec un petit groupe pilote Windows.
Configurez entièrement ZTNA avec l’identité, la passerelle, les ressources et les stratégies.
Pour les applications et ressources sans agent autres que RDP et SSH, activez Appliquer Protected Browser.
Testez séparément, de manière positive et négative, la résolution DNS et l’accès ZTNA. Un test DNS réussi ne prouve pas que l’accès ZTNA fonctionne, et inversement.

Prérequis, licence et rôles

La voie DNS nécessite une licence Workspace Protection, un agent Sophos Endpoint installé et des endpoints Windows compatibles. Windows Server et macOS ne peuvent actuellement pas être ajoutés à la stratégie Endpoint prévue à cet effet. Le détail des limites de licence ne fait pas partie de cette intégration ; avant le pilote, il suffit de confirmer que Workspace Protection est disponible dans le tenant et que Sophos Endpoint est installé sur les appareils pilotes.

Pour la voie ZTNA, les utilisateurs et groupes, le fournisseur d’identité, la passerelle, les ressources, les stratégies, DNS et les certificats doivent déjà fonctionner. Protected Browser complète ce chemin d’accès préparé ; il n’en remplace aucun fondement. Configurer Sophos ZTNA décrit l’ordre et la validation.

Sophos ne précise aucun rôle d’administrateur pour cette page d’intégration. La personne qui intervient doit donc disposer d’un accès avéré aux objets Endpoint, DNS Protection, ZTNA et Protected Browser nécessaires, sans recevoir préventivement des droits Super Admin. Si un produit ou un contrôle manque, vérifiez d’abord le tenant, la licence et les autorisations attribuées.

Avant le pilote, consignez également :

un petit groupe d’utilisateurs et d’appareils ;
un domaine public de test autorisé et un autre délibérément bloqué ;
un nom interne qui doit continuer à être résolu par le service DNS local ;
une ressource de test ZTNA autorisée et un utilisateur de test non autorisé ;
l’ancien chemin de résolution et d’accès comme voie de retour ;
l’heure, la personne responsable et le résultat attendu de chaque modification.

Fournir DNS Protection à Protected Browser

La page Mes produits > Protected Browser sert de page d’orientation pour DNS Protection. Elle ne contient aucune configuration DNS locale. L’installation, la version du package, la stratégie Endpoint complète, les emplacements, le filtrage, les exceptions de domaine, les pages de blocage, le dépannage et le retour arrière sont donc décrits dans Configurer Sophos DNS Protection pour les endpoints.

Pour cette intégration de Protected Browser, un contrôle de préparation avant le pilote suffit :

Le composant DNS est installé sur les appareils pilotes ; selon la licence, il peut s’appeler DNS et ZTNA.
La stratégie Endpoint attribuée aux appareils ou groupes pilotes est active et Utiliser Sophos DNS Protection est activé.
L’Emplacement par défaut sélectionné, ou un emplacement personnalisé, utilise la méthode de connexion DNS sécurisé. Un nouvel emplacement ne doit pas employer une autre méthode de connexion pour cette voie Endpoint.
La stratégie de filtrage attendue est attribuée à l’emplacement. Une stratégie peut être attribuée à plusieurs emplacements ou pare-feu, mais chaque emplacement ne peut être associé qu’à une seule stratégie. Si le filtrage doit être vérifié, ces limites s’appliquent aussi : DNS Protection prend en charge au maximum 50 stratégies de filtrage ; Autoriser autorise toutes les catégories d’un groupe, Bloquer les bloque et Spécifier définit l’action par catégorie. Créez et modifiez les stratégies en suivant le guide lié.
Le nom interne de test y est pris en compte comme exception afin que le service DNS local prévu continue à le résoudre.

Sophos Endpoint intercepte ensuite le trafic DNS, à l’exception des domaines exclus, et le transmet à DNS Protection via HTTPS. Les réponses vont directement à l’application. Sans intégration activée, le service DNS local traite les requêtes comme auparavant. Les listes de domaines, les nouvelles tentatives NXDOMAIN et la distribution de certificats ne sont pas reconfigurées ici ; elles sont planifiées et vérifiées selon le guide lié.

Fournir ZTNA à Protected Browser

ZTNA doit être entièrement configuré avant l’intégration du navigateur. Protected Browser se connecte à la passerelle ZTNA et permet ainsi un accès contrôlé aux applications internes et aux environnements de cloud privé. La configuration ZTNA commune reste dans le runbook lié ; elle n’est pas répétée ici sous la forme d’une seconde procédure potentiellement divergente.

Pour l’accès sans agent aux applications et ressources autres que RDP et SSH, activez ensuite Appliquer Protected Browser. Sophos ne documente ni chemin de menu fiable ni champ de formulaire supplémentaire pour ce réglage. Utilisez donc le commutateur uniquement dans la configuration ZTNA visible dans votre tenant. S’il manque, arrêtez-vous là plutôt que de deviner un chemin provenant d’une autre vue du produit.

RDP et SSH constituent une variante distincte. Sophos exige une configuration ZTNA spécifique pour les ressources RDP ou SSH sans agent. Un test général d’application web ou la seule activation d’Appliquer Protected Browser ne valide pas cette voie.

Valider le pilote

La validation sépare délibérément DNS et ZTNA. Commencez par tester exactement un appareil pilote avec un utilisateur autorisé.

Vérifier le résultat DNS

Résultats attendus :

Le domaine public de test autorisé est résolu et accessible.
Le domaine de test bloqué est bloqué conformément à la stratégie de filtrage attribuée.
Le nom interne de test passe par le service DNS local prévu et reste accessible.
Les requêtes DNS de l’appareil pilote apparaissent pour l’emplacement attendu ou dans les rapports DNS associés.
Une application ayant son propre comportement DNS sécurisé ou DNS-over-HTTPS est testée séparément, au lieu d’étendre à toutes les applications les conclusions d’un simple test de navigateur.

Si un événement attendu manque, n’assouplissez pas immédiatement le filtrage. Vérifiez d’abord le composant installé, la stratégie Endpoint réellement active, Utiliser Sophos DNS Protection, l’emplacement DNS sécurisé et le résolveur effectivement utilisé. Le guide lié contient la suite du dépannage DNS.

Vérifier le résultat ZTNA

Avec l’utilisateur autorisé, ouvrez dans Protected Browser la ressource privée de test préparée. La réussite signifie que la connexion, la passerelle ZTNA, l’attribution de la ressource et l’application fonctionnent ensemble. Un utilisateur extérieur au groupe autorisé confirme ensuite le cas négatif : la ressource ne doit être ni disponible ni accessible pour lui.

Consignez séparément l’heure et le résultat des tests DNS et ZTNA. Vous saurez ainsi quelle voie est touchée par une panne ultérieure.

Dépannage par symptôme

DNS ne fonctionne pas sur l’appareil pilote

Vérifiez d’abord qu’il s’agit d’un endpoint Windows compatible, que Sophos Endpoint et le composant DNS sont installés et que la stratégie Endpoint effectivement appliquée active Utiliser Sophos DNS Protection. Contrôlez ensuite l’emplacement DNS sécurisé sélectionné et l’accessibilité HTTPS de DNS Protection. Windows Server et macOS ne constituent pas des contre-tests appropriés pour cette voie de stratégie Endpoint. Effectuez les modifications de stratégie, d’emplacement, de filtrage, de domaine ou de retour arrière selon le guide lié.

Si vous vérifiez aussi un emplacement réseau pour cerner le problème, il lui faut une adresse IPv4 publique valide ou un FQDN d’emplacement résolvable. Les adresses RFC 1918 appartenant à 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16 ne sont pas des adresses publiques valides à cette fin. Toutefois, toutes les adresses commençant par 172. ou 192. ne sont pas privées ; cette abréviation ne doit donc pas servir de critère de contrôle.

La connexion ZTNA fonctionne, mais pas l’application

DNS Protection n’est alors pas le premier suspect. Vérifiez l’attribution des utilisateurs et groupes, la ressource ZTNA, la passerelle sélectionnée et l’accessibilité de l’application depuis cette passerelle. Confirmez ensuite qu’Appliquer Protected Browser est actif pour l’accès sans agent prévu. Ne comparez pas RDP et SSH à la voie générale des applications web.

Si Appliquer Protected Browser manque ou si la procédure visible dans le tenant n’est pas claire, ne modifiez plus la configuration à ce stade. L’équipe ZTNA responsable doit clarifier la licence, les autorisations et la vue actuelle du produit avant de contourner des protections ou de recréer des ressources.

Retour arrière et retrait sûrs

Ne démontez pas DNS et ZTNA simultanément. Avant tout retour arrière, documentez les appareils pilotes, la voie concernée, la personne responsable et le dernier résultat de test positif.

Annulez la voie DNS exclusivement selon la procédure de retour du guide lié, puis validez la résolution des noms internes et publics. Ne supprimez pas immédiatement le composant logiciel commun nommé DNS et ZTNA, car cela pourrait aussi affecter la voie ZTNA.

Sophos ne documente aucune procédure complète de suppression ou de retour arrière pour Appliquer Protected Browser. Pour ZTNA, ne supprimez donc ni la passerelle, ni les objets d’identité, DNS, certificat ou stratégie partagés au titre d’un prétendu retour immédiat. Si l’accès doit être arrêté, transmettez à l’équipe ZTNA responsable la ressource et le groupe d’utilisateurs concernés, puis répétez le test négatif. Sans étape réversible confirmée dans le tenant, le retour arrière s’arrête là.

Exploitation et contrôle régulier

Après le pilote, attribuez les voies DNS et ZTNA à des personnes différentes. Après toute modification de la configuration DNS Endpoint, des groupes d’utilisateurs, de la passerelle ou de la ressource ZTNA, répétez les tests positifs et négatifs concernés. Contrôlez régulièrement la disponibilité de Workspace Protection, le composant Endpoint installé, les points de préparation DNS, l’accès ZTNA et la voie de retour documentée.

Les décisions sur la poursuite de l’exploitation doivent s’appuyer sur la configuration actuelle visible dans le tenant et sur l’aide actuelle de chaque composant. Ne déduisez des annonces historiques aucune échéance de migration, date d’arrêt ou date EOL. Si Sophos modifie un prérequis ou une vue du produit, recommencez d’abord le pilote avant d’adapter le déploiement général.