Configurer Sophos ZTNA : runbook de configuration complet

Sophos Zero Trust Network Access, ou ZTNA, contrôle l’accès aux applications et sites internes au moyen des identités, groupes et stratégies. Une configuration complète exige un service d’annuaire, un fournisseur d’identité, une passerelle, une conception des certificats et du DNS, des stratégies et des ressources. Les applications locales nécessitent un agent ZTNA ; les applications web peuvent être publiées sans agent.

Ce runbook présente l’architecture globale et l’ordre de configuration correct. Il ne remplace ni la planification détaillée d’une passerelle, ni les runbooks spécialisés pour les contrôleurs de domaine, RDP ou SSH. Commencez par une seule application, un groupe pilote et un chemin de retour documenté. N’élargissez le périmètre qu’après la réussite des tests positif et négatif.

Réponse directe : l’ordre correct

Configurez Sophos ZTNA dans cet ordre :

Vérifier la licence, l’accès administrateur, les plateformes et l’application cible.
Définir le type d’accès et le mode de passerelle.
Synchroniser les utilisateurs et groupes de sécurité depuis Microsoft Entra ID ou Active Directory.
Configurer le fournisseur d’identité et tester sa connexion.
Mettre à disposition le certificat wildcard, le domaine et la passerelle.
Configurer la résolution DNS publique et privée.
Créer une stratégie ZTNA limitée.
Déployer l’agent ZTNA uniquement lorsque le type d’accès l’exige.
Créer la ressource avec exactement une stratégie et les groupes prévus.
Tester les accès autorisé et non autorisé ainsi que les journaux.
Ensuite seulement, migrer d’autres utilisateurs, applications et sites.

Sophos Fusion constitue le plan d’administration. Passerelle, agent, service d’annuaire, fournisseur d’identité, certificat, DNS, stratégie et ressource restent des dépendances techniques distinctes. Une authentification réussie ne prouve donc pas que l’application est joignable ou correctement restreinte.

Prérequis, licence et rôles

Licence et essai

Sophos ZTNA fait partie de Sophos Workspace Protection. La licence existe sous forme d’abonnement autonome, via MSP Flex ou dans l’offre Sophos Endpoint Plus Workspace Protection. Pour Workspace Protection, la quantité nécessaire correspond à la consommation la plus élevée parmi les produits inclus ; pour ZTNA, les utilisateurs uniques authentifiés pendant 30 jours sont comptés. Le même type de licence couvre les accès avec et sans agent ainsi que les passerelles locales et Sophos Cloud Gateway.

La licence Workspace Protection autonome n’inclut pas de licence Sophos Endpoint. Un déploiement avec agent exige donc aussi un droit Endpoint approprié et la possibilité d’installer Sophos Endpoint Agent. Cela ne change pas le fait que la licence ZTNA couvre les deux méthodes d’accès.

Sophos Cloud Gateway applique aussi une limite moyenne de transfert de 15 Go par utilisateur et par mois. Une licence d’essai dure normalement 30 jours. Un tenant d’essai accepte au plus 1 000 entrées par type d’objet, par exemple utilisateurs, groupes ou appareils. À l’expiration, les produits Workspace Protection ne sont plus disponibles dans Sophos Fusion ; la configuration est conservée et réapparaît après renouvellement.

Activez et contrôlez la licence via l’icône de profil > Licensing. Pour un essai structuré, consultez Démarrer et évaluer en toute sécurité un essai Sophos Fusion.

Responsabilités

Clarifiez au minimum ces rôles avant toute modification :

Administrateur Sophos Fusion : peut configurer les sources d’annuaire, fournisseurs d’identité, passerelles, stratégies et ressources. La configuration d’une source d’annuaire AD exige un administrateur de la console Sophos Central.
Administrateur des identités : crée l’inscription d’application, le Client Secret, les groupes, les Redirect URI et, si nécessaire, les comptes invités chez le fournisseur d’identité.
Responsable DNS et certificats : peut créer les enregistrements DNS publics et internes, confirmer la propriété du domaine et renouveler les certificats.
Administrateur réseau ou pare-feu : fournit routage, connexions sortantes, NAT et règles de pare-feu pour le mode choisi.
Application Owner : connaît le FQDN interne ou l’IP cible, les ports, l’authentification, les redirections et le critère de recette métier.
Responsable des endpoints : déploie Sophos Endpoint Agent avec le composant ZTNA et vérifie les systèmes pris en charge.

