Guide de mise en œuvre ZTNA : de la conception à la production

Un projet Zero Trust Network Access (ZTNA) réussit lorsque les décisions d’accès deviennent plus explicites sans compliquer inutilement le travail quotidien.

Il ne suffit donc pas d’installer une passerelle. Une mise en production doit relier l’identité, les appareils, les ressources protégées, les politiques, les chemins d’accès, la journalisation, le support et la reprise dans un même modèle opérationnel.

Ce guide explique comment mettre en œuvre ZTNA par étapes contrôlées. Il complète l’explication architecturale de Comment fonctionne ZTNA et le processus décrit dans le Guide de migration VPN vers ZTNA.

1. Définir le résultat avant les politiques​

Commencez par le problème d’accès que vous cherchez à résoudre.

Les objectifs peuvent inclure :

• remplacer des autorisations VPN distantes très larges par un accès au niveau des ressources
• réduire les accès permanents aux systèmes sensibles
• séparer l’accès des prestataires de celui des employés
• intégrer le contexte d’identité et d’appareil dans les décisions d’autorisation
• améliorer la visibilité d’audit sur l’accès aux ressources privées
• prendre en charge des environnements sur site, auto-hébergés ou déconnectés

Évitez de commencer par une grande matrice de politiques. Identifiez d’abord le résultat métier, puis les utilisateurs et les ressources concernés.

Un pilote bien délimité est plus facile à valider qu’un projet défini simplement comme « déployer Zero Trust partout ».

2. Inventorier identités, appareils et ressources​

Les décisions ZTNA nécessitent de connaître le demandeur, le terminal et la destination.

Créez trois inventaires.

Identités​

Documentez :

• les groupes d’employés et d’administrateurs
• les prestataires et utilisateurs temporaires
• la source d’identité et la méthode d’authentification
• la propriété des groupes ou rôles
• les processus d’arrivée, de mobilité et de départ
• les besoins d’accès privilégié ou soumis à approbation

Appareils​

Documentez :

• les terminaux gérés et non gérés
• la méthode d’enrôlement
• les systèmes d’exploitation concernés
• le modèle de propriété des appareils
• les signaux de posture MDM ou EDR disponibles
• les appareils qui ne peuvent pas utiliser le chemin d’accès géré habituel

Ressources​

Documentez :

• les applications et serveurs
• les protocoles et ports nécessaires
• le propriétaire métier
• le niveau de sensibilité
• les groupes qui ont réellement besoin d’accès
• les dépendances envers d’autres services

Ne définissez pas une ressource uniquement comme un sous-réseau lorsque le besoin réel concerne une application ou un serveur précis.

3. Choisir délibérément le modèle de déploiement​

Les produits ZTNA peuvent placer leurs composants de contrôle et d’application à différents endroits. Choisissez le modèle opérationnel adapté avant le déploiement.

Questions à trancher :

• Qui exploite la plateforme d’accès : votre organisation, un MSP ou le fournisseur ?
• L’accès principal doit-il continuer à fonctionner sans connexion Internet ?
• Certains systèmes protégés se trouvent-ils dans des réseaux isolés ou air-gapped ?
• Quels services externes d’identité, de posture, de supervision ou d’authentification sont des dépendances acceptables ?
• Comment fonctionneront les mises à jour, les licences, les sauvegardes et la reprise après incident ?

Avec ZTXGate, la plateforme centrale peut être exploitée par le client ou un MSP sans plan de contrôle cloud CoreZT obligatoire. Les déploiements connectés peuvent utiliser ZTXHub en option pour centraliser les mises à jour logicielles et les licences, tandis que les déploiements autonomes utilisent des procédures manuelles.

Comparer ZTNA auto-hébergé et cloud

4. Établir le cycle de vie des identités avant les politiques d’accès​

L’authentification prouve l’identité. Le provisionnement et les contrôles de cycle de vie déterminent si cette identité doit toujours exister et quel contexte organisationnel elle porte.

Avant l’accès en production, définissez :

• où les utilisateurs sont créés
• comment les groupes ou rôles sont attribués
• comment les changements d’identité arrivent dans la plateforme ZTNA
• comment l’accès est retiré lorsqu’un utilisateur quitte l’organisation
• comment les identités temporaires expirent
• quelles méthodes d’authentification conviennent à l’accès normal et sensible

ZTXGate peut utiliser OIDC pour l’authentification et SCIM pour le provisionnement et la synchronisation du cycle de vie des identités.

Découvrir identité et confiance de l’appareil

5. Concevoir l’enrôlement et la confiance des appareils​

Une identité utilisateur seule ne dit pas quel terminal émet la demande.

Définissez :

• comment les appareils sont enrôlés
• si certaines ressources sont réservées aux appareils enrôlés
• ce qui se passe lorsqu’un appareil est remplacé ou perdu
• comment l’accès d’un appareil est révoqué
• si des informations de posture sont requises pour certaines ressources

Dans les environnements connectés, ZTXGate peut utiliser des informations de posture issues d’intégrations prises en charge, notamment Microsoft Intune, Microsoft Defender for Endpoint, SentinelOne Singularity, CrowdStrike et Jamf.

Considérez la posture comme un signal de politique, et non comme un substitut à l’identité ou à l’autorisation de ressource.

6. Modéliser les ressources autour du besoin d’accès​

Le modèle de ressources doit refléter ce qu’un utilisateur est réellement autorisé à atteindre.

Au lieu d’accorder à une équipe de développement l’accès à tout un segment réseau, définissez les services dont elle a besoin :

• service de gestion de code source
• système de build
• serveurs applicatifs de développement
• documentation interne

L’administration de production peut alors rester une ressource distincte avec une politique distincte.

Pour chaque ressource, posez les questions suivantes :

• Qui en est propriétaire ?
• Qui en a besoin ?
• Depuis quels appareils ?
• Avec quel protocole ?
• Sous quelles conditions horaires ou d’approbation ?
• Une authentification supplémentaire est-elle nécessaire ?

Un nombre réduit de politiques compréhensibles est généralement plus facile à exploiter qu’un ensemble dense rempli d’exceptions.

7. Choisir le bon chemin d’accès pour chaque ressource​

Toutes les ressources n’ont pas besoin du même mécanisme d’accès.

Avec ZTXGate, deux modèles sont particulièrement importants.

Accès géré​

Les terminaux gérés utilisent une connectivité basée sur WireGuard pour les ressources autorisées. Le tunnel assure le transport sécurisé, tandis que la politique ZTXGate détermine les ressources réellement accessibles.

Ce chemin convient lorsque le terminal a besoin d’un accès par protocole réseau à la ressource protégée.

Accès web sans client​

L’accès sans client sous licence peut proxifier des applications HTTP et HTTPS privées afin que les utilisateurs autorisés puissent y accéder depuis un navigateur sans installer WireGuard sur le terminal.

Ce mode convient à certaines applications web, notamment dans des scénarios de prestataires ou de tiers.

Choisissez le chemin d’accès en fonction des besoins de la ressource plutôt que de forcer toutes les applications dans le même mécanisme.

WireGuard & ZTNA · ZTNA sans client

8. Commencer par des politiques simples​

Une première politique devrait pouvoir être expliquée en une phrase.

Par exemple :

Les membres du rôle Développement peuvent accéder à l’application de développement depuis des appareils enrôlés.

Ajoutez des conditions seulement lorsqu’elles répondent à un besoin réel.

Selon la ressource, la politique peut prendre en compte :

• l’identité et le rôle
• l’appareil enrôlé
• la posture disponible de l’appareil
• l’emplacement réseau
• l’heure
• la ressource
• la durée d’accès
• l’état d’approbation
• les exigences d’authentification supplémentaire

Les ressources sensibles peuvent utiliser un accès temporaire, des workflows de demande et d’approbation et une authentification renforcée lorsque c’est approprié.

Ne reproduisez pas automatiquement toutes les anciennes règles VPN ou pare-feu. Une mise en œuvre ZTNA est aussi l’occasion de supprimer les autorisations qui n’ont plus de justification métier claire.

9. Intégrer audit et supervision dès le pilote​

Ne reportez pas la visibilité à l’après-déploiement.

Pendant le pilote, vérifiez que les opérateurs peuvent répondre à ces questions :

• Qui a tenté l’accès ?
• Quel appareil était impliqué ?
• Quelle ressource était demandée ?
• La demande a-t-elle été autorisée ou refusée ?
• Quelle condition de politique a influencé la décision ?
• Quand l’accès temporaire a-t-il été accordé ou a-t-il expiré ?
• Les événements pertinents peuvent-ils être envoyés au système de supervision de l’organisation ?

ZTXGate fournit des enregistrements d’audit et peut transmettre les événements pertinents aux plateformes SIEM via les formats et transports pris en charge.

Découvrir l’intégration SIEM

10. Valider les cas d’échec et de refus​

Une connexion réussie ne prouve que le scénario nominal.

Testez volontairement les cas négatifs :

• utilisateur sans le rôle requis
• appareil non enrôlé ou révoqué
• condition de posture non satisfaite
• accès temporaire expiré
• demande d’approbation rejetée
• authentification renforcée échouée
• dépendance externe d’identité ou de posture indisponible
• ressource indisponible

Le résultat attendu doit être compréhensible pour l’équipe sécurité comme pour le support utilisateur.

Dans un environnement déconnecté, testez le système dans l’état de connectivité réellement prévu. Les services cloud externes ne peuvent pas fournir de signaux de politique lorsqu’ils sont injoignables.

11. Piloter avec un groupe d’utilisateurs limité​

Choisissez un périmètre pilote dont les besoins d’accès sont connus et le retour arrière maîtrisable.

Un bon pilote comprend généralement :

• un ou deux groupes d’utilisateurs
• un petit ensemble de ressources
• des propriétaires de ressources identifiables
• des contacts de support clairs
• des critères de réussite mesurables

Validez le travail quotidien normal avant d’élargir le périmètre.

Les critères peuvent inclure :

• les utilisateurs atteignent toutes les ressources approuvées
• les ressources non autorisées restent inaccessibles
• les changements d’arrivée et de départ prennent effet correctement
• la révocation d’un appareil fonctionne
• l’accès temporaire expire comme prévu
• les opérateurs trouvent les données d’audit nécessaires
• le support peut diagnostiquer les incidents courants

12. Déployer par vagues​

Après le pilote, ajoutez utilisateurs et ressources par vagues contrôlées.

Une séquence possible :

1. applications internes moins sensibles
2. ressources de développement et d’ingénierie
3. accès prestataires ou partenaires
4. services d’administration
5. systèmes de production sensibles

L’ordre exact dépend de votre organisation. L’essentiel est que chaque vague reste assez petite pour être comprise, testée et annulée si nécessaire.

Si ZTNA remplace un accès VPN, réduisez la portée de l’ancien VPN à mesure que chaque vague se stabilise au lieu de conserver indéfiniment des autorisations larges en double.

13. Préparer l’exploitation et la reprise​

Un ZTNA en production a besoin d’un modèle opérationnel après le déploiement initial.

Définissez les responsabilités pour :

• la propriété et la revue des politiques d’accès
• le cycle de vie des utilisateurs et appareils
• l’approbation des accès temporaires
• les intégrations d’identité et de posture
• la gestion des certificats et clés
• la rétention des journaux et l’envoi SIEM
• les mises à jour logicielles
• la protection des sauvegardes
• les tests de reprise après incident

ZTXGate utilise un modèle de reprise par sauvegarde et restauration plutôt qu’une haute disponibilité clusterisée conventionnelle. Les administrateurs doivent donc prévoir la protection des sauvegardes et la restauration d’un déploiement de remplacement si nécessaire.

Découvrir Sécurité & Confiance

14. Réexaminer les politiques après le déploiement​

ZTNA ne doit pas devenir une nouvelle collection d’autorisations permanentes que personne ne revoit.

Planifiez des revues pour :

• les utilisateurs qui n’ont plus besoin d’une ressource
• les appareils qui devraient être révoqués
• les rôles devenus trop larges
• les exceptions temporaires devenues permanentes
• les ressources inutilisées
• les dépendances envers des services externes
• les politiques provoquant des refus ou incidents de support répétés

L’objectif est de maintenir l’accès aligné sur le besoin métier actuel plutôt que sur des habitudes historiques.

Exemple de séquence de mise en œuvre​

Un premier déploiement pratique peut suivre cette progression :

Où se place ZTXGate​

ZTXGate réunit les briques décrites ci-dessus dans une plateforme ZTNA exploitée par le client ou un MSP :

• authentification OIDC et provisionnement SCIM
• enrôlement individuel des appareils
• signaux de posture MDM/EDR pris en charge
• politiques d’accès au niveau des ressources
• application continue lorsque les conditions pertinentes évoluent
• accès géré basé sur WireGuard
• accès HTTP/HTTPS sans client sous licence
• accès temporaire et workflows de demande/approbation
• options d’authentification renforcée
• audit et transmission SIEM
• déploiements sur site, cloud, hybrides et air-gapped
• ZTXHub optionnel pour la gestion centralisée des mises à jour et licences

Une mise en œuvre raisonnable commence malgré tout à petite échelle : établir le cycle de vie des identités et appareils, définir un nombre limité de ressources, créer des politiques simples, valider les cas positifs et négatifs, puis élargir seulement lorsque le modèle opérationnel fonctionne.

Migration VPN vers ZTNA · Comment fonctionne ZTNA · Architecture ZTNA

Guides associés et prochaines étapes​

• Comment fonctionne le ZTNA — revoyez le modèle de décision ZTNA.
• Guide de migration VPN vers ZTNA — planifiez la coexistence et le retrait progressif des accès VPN larges.
• ZTNA auto-hébergé vs cloud — choisissez le modèle d’exploitation et de dépendance.