Aller au contenu principal

Migrer du VPN vers le ZTNA : un guide pratique et progressif

Passer d’une connectivité VPN d’accès distant classique au Zero Trust Network Access (ZTNA) ne nécessite pas un remplacement brutal et simultané de tous les accès.

Une approche plus sûre consiste à migrer par étapes contrôlées : comprendre ce que fait aujourd’hui le VPN, identifier les accès qui bénéficient d’une autorisation au niveau de la ressource, introduire le ZTNA en parallèle, valider les opérations puis réduire progressivement la portée du VPN.

L’objectif n’est pas de supprimer la technologie VPN pour le principe. Il est de remplacer un accès réseau inutilement large par un accès explicite aux ressources réellement nécessaires.

Comparer ZTNA et VPN · Découvrir le remplacement VPN avec ZTXGate

1. Définissez ce que vous migrez réellement​

Commencez par séparer le produit VPN des usages d’accès qu’il permet aujourd’hui.

Documentez :

  • les utilisateurs et équipes qui se connectent à distance
  • les applications, serveurs et sous-réseaux qu’ils atteignent
  • les protocoles nécessaires
  • les utilisateurs disposant d’un accès permanent ou temporaire
  • la manière dont l’identité est vérifiée
  • l’éventuelle vérification de posture de l’appareil
  • les règles de pare-feu ou de segmentation qui limitent l’accès VPN
  • les processus opérationnels qui dépendent du VPN

Cet inventaire révèle une distinction importante : certaines connexions existent uniquement parce qu’un utilisateur a besoin d’une application précise, alors que d’autres nécessitent réellement une connectivité réseau plus large.

Ces deux cas ne doivent pas automatiquement suivre le même chemin de migration.

2. Décidez ce qui doit passer au ZTNA — et ce qui ne doit pas​

Le ZTNA convient particulièrement lorsque l’accès peut être exprimé comme une relation entre une identité connue, un appareil connu et une ressource définie.

Les candidats typiques incluent :

  • les employés accédant à des applications métier privées
  • les développeurs atteignant des systèmes de développement précis
  • les administrateurs accédant à des services de gestion définis
  • les prestataires ayant besoin d’un accès limité ou temporaire
  • les utilisateurs qui doivent atteindre une seule application sans recevoir un accès général au sous-réseau

Certains usages VPN peuvent rester pertinents, notamment :

  • la connectivité site à site
  • les réseaux d’infrastructure
  • les workflows qui nécessitent volontairement une large portée de protocoles ou de sous-réseaux
  • les environnements anciens qui ne peuvent pas encore être modélisés proprement comme des ressources distinctes

Une migration réussie n’a pas besoin de forcer tous les usages réseau dans le ZTNA.

3. Choisissez une petite première vague​

Évitez de commencer par l’environnement le plus complexe ou le plus critique.

Choisissez un pilote où :

  • les utilisateurs sont faciles à identifier
  • les ressources nécessaires sont bien comprises
  • la politique d’accès reste relativement simple
  • l’équipe peut fournir un retour utile
  • le VPN existant peut rester disponible comme solution de repli contrôlée pendant l’évaluation

Par exemple, une équipe de développement ayant besoin de quelques services internes est généralement plus simple à évaluer qu’une équipe d’exploitation administrant de nombreux réseaux de production.

La première vague doit valider le modèle d’accès et le processus opérationnel, pas toute l’architecture de l’entreprise.

4. Établissez l’identité et la confiance de l’appareil​

Les VPN traditionnels authentifient souvent l’utilisateur avant d’établir un tunnel. Le ZTNA rapproche le contexte d’identité et d’appareil de la décision d’autorisation pour chaque ressource protégée.

Avant la migration, déterminez :

  • comment les utilisateurs s’authentifient
  • comment utilisateurs et groupes sont provisionnés
  • comment les appareils sont enregistrés et identifiés
  • quels signaux de posture sont requis
  • si les ressources sensibles nécessitent une authentification supplémentaire
  • comment les utilisateurs désactivés ou appareils révoqués perdent l’accès

Avec ZTXGate, l’identité peut être intégrée via OIDC et SCIM, tandis que les appareils enregistrés et les intégrations de posture prises en charge peuvent contribuer aux décisions de politique.

Découvrir l’identité et la confiance appareil

5. Modélisez des ressources plutôt que des sous-réseaux​

Une politique VPN commence souvent par des objets réseau : routes, sous-réseaux, ports, zones de pare-feu et ACL.

Une migration ZTNA doit commencer par la ressource protégée.

Au lieu de demander :

À quel réseau cet utilisateur peut-il se connecter ?

posez plutôt la question :

À quelle ressource cet utilisateur doit-il pouvoir accéder, depuis quel appareil et dans quelles conditions ?

Les regroupements utiles peuvent suivre des limites métier ou opérationnelles :

  • applications de développement
  • systèmes financiers
  • services d’administration
  • interfaces de gestion de production
  • ressources accessibles aux prestataires

Gardez les premières politiques simples. Des règles trop complexes sont difficiles à valider et rendent le dépannage de migration plus délicat.

6. Faites fonctionner ZTNA et VPN en parallèle​

Une transition progressive est généralement plus facile à exploiter qu’une bascule brutale.

Pendant le pilote :

  1. conservez le VPN pour les scénarios de repli approuvés
  2. déplacez certaines ressources vers le chemin ZTNA
  3. vérifiez que les utilisateurs accomplissent leur travail normal via le nouveau modèle
  4. comparez l’autorisation et la visibilité d’audit avec l’ancien workflow
  5. identifiez les dépendances absentes de l’inventaire initial

Le fonctionnement parallèle donne le temps de découvrir des dépendances cachées : applications appelant des services secondaires, administrateurs ayant besoin d’un protocole supplémentaire ou utilisateurs dépendant de routes jamais formellement documentées.

Le repli ne doit toutefois pas justifier le maintien permanent des deux chemins. Il doit être contrôlé puis réduit à mesure que la confiance augmente.

7. Validez la sécurité et les opérations, pas seulement la connectivité​

Une migration n’est pas terminée simplement parce qu’un utilisateur peut ouvrir une application.

Validez l’ensemble du cycle de vie :

  • provisioning d’un nouvel utilisateur
  • enregistrement de l’appareil
  • approbation d’accès
  • expiration des accès temporaires
  • suppression d’un utilisateur
  • révocation d’un appareil
  • échec d’authentification
  • refus de politique
  • journaux d’audit
  • transfert vers le SIEM si nécessaire
  • procédures de sauvegarde et de restauration

Testez également ce qui se passe lorsqu’une dépendance est indisponible. Si une politique utilise un fournisseur d’identité, un MDM, un EDR ou un service MFA externe, comprenez le comportement lorsque ce service n’est pas joignable.

Ce point est particulièrement important dans les environnements restreints ou déconnectés.

8. Migrez par vagues​

Lorsque le pilote est stable, répétez le processus avec d’autres groupes de ressources.

Une séquence possible :

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

L’ordre exact dépend de votre environnement. L’essentiel est de garder chaque vague assez petite pour que politiques, dépendances et chemin de retour restent compréhensibles.

Après chaque vague, vérifiez si les anciennes permissions VPN peuvent être réduites.

9. Réduisez la portée du VPN à mesure que la couverture ZTNA augmente​

Si les permissions VPN d’origine restent intactes après la migration, vous conservez précisément le chemin d’accès large que vous vouliez réduire.

Lorsque chaque vague devient stable :

  • retirez les utilisateurs migrés des groupes VPN inutiles
  • supprimez les routes devenues inutiles
  • réduisez les règles de pare-feu associées à l’ancien chemin
  • documentez les exceptions qui nécessitent encore le VPN
  • surveillez les dépendances inattendues à des accès retirés

L’état final peut être une suppression complète du VPN d’accès distant ou un VPN plus limité conservé pour certains besoins réseau.

Les deux peuvent être valides.

10. Définissez des critères de sortie clairs​

Avant de retirer un ancien chemin d’accès, définissez des vérifications objectives.

Pour chaque groupe migré, confirmez que :

  • toutes les ressources nécessaires sont représentées
  • l’identité et l’enregistrement des appareils fonctionnent de manière fiable
  • les politiques d’accès ont été validées
  • les accès temporaires et approuvés se comportent comme prévu
  • les données de supervision et d’audit sont disponibles
  • l’équipe support connaît le nouveau workflow
  • les procédures de restauration sont documentées
  • aucun processus requis ne dépend encore d’un accès VPN large

Cela évite de maintenir indéfiniment deux systèmes d’accès en parallèle.

Exemple : une migration ciblée​

Prenons une équipe de développement qui utilise actuellement un VPN pour plusieurs systèmes internes.

État initial​

  • le VPN donne accès à un sous-réseau de développement
  • des règles de pare-feu limitent certaines destinations
  • les développeurs s’authentifient auprès du VPN
  • l’administration de production est accessible à un plus petit groupe privilégié

Première vague ZTNA​

Définissez les ressources réelles :

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

Puis appliquez des politiques telles que :

  • équipe de développement → ressources de développement
  • appareils enregistrés uniquement
  • administration de production → administrateurs autorisés séparément
  • accès production sensible → accès temporaire ou approuvé avec vérification renforcée

Le VPN peut rester temporairement pour les dépendances non encore migrées. À mesure qu’elles sont comprises puis déplacées, sa portée peut être réduite.

Où se situe ZTXGate​

ZTXGate est conçu autour d’un accès explicite aux ressources plutôt que d’une admission réseau large.

Pour une migration VPN progressive, il peut combiner :

  • identité utilisateur et appareil
  • intégration OIDC et SCIM
  • enregistrement d’appareils et signaux de posture pris en charge
  • politiques au niveau des ressources
  • accès temporaire et workflows de demande/approbation
  • authentification renforcée pour les ressources sensibles
  • accès géré basé sur WireGuard
  • accès HTTP/HTTPS sans client sous licence pour les applications navigateur adaptées
  • journaux d’audit centralisés et transfert SIEM
  • déploiement exploité par le client ou un MSP sans plan de contrôle cloud CoreZT obligatoire

ZTXGate peut donc être introduit parallèlement à un VPN existant puis étendu ressource par ressource sans imposer un remplacement immédiat à l’échelle du réseau.

Découvrir ZTXGate · Découvrir l’architecture ZTNA

Checklist de migration​

Avant de passer à la vague suivante, demandez-vous :

  • Avons-nous inventorié les utilisateurs et ressources derrière le VPN actuel ?
  • Quels usages nécessitent réellement encore une connectivité réseau large ?
  • Les processus de cycle de vie de l’identité et des appareils sont-ils prêts ?
  • Les politiques de ressources sont-elles assez simples pour être relues ?
  • Pouvons-nous faire fonctionner ancien et nouveau chemins en parallèle pendant la validation ?
  • Avons-nous testé onboarding, révocation, accès temporaire, journalisation et restauration ?
  • Pouvons-nous réduire l’ancien chemin VPN après cette vague ?
  • Les équipes support et opérations comprennent-elles le nouveau workflow ?

Une migration VPN vers ZTNA est plus facile à maîtriser lorsque chaque étape réduit à la fois l’incertitude et la portée d’accès.

Remplacement VPN · ZTNA vs VPN · Comment fonctionne le ZTNA · ZTNA auto-hébergé vs cloud

Guides associés et prochaines étapes​