Ne stockez pas les Client Secrets, mots de passe de bind ou clés privées dans le ticket ou le runbook. Documentez plutôt le responsable, l’emplacement de stockage, l’expiration et le processus de rotation.

Vérification technique préalable

Avant le premier clic, vérifiez :

Hôte de passerelle : VMware ESXi 6.5 ou version ultérieure, ou Hyper-V sur Windows Server 2016 ou version ultérieure. Sophos exige au moins 2 cœurs CPU, 4 Go de RAM et 80 Go de stockage ; un SSD est recommandé. Date et heure doivent être exactes et le fuseau doit être UTC.
Sophos Firewall comme passerelle : SFOS 19.5 MR3 ou version ultérieure, administré par Sophos Fusion. Les pare-feu matériels, cloud, virtuels et logiciels sont pris en charge. Certaines fonctions récentes peuvent exiger une version SFOS supérieure.
Certificat : certificat wildcard de Let’s Encrypt ou d’une autorité de confiance. RSA à partir de 2 048 bits et ECDSA sont pris en charge, mais pas P-384 ni P-521.
Annuaire : Microsoft Entra ID ou Active Directory local avec des groupes maintenus. Les groupes Entra destinés à ZTNA doivent être activés pour la sécurité.
Fournisseur d’identité : Microsoft Entra ID, Okta ou Active Directory local.
Plateforme de l’agent : Windows 10 1803 ou version ultérieure, ou macOS 11 Big Sur ou version ultérieure.
Application : ports statiques connus. Les applications à attribution dynamique ou à très grandes plages de ports, comme d’anciens produits VoIP, ne sont pas prises en charge.
Réseau : accessibilité interne et résolution privée de la passerelle vers l’application. Les passerelles locales doivent aussi joindre en sortie les destinations exigées par Sophos ; l’inspection SSL/TLS ne doit pas rompre ces connexions.

Pour l’architecture, le dimensionnement et les règles réseau, suivez Planifier et créer une passerelle Sophos ZTNA.

Valeurs d’exemple de ce runbook

Remplacez toutes les valeurs par les vôtres. Ne mélangez pas domaines de test et de production.

Objet	Valeur d’exemple
Groupe pilote	`ZTNA-Pilot-Finance`
FQDN de passerelle	`ztna.example.net`
FQDN externe de ressource	`wiki.example.net`
Cible interne	`wiki.intern.example.net`
Port web	`443/TCP`
Stratégie	`ZTNA-Pilot-Healthy`
Ressource	`Wiki-Pilot`
PoP principal	`Europe (Frankfurt) Region`
Utilisateur de test autorisé	`ztna-allow@example.net`
Utilisateur de test bloqué	`ztna-deny@example.net`

1. Choisir le chemin d’accès et le mode de passerelle

Sans agent ou avec agent

Ce choix est techniquement contraignant :

Exigence	Sans agent	Avec agent
Application ou site web	Oui	Oui
Application locale, par exemple application TCP native	Non	Oui
Contrôle de l’état de l’appareil	Non	Oui
Sophos Endpoint Agent requis	Non	Oui
FQDN externe de ressource résolu publiquement	Oui	Non
Avertissement si la ressource est inaccessible	Uniquement dans ce mode	Non

L’accès sans agent ne contrôle que les applications et sites web et n’évalue pas l’état de l’appareil. Une stratégie avec agent peut contrôler l’état de sécurité et restreindre tous les types de ressources pris en charge. Les stratégies et ressources avec agent ne fonctionnent qu’après installation du composant ZTNA sur les appareils.

Protected Browser complet et son extension ne sont pas équivalents : dans un autre navigateur, l’extension n’évalue pas l’intégrité de l’endpoint. Les conditions de protection de l’endpoint ne valent donc que pour le trafic de Protected Browser complet. Les sessions RDP et SSH sans agent via Protected Browser sont des déploiements distincts ; créez une stratégie ZTNA sans agent, une ressource strictement limitée et les objets Protected Browser associés. Ne recopiez pas telle quelle une stratégie d’application web vers des cibles RDP ou SSH d’administration.

Passerelle locale ou Sophos Cloud Gateway

Passerelle locale : l’appliance virtuelle se trouve dans votre centre de données et est joignable depuis Internet. Vous gérez l’instance et devez prévoir ports de pare-feu et règles NAT adaptés.
Sophos Cloud Gateway : Sophos exploite le plan de données cloud. Une instance dans le centre de données relie ce plan aux ressources internes ; l’exposition Internet directe, les ouvertures entrantes et les règles NAT du chemin d’accès ne sont pas nécessaires.

Les modes sont interchangeables et une migration est possible. Traitez-la néanmoins comme un changement contrôlé : DNS, certificat, PoP, noms externes et tests doivent correspondre au nouveau chemin de données.

En mode cloud, choisissez le Point of Presence (PoP) proche du centre de données, pas automatiquement proche des utilisateurs. Des régions existent en Irlande, à Francfort, dans l’Ohio, dans l’Oregon, à Mumbai et à Sydney. Depuis ZTNA 2.1, un PoP secondaire voisin est configuré par défaut pour le basculement automatique. Modifiez le PoP sous My Products > ZTNA > Gateways : ouvrez la passerelle, choisissez Edit, changez la région sous Points of Presence, puis enregistrez.

2. Préparer le service d’annuaire et les groupes

ZTNA autorise selon les groupes d’utilisateurs synchronisés. Créez d’abord un petit groupe pilote activé pour la sécurité et n’y placez que l’utilisateur autorisé. Un second utilisateur hors du groupe est nécessaire au test négatif.

Synchroniser Microsoft Entra ID

Le guide Synchroniser Microsoft Entra ID avec Sophos Fusion reste la référence détaillée. Pour ZTNA, retenez notamment :

Inscrivez l’application ZTNA dans Entra ID.
Pour les passerelles ESXi et Hyper-V, ajoutez https://<gateway-fqdn>/oauth2/callback ; pour Sophos Firewall, ajoutez https://<gateway-fqdn>/ztna-oauth2/callback comme Redirect URI. Plusieurs FQDN sont possibles.
Notez Client ID, Tenant ID et la valeur du Client secret lors de sa création. Elle ne pourra plus être affichée.
N’accordez que les autorisations Microsoft Graph nécessaires et le consentement administrateur requis.
Créez ou sélectionnez des groupes activés pour la sécurité. Vérifiez explicitement ceux importés depuis Microsoft 365 ou AD.
Dans Sophos Fusion, ouvrez Global Settings > Directory service ou Access control > Sign-in & identity, puis ajoutez Microsoft Entra ID.
Configurez domaine, Client ID, Client secret, durée de validité et périodicité Hourly, Daily, Weekly, Monthly ou None.
Limitez les utilisateurs et groupes synchronisés au périmètre nécessaire. Enregistrez et contrôlez sous My Environment > Users & groups.

Plusieurs sources Entra ID d’un même domaine ne peuvent pas être synchronisées. Office 365 GCC High n’est pas pris en charge. Si l’UPN diffère de la connexion endpoint, des utilisateurs en double ou non liés peuvent apparaître. Si vous renommez ensuite un groupe Entra attribué, le nom n’est pas actualisé automatiquement dans l’attribution ; réattribuez le groupe.

Synchroniser Active Directory local

Pour AD, téléchargez Active Directory Synchronization Setup sous Global Settings > Directory service. Il faut .NET Framework 4.6.2 sur l’ordinateur de synchronisation, des identifiants API Sophos avec le rôle Service Principal Active Directory Sync, des utilisateurs et adresses e-mail uniques et les règles de pare-feu ou proxy nécessaires.

Validez Client ID et Client Secret dans le programme d’installation.
Pour LDAP, utilisez un compte ayant accès en lecture à la forêt et le moins de droits possible.
Laissez Use LDAP over SSL connection activé si possible. Le port 636 sert habituellement à LDAPS et le 389 à une connexion non sécurisée.
Sélectionnez ensemble utilisateurs et groupes d’utilisateurs. Faites de même pour appareils et groupes d’appareils.
Limitez le périmètre avec des Base Distinguished Names et filtres LDAP, par exemple OU=Finance,DC=example,DC=net.
Après l’installation ou un changement de filtre, lancez d’abord un aperçu et une synchronisation manuels. Celle-ci peut prendre 15 minutes.

Ne synchronisez pas simultanément depuis AD et Entra ID les utilisateurs et groupes d’un même domaine. Les groupes principaux AD ne sont pas synchronisés pour ZTNA ; les utilisateurs concernés doivent appartenir à un autre groupe AD. Une modification de Base DN ou de filtres peut exclure des objets déjà importés et donc les supprimer de Sophos Fusion. Supprimez les comptes inactifs dans l’annuaire source plutôt que de simplement les masquer de la synchronisation.

Accès invité

Microsoft Entra B2B convient aux utilisateurs externes. Vérifiez au préalable si le tenant autorise la collaboration externe, quels domaines peuvent être invités et qui approuve. Ajoutez les invités individuellement ou par lot contrôlé. Créez un groupe d’invités distinct, synchronisez-le avec Sophos Fusion et n’attribuez que les ressources requises. L’Application Owner doit connaître la date de départ et le sponsor de chaque compte.

Ajouter manuellement un utilisateur

Si l’utilisateur ne vient pas d’un annuaire, ouvrez My Environment > Users & groups, choisissez Add user, puis renseignez First and last name, Email address et, si nécessaire, Role, Manager, Exchange login et Add to groups (optional). N’attribuez un rôle d’administration que s’il est nécessaire ; User ne donne accès qu’au portail libre-service. Activez Email setup link seulement si l’utilisateur doit protéger son appareil et possède des droits d’administrateur local et Internet. Enregistrez, puis vérifiez sa présence dans la liste et le groupe ZTNA prévu. Sinon, contrôlez l’e-mail, le filtre de groupe et si l’annuaire doit être la source de référence.

3. Configurer le fournisseur d’identité

Ouvrez Sophos Central > My Products > ZTNA > Identity providers > Add identity provider ou My Products > ZTNA > Identity providers. Une seule entrée est possible par fournisseur. Évitez les caractères spéciaux ., @ ou # dans le nom, qui peuvent empêcher l’enregistrement.

Microsoft Entra ID

Sélectionnez Microsoft Entra ID (Azure AD).
Saisissez nom, description, Client ID, Tenant ID et Client secret.
Testez la connexion.
N’enregistrez qu’après un test réussi.

Active Directory local

Sélectionnez Microsoft AD (on-prem).
Saisissez l’hôte et le port du serveur AD principal et, éventuellement, un serveur secondaire du même domaine.
Activez TLS ou StartTLS. Si vous sélectionnez Verify SSL certificate, chargez un certificat .pem, .crt ou .cer de 10 Ko maximum.
Saisissez Bind DN, le mot de passe de bind et le Base DN des utilisateurs et groupes.
Vous pouvez activer Captcha et un mot de passe à usage unique par e-mail avec configuration SMTP.
Affectez le fournisseur à une passerelle. Rouvrez-le, sélectionnez la passerelle sous Test Connection et éventuellement un nom d’utilisateur. Le test affiche alors aussi ses groupes.

Avec AD comme fournisseur d’identité, une passerelle ESXi ou Hyper-V doit utiliser au moins ZTNA 2.1 ; Sophos Firewall exige au moins SFOS 19.5 MR3. Le champ e-mail de l’utilisateur test doit être valide. ZTNA ne prend ici en charge qu’un domaine, pas plusieurs domaines enfants d’une forêt. Avec AD local, l’utilisateur doit s’authentifier au premier accès aux ressources derrière chaque passerelle et ne peut être authentifié que sur un appareil à la fois.

Okta

Pour Okta, il faut des groupes synchronisés et un serveur d’autorisation OIDC. La passerelle doit utiliser au moins la version 1.1. Créez dans Okta une application web OIDC, activez Client Credentials et Refresh Token, utilisez le bon chemin de callback et affectez les groupes. Saisissez ensuite Client ID, Client Secret et Issuer URI dans ZTNA. Un serveur d’autorisation Okta personnalisé exige une licence API Access Management.

Connexion fédérée à Sophos Fusion

La connexion fédérée à l’administration Sophos Fusion est distincte du fournisseur ZTNA ci-dessus. Il faut être Super Admin et vérifier d’abord le domaine sous Access control > Sign-in & identity > Sophos sign-in avec le TXT record généré. Ouvrez ensuite Access control > Sign-in & identity > Federated identity providers, puis Add identity provider :

Saisissez nom et description sans ., @ ni #.
Choisissez Microsoft Entra ID, OpenID Connect ou Microsoft AD FS. Entra exige Tenant ID ; OIDC, Client ID, Issuer, Authorization endpoint et JWKS URL ; AD FS, son URL de métadonnées.
Affectez le domaine vérifié. Plusieurs domaines sont possibles, mais un utilisateur ne peut appartenir qu’à un seul.
Choisissez explicitement IdP-enforced MFA ou No IdP-enforced MFA ; dans le second cas, Sophos Fusion impose MFA après l’authentification IdP.
Enregistrez et activez. Une configuration incomplète ou invalide empêche l’activation.

N’activez la fédération qu’une fois que tous les administrateurs et utilisateurs concernés possèdent un domaine et un fournisseur. Testez un compte administrateur limité dans une fenêtre privée en gardant une session Super Admin fonctionnelle ouverte. En cas d’échec, désactivez le fournisseur depuis cette session et contrôlez domaine, endpoints, confiance du certificat et choix MFA.

Sélectionner un fournisseur d’identité dans Sophos ZTNA

4. Mettre à disposition passerelle, domaines et certificat

Planifiez et créez la passerelle selon Planifier et créer une passerelle Sophos ZTNA. Pour plusieurs ressources d’un domaine, utilisez un certificat wildcard. Pour Let’s Encrypt, consultez Créer un certificat wildcard Let’s Encrypt.

Pour le chemin Let’s Encrypt géré par Sophos Fusion, ouvrez My Products > ZTNA > Settings > Domains and certificates, puis Add domain. Fusion génère un CNAME pour _acme-challenge.<domain>. Publiez exactement son nom et sa cible dans le DNS public, conservez-le pour les renouvellements, puis choisissez Verify. L’état doit devenir vérifié. Reprenez la cible complète ; certains fournisseurs exigent un point final. Convertissez au CNAME actuel tout domaine autrefois validé par TXT. Après chaque ajout de domaine, régénérez l’unique certificat géré du compte pour l’y inclure.

Le challenge DNS Certbot manuel d’un certificat wildcard propre est distinct : lui seul utilise le TXT demandé par Certbot. Chargez certificat, chaîne complète et clé privée, puis vérifiez domaine et Subject Alternative Names. Le certificat n’est opérationnel que si un client externe accepte toute la chaîne. L’émission complète reste dans le runbook lié.

5. Configurer le DNS

Passerelle locale

Pour un accès sans agent, publiez :

un enregistrement A pour le FQDN de la passerelle, par exemple ztna.example.net,
un CNAME par ressource vers ce FQDN, par exemple wiki.example.net,
la passerelle et les ressources sans agent dans le même domaine.

Avec agent, seul l’enregistrement A public de la passerelle est nécessaire ; les ressources n’ont pas besoin de CNAME public. La passerelle doit résoudre le FQDN cible en interne. Vous pouvez aussi saisir l’IP interne lors de la création de la ressource.

Sophos Cloud Gateway

Confirmez la propriété du domaine avec le CNAME généré par Sophos. Publiez ensuite le CNAME de l’alias de passerelle. Ajoutez pour chaque ressource sans agent un CNAME vers l’alias affiché. Les ressources avec agent n’exigent pas de CNAME public.

Contrôlez chaque nom selon trois perspectives :

publiquement depuis un réseau externe,
en interne depuis le réseau de la passerelle,
depuis l’appareil pilote dans le mode prévu.

L’agent intercepte le trafic par FQDN, pas par adresse IP. Si une application web redirige vers un autre FQDN, créez aussi celui-ci comme ressource.

6. Créer une stratégie

Ouvrez Sophos Central > My Products > ZTNA > Policies > Add policy ou My Products > ZTNA > Policies.

Cliquez sur Add policy.
Choisissez Agent ou Agentless selon la ressource.
Donnez un nom unique, par exemple ZTNA-Pilot-Healthy.
Pour une stratégie avec agent, laissez Use access control conditions activé sous Access rules.
Sous Allow access, choisissez l’état de sécurité requis.
Enregistrez.

Une stratégie définit méthode et conditions d’accès. Les groupes sont affectés à la ressource, pas à la stratégie. Une ressource ne peut avoir qu’une stratégie ; une nouvelle affectation remplace la précédente.

Les stratégies sans agent n’ont pas de règles d’état de l’appareil. Si Request agent apparaît, vous pouvez créer la stratégie, mais devez attendre le provisionnement et l’installation de l’agent avant les tests avec agent.

7. Agent et cas d’accès particuliers

Installez le composant ZTNA via Sophos Endpoint Agent uniquement sur le groupe pilote. Vérifiez ensuite sur l’endpoint que l’agent est configuré et a reçu la stratégie attendue.

Sous My Products > ZTNA > Settings, réglez l’inactivité du tunnel sur 5, 15 ou 30 minutes, ou 1 heure ; la valeur par défaut est 5 minutes. Le tunnel se rétablit automatiquement avec un nouveau trafic. Le délai minimal avant qu’un nouvel état déclenche une règle évite des blocages inutiles lors de problèmes brefs.

Sous Windows, Do not monitor local traffic peut éviter le hairpinning au bureau. Il faut au moins Sophos Core Agent 2025.2.1.709. Saisissez un FQDN et une IP dans Sophos Fusion et la même association dans le DNS interne. Si la résolution correspond, l’agent envoie directement le trafic local sur le LAN. N’activez cette option que si les ressources doivent être accessibles sur le LAN sans ZTNA ; selon la documentation produit attribuée, elle n’est pas encore disponible sous macOS.

Planifiez séparément les cas particuliers :

Ferme RDS : Terminez d’abord la ferme et son appartenance au domaine selon la documentation Microsoft actuelle. Sous My Products > ZTNA > Resources & access > Add resource, choisissez passerelle, Access method: Agent, Resource type: Remote Desktop Protocol (RDP), FQDN externe de RD Gateway, ports requis (l’exemple utilise 3389, 443 et 80), FQDN interne ou IP et groupe pilote. Depuis le poste pilote, ouvrez https://<rd-gateway-fqdn>/rdweb, téléchargez le fichier RDP et connectez-vous. Une session doit s’ouvrir sur un Session Host. Une capture doit montrer le trafic ZTNA sur TAP/TUN et aucun trafic direct RD Gateway/Session Host sur l’interface principale. Sinon, contrôlez agent, type, ports, DNS et broker/passerelle RDS avant extension.
Contrôle SaaS : Utilisez-le seulement si le SaaS accepte des listes d’IP. Ajoutez l’application comme ressource, n’affectez que le groupe requis et laissez Internal FQDN/IP address vide afin d’utiliser le FQDN externe. Dans le SaaS, n’autorisez que l’IP ou la plage publique de l’interface NAT devant la passerelle. Le pilote doit réussir via ZTNA ; un utilisateur non autorisé ou un accès direct hors de cette plage doit échouer. Sinon, comparez le NAT sortant réel à la liste et contrôlez groupe, FQDN et chemin.
Windows Hello : Ce chemin sans mot de passe à clés exige Microsoft Entra ID, une licence Azure Premium, Windows 10 ou 11, ZTNA déjà configuré et un serveur applicatif dans le même domaine que l’appareil. Dans Azure, autorisez la jonction sous Devices > Device settings. Dans Intune, activez Hello sous Devices > Windows enrollment > Windows Hello for Business pour tous ou créez sous Devices > Configuration profiles > Create profile un profil Windows 10 and later > Templates > Identity protection pour le pilote. Joignez l’appareil via Settings > Accounts > Access work or school > Connect > Join this device to Azure Active Directory, redémarrez, connectez-vous avec Entra et configurez MFA et PIN ou biométrie. Installez ensuite l’agent. L’accès direct à une application avec agent, y compris CIFS ou RDP, ne doit pas redemander l’IdP ; Sophos Endpoint doit afficher ZTNA configuré et l’utilisateur authentifié. Sinon, contrôlez jonction, profil, connexion Hello, domaine commun et agent. Vérifiez les menus dans la documentation Microsoft actuelle.
Au bureau : choisissez consciemment le même chemin ZTNA qu’à l’extérieur ou l’accès LAN direct. Évitez le hairpinning involontaire.
Contrôleur de domaine : créez-les comme ressources avec agent pour Windows. Depuis Endpoint 2026.1, Sophos gère plusieurs contrôleurs ; priorité et pondération des enregistrements SRV générés permettent basculement et répartition de charge. Pour trois DC, utilisez Configurer plusieurs contrôleurs de domaine avec Sophos ZTNA plutôt que de recréer le basculement dans une ressource web générale.

8. Créer une ressource et attribuer l’accès

Ouvrez Sophos Central > My Products > ZTNA > Resources & access > Add resource ou My Products > ZTNA > Resources & access.

Documentez d’abord :

nom de ressource et Application Owner,
passerelle,
application web, site ou application locale,
FQDN interne ou IP interne,
FQDN externe,
protocole et port,
accès avec ou sans agent,
stratégie,
groupes autorisés,
FQDN de redirection,
tests positif et négatif.

Utilisez un FQDN pour les applications et sites web, et une adresse IP pour les applications locales. Sans agent, le FQDN externe doit être disponible publiquement. Avec agent, il ne doit pas l’être, sinon la ressource est inaccessible.

Cliquez sur Add resource.
Choisissez passerelle et type d’accès.
Saisissez noms interne et externe, protocole et port.
Choisissez la stratégie créée.
N’affectez que le groupe pilote.
Enregistrez et ouvrez le résumé de la ressource pour contrôle.

Les modifications d’appartenance peuvent prendre une heure avant d’agir sur la passerelle. Attendez ce délai avant de modifier encore la configuration.

Validation et résultat attendu

Contrôler la configuration

Sous My Products > ZTNA > Dashboard, aucune alerte High ou Medium inattendue n’apparaît.
Le test du fournisseur d’identité réussit et, pour AD, affiche le groupe attendu.
Domaine et certificat sont valides ; les navigateurs externes ne signalent aucune erreur.
Les enregistrements DNS publics pointent vers la passerelle ou l’alias Sophos attendu.
La passerelle résout la cible interne et atteint son port.
Type de stratégie, type de ressource et état de l’agent concordent.
La ressource affiche exactement la stratégie et le groupe pilote prévus.

Tester l’accès

Ouvrez l’application comme utilisateur pilote autorisé via son FQDN externe, pas son IP.
Confirmez la connexion auprès du fournisseur configuré.
Testez la fonction réelle, pas seulement la page d’accueil : connexion, navigation et lecture sans risque doivent fonctionner.
Testez un utilisateur hors du groupe. Le refus doit être traçable.
Pour une stratégie avec agent, modifiez l’état pertinent uniquement dans une fenêtre contrôlée. La condition doit s’appliquer.
Corrélez les journaux ZTNA, passerelle, fournisseur d’identité, DNS et pare-feu au même horodatage.
Documentez utilisateur, appareil, FQDN, heure, résultat attendu et réel.

Les utilisateurs ouvrent les applications web directement ou via le portail utilisateur ZTNA. Son adresse est le FQDN de la passerelle. Avec le type de plateforme Sophos Firewall, un administrateur doit d’abord configurer une ressource d’accès au portail. Le portail affiche les applications sans agent autorisées de toutes les passerelles ; celles avec agent n’y figurent pas. Une nouvelle connexion est requise après sept jours sans accès. Cinq échecs consécutifs bloquent les autres ressources pendant 60 minutes.

Dépannage par symptôme

Échec de connexion

Testez sous My Products > ZTNA > Identity providers.
Contrôlez Client ID, Tenant ID, expiration du secret et Redirect URI.
Vérifiez que l’utilisateur et le groupe sont synchronisés et activés pour la sécurité.
Pour AD, contrôlez Bind DN, Base DN, port, certificat TLS et e-mail valide de l’utilisateur test.
Après cinq échecs, attendez le verrouillage de 60 minutes au lieu de multiplier les tests.

Un fournisseur ne peut être activé tant que la configuration est incomplète ou invalide. Pour Verification failed due to invalid Client ID, vérifiez l’ID d’application et si la connexion utilisateur est activée dans Entra ID.

Connexion réussie, mais application inaccessible

Ouvrez exactement le FQDN externe de la ressource.
Contrôlez les redirections et créez chaque FQDN supplémentaire comme ressource.
Testez résolution interne et port cible depuis le réseau de la passerelle.
Comparez type de ressource, type de stratégie et installation de l’agent.
Vérifiez que le FQDN externe est public sans agent et précisément non public avec agent.
Vérifiez si une nouvelle stratégie a remplacé l’affectation précédente.
Si l’accès direct fonctionne mais pas le portail sur Sophos Firewall, vérifiez que la ressource de portail requise existe et est affectée au bon groupe.

L’utilisateur n’obtient pas l’accès attendu

Contrôlez l’appartenance effective, pas seulement attendue.
Attendez jusqu’à une heure après une modification.
Réattribuez les groupes Entra renommés.
Pour AD, vérifiez que l’utilisateur n’appartient pas uniquement à un groupe principal.
Vérifiez si des filtres ou le Base DN l’ont exclu du périmètre.

DNS ou certificat défectueux

Comparez A et CNAME caractère par caractère avec Sophos Fusion. Ne contrôlez TXT que pour Certbot manuel ou la vérification de domaine de la fédération Fusion.
Pour un certificat géré, contrôlez le CNAME _acme-challenge.<domain>, conservez-le pour les renouvellements et régénérez le certificat après changement de domaine.
Vérifiez si le fournisseur DNS a ajouté votre domaine au CNAME.
Contrôlez chaîne, portée wildcard, expiration et type de clé.
Testez séparément en public et en interne. Un test LAN réussi ne prouve pas la résolution publique.

Agent installé, mais tunnel ou état inopérant

Contrôlez système, version Endpoint et composant ZTNA installé.
Vérifiez que stratégie et ressource sont toutes deux avec agent.
Tenez compte du délai minimal configuré pour l’état.
Avec Do not monitor local traffic, FQDN et IP du DNS interne doivent correspondre exactement à Central.
L’extension Protected Browser ne fournit pas l’état d’intégrité ; testez ces conditions dans le navigateur complet ou avec l’agent ZTNA.

Escalade vers Sophos Support

Sous Global Settings > Products and Services > ZTNA, définissez l’expiration de l’accès support. Générez ensuite un jeton de support temporaire dans les paramètres de passerelle. Ne transmettez aucun identifiant permanent et révoquez le jeton ou laissez-le expirer après intervention.

Retour sûr et départ des utilisateurs

Annuler un pilote en échec

Arrêtez l’extension à d’autres utilisateurs.
Retirez le groupe pilote de la ressource ou placez la stratégie sur Policy bypassed. Les utilisateurs ne pourront alors pas accéder aux ressources gérées.
Restaurez le chemin antérieur documenté, par exemple VPN ou LAN direct. Ne le retirez qu’après recette de ZTNA.
Retirez le composant ZTNA uniquement des appareils pilotes si aucune autre ressource avec agent ne l’exige.
Retirez les CNAME publics seulement après confirmation du retour. Ne supprimez pas trop vite le DNS de passerelle ou le certificat encore utilisés.
Vérifiez par tests positif et négatif que l’ancien chemin fonctionne et qu’aucune exposition publique involontaire ne subsiste.

Ne désactivez pas Use access control conditions comme contournement d’urgence : vous supprimeriez le contrôle d’état. Si l’accès sûr ne peut être restauré, arrêtez-vous et escaladez plutôt que d’élargir la stratégie.

Retirer un utilisateur ou un invité

Retirez l’appartenance dans l’annuaire de référence ou désactivez le compte chez le fournisseur.
Prévoyez jusqu’à une heure pour l’effet sur la passerelle. La désactivation force ensuite la déconnexion et bloque les ressources.
Vérifiez qu’aucun autre groupe synchronisé n’accorde le même accès.
Contrôlez les journaux ZTNA par un test négatif.
Supprimez comptes invités orphelins, invitations et groupes temporaires du système source.

Les utilisateurs restent en principe connectés jusqu’à sept jours d’inactivité. Seul un administrateur peut actuellement imposer une déconnexion immédiate. Tenez-en compte sur les appareils partagés.

Retirer une ressource ou une passerelle

Inventoriez groupes, stratégies, ressources, noms DNS et dépendances de certificats.
Retirez d’abord l’accès utilisateur et observez les journaux.
Supprimez ensuite la ressource.
Retirez les DNS publics seulement si aucun autre chemin ne les utilise.
Supprimez une passerelle seulement après migration de toutes les ressources et validation du nouveau chemin.
Révoquez secrets et certificats inutiles et retirez les anciennes règles de pare-feu ou NAT.

Exploitation, revue et cycle de vie

Effectuez une revue au moins chaque trimestre et après toute modification majeure :

utilisateurs actifs et consommation de licence des 30 derniers jours,
appartenances aux groupes et invités,
affectation ressource-stratégie et Application Owner,
expiration des certificats et rotation des secrets,
versions des passerelles, agents, SFOS et hyperviseurs,
PoP, basculement et états actuels,
ressources sans agent inaccessibles et tendances d’alertes,
exceptions sortantes, NAT et anciens DNS,
tests positif et négatif de chaque application critique,
chemin d’urgence et de retour documenté.

Le tableau de bord ZTNA affiche le nombre d’alertes et les cinq applications au plus fort transfert sur 24 heures. Utilisez Gateway bandwidth et Resource bandwidth pour suivre utilisateurs authentifiés et volumes.

Une licence ZTNA active inclut versions fonctionnelles et de maintenance, support 24x7 et fonctions Sophos Fusion associées. Sophos prévoit des versions fonctionnelles environ tous les six à douze mois et de maintenance tous les un à trois mois. La version fonctionnelle actuelle et une autre sélectionnée sont maintenues ; les deux dernières versions de maintenance devraient être prises en charge pour chacune. La période de support prévue est d’environ 24 mois, avec normalement un préavis public de 90 jours avant la fin du support.

Considérez ces indications comme une planification, pas la garantie d’une date. Avant toute mise à niveau, consultez les release notes ZTNA, limitations connues, compatibilité de l’agent et état des PoP utilisés. Les anciennes déclarations de transition, entitlement, migration ou EOL sans annonce produit actuelle n’ont pas leur place dans le plan d’exploitation.