VPN cloud managé vs Zero Trust / ZTNA : complément ou remplaçant ?

Dès qu’on parle d’accès distant moderne, deux notions reviennent régulièrement : le VPN cloud managé et le Zero Trust / ZTNA (Zero Trust Network Access). Les deux sont souvent mélangés dans le discours marketing, alors qu’ils répondent à des logiques différentes.

Un VPN cloud managé modernise un modèle d’accès réseau traditionnel (tunnel + ACL), tandis que le ZTNA pousse l’idée plus loin en raisonnant au niveau “application” et “contexte”, plutôt qu’au niveau “réseau” pur. Ce texte propose un point de vue technique : ce que chaque approche fait, ce qu’elle ne fait pas, et dans quels cas elles se complètent plutôt que de s’opposer.

1. Rappel : VPN cloud managé, logique réseau

Un VPN cloud managé, tel que vu dans les textes précédents, repose sur quelques principes :

  • les utilisateurs s’authentifient auprès d’un fournisseur (souvent via SSO, MFA) ;
  • leurs clients établissent un tunnel chiffré vers l’infrastructure du fournisseur ;
  • des connecteurs, déployés sur vos réseaux privés (on-premise, VPC, homelab), établissent à leur tour des tunnels sortants vers ce même fournisseur ;
  • le fournisseur route le trafic :
    • du client vers le bon connecteur,
    • puis du connecteur vers vos sous-réseaux internes.

La couche de contrôle permet, via une interface web :

  • de gérer des groupes d’utilisateurs ;
  • de définir des ressources réseau (subnets, hôtes, parfois des “apps”) ;
  • de configurer des ACL (qui peut atteindre quoi, sur quels ports).

Le modèle d’origine reste malgré tout très “réseau” :

  • on parle d’adresses IP, de plages, de ports ;
  • on établit des routes (split tunneling, full tunnel) ;
  • les utilisateurs sont logiquement “raccordés” à des segments de réseau internes.

2. Rappel : Zero Trust / ZTNA, logique application + identité

Le modèle Zero Trust part de quelques idées fondatrices :

  • ne jamais présumer qu’un utilisateur ou un appareil est “de confiance” simplement parce qu’il est “dans le réseau” ;
  • vérifier en continu l’identité, l’état de la machine, le contexte (localisation, heure, comportement) ;
  • accorder un accès par application, pas par segment réseau entier ;
  • appliquer le principe du least privilege de manière stricte et dynamique.

Un service ZTNA typique fonctionne plus comme :

  • un “proxy applicatif intelligent” qui publie des applications internes (web, RDP, SSH, etc.) ;
  • un point de contrôle qui décide :
    • si une requête vers telle appli est autorisée maintenant,
    • pour cet utilisateur, sur cet appareil, avec ce niveau de confiance.

Techniquement, le ZTNA s’appuie souvent sur :

  • un tunnel chiffré (comme un VPN) ou un canal TLS par appli ;
  • des connecteurs internes qui exposent des services applicatifs plutôt que des sous-réseaux entiers ;
  • une intégration forte avec les systèmes d’identité et de posture de sécurité (SSO, MDM, EDR, etc.).

3. Différences structurelles : réseau vs application

3.1 Côté VPN cloud managé

Le VPN cloud managé permet déjà de sortir du “tout le réseau interne” en introduisant des ACL fines, mais :

  • les ACL restent souvent exprimées en termes de réseau :
    • subnet 10.0.10.0/24 ;
    • IP 10.0.10.5 ;
    • ports 22, 443, 3389…
  • les clients sont généralement “raccordés” à un espace réseau virtuel depuis lequel ils peuvent initier des connexions ;
  • la logique reste proche de celle d’un VPN IPsec modernisé, avec plus de contrôle et de visibilité.

3.2 Côté ZTNA

Un service ZTNA, lui, se positionne davantage comme :

  • une passerelle applicative :
    • l’utilisateur demande l’accès à une application “CRM interne” ou “Console d’admin X” ;
    • le ZTNA applique des règles sur cette appli, indépendamment de l’IP de la machine cible.
  • un composant intégré au cycle d’authentification :
    • SSO (SAML, OpenID Connect),
    • MFA,
    • vérification de la posture (OS à jour, présence d’un agent de sécurité, etc.).

L’utilisateur ne “voit” jamais le réseau interne en tant que tel : il voit une liste d’applications auxquelles il a droit, point par point.

4. Cas d’usage : quand le VPN cloud managé suffit encore

Il existe de nombreux scénarios où un VPN cloud managé bien configuré reste pertinent, même si l’on vise une approche plus moderne :

  • Accès administrateur bas niveau :
    • administration système via SSH, RDP, outils d’orchestration ;
    • accès à des équipements réseau, hyperviseurs, appliances qui ne sont pas “ZTNA-ready”.
  • Environnements techniques non standards :
    • protocoles non HTTP(S) ou propriétaires ;
    • flux qui passent mal par des proxies applicatifs.
  • Scénarios multi-sites / interconnectivité :
    • liens entre plusieurs sites, VPC, labos ;
    • où le besoin est réellement de raccorder des réseaux, pas seulement de publier une appli.

Dans ces cas, le VPN cloud managé est un moyen plus clair et plus souple qu’un vieux VPN IPsec, tout en restant aligné avec une logique réseau classique.

5. Cas d’usage : là où le ZTNA apporte une vraie valeur en plus

Le ZTNA devient vraiment intéressant dès que l’on s’éloigne de la logique “admin technique” et que l’on se rapproche des usages métier :

  • Accès applicatif pour des utilisateurs non techniques :
    • utilisateurs qui ont besoin d’accéder à 2 ou 3 applis internes, pas à un réseau entier ;
    • cas typiques : comptabilité, RH, support, direction, partenaires.
  • Contexte dynamique :
    • bloquer ou restreindre certains accès selon l’origine géographique ;
    • imposer certaines conditions (appareil géré, OS à jour, EDR en place) pour des applis sensibles.
  • Réduction de la surface réseau exposée :
    • les applis internes ne sont jamais directement joignables depuis Internet ;
    • les clients ne sont jamais “sur le LAN” : ils parlent seulement à la passerelle ZTNA.

Ici, un simple VPN cloud managé, même avec des ACL, reste trop “réseau-centré” pour répondre à toutes les exigences Zero Trust.

6. Complémentarité : VPN cloud managé comme base, ZTNA comme surcouche

Dans beaucoup d’architectures, l’opposition “VPN vs ZTNA” est en réalité trompeuse. On voit plutôt des schémas de ce type :

  • un VPN cloud managé fournit la connectivité sécurisée de base entre :
    • les utilisateurs ;
    • les différents réseaux privés (sites, VPC, labos) ;
    • les environnements techniques non publiés autrement.
  • un service ZTNA est posé par-dessus pour :
    • publier des applications internes critiques ou exposées à un large public ;
    • appliquer des politiques d’accès plus contextuelles et granulaires ;
    • offrir une expérience “portail d’applications” plutôt qu’une simple connexion réseau.

Schéma logique possible :

  • Clients → VPN cloud → réseaux internes / VPC ;
  • ZTNA placé entre les clients et certaines applis internes, en s’appuyant éventuellement sur le VPN cloud pour la connectivité bas niveau.

Le VPN cloud devient alors un composant de transport, et le ZTNA un composant de contrôle et de publication applicative.

7. Limites de chaque approche

7.1 Limites du VPN cloud managé

Même bien conçu, un VPN cloud managé :

  • reste basé sur des notions IP/ports, moins naturelles pour des politiques métiers ;
  • expose toujours un “espace réseau” au client (même si ce n’est qu’un segment filtré) ;
  • n’intègre pas toujours nativement la notion de posture de l’appareil ou de contexte (à moins de couplages externes).

Pour un audit ou un RSSI très orienté Zero Trust, il peut donc être jugé encore trop “réseau-centré” et pas assez “application + contexte”.

7.2 Limites du ZTNA

De son côté, un ZTNA pur :

  • ne couvre pas toujours les besoins bas-niveau (admin réseau, hyperviseurs, flux non standards) ;
  • peut être plus complexe à mettre en place pour des protocoles non web ;
  • suppose souvent une bonne maturité dans la gestion des identités et des postes clients.

Il ne remplace pas forcément toute forme de connectivité réseau, notamment pour les opérations d’infrastructure profondes.

8. Itinéraire d’évolution : du VPN traditionnel au ZTNA via le VPN cloud managé

Pour une organisation qui part d’un VPN IPsec classique, le chemin réaliste peut ressembler à :

  1. Remplacer le VPN IPsec par un VPN cloud managé :
    • même logique globalement, mais avec :
      • meilleure gestion des identités ;
      • ACL plus fines ;
      • connecteurs plus souples (sortants, pas de port ouvert en entrée).
  2. Structurer les ACL :
    • groupes par rôle ;
    • ressources par sensibilité ;
    • politique de moindre privilège.
  3. Introduire du ZTNA pour certaines applications :
    • publication applicative ciblée ;
    • politiques contextuelles (MFA renforcé, contrôle d’appareil) ;
    • portail d’accès pour les usages purement métier.
  4. Réduire progressivement la dépendance au “réseau” pour les usages qui s’y prêtent.

L’idée n’est pas forcément d’éradiquer tout VPN, mais de réduire sa portée au profit d’un accès plus applicatif et ciblé là où c’est pertinent.

Conclusion

Opposer frontalement VPN cloud managé et ZTNA revient à mélanger deux niveaux :

  • le niveau transport réseau (tunnels, routes, connecteurs) où le VPN cloud reste une brique forte ;
  • le niveau contrôle applicatif + identité + contexte, où le ZTNA apporte une granularité et une vision Zero Trust plus abouties.

Un VPN cloud managé modernise un héritage IPsec en offrant :

  • une gestion centralisée des accès ;
  • des ACL plus fines ;
  • une intégration plus simple avec des environnements distribués.

Le ZTNA, lui, va plus loin :

  • il publie des applications plutôt que des réseaux ;
  • il applique des décisions en fonction de l’utilisateur, de l’appareil et du contexte ;
  • il s’inscrit pleinement dans une logique Zero Trust rigoureuse.

Dans la plupart des cas, la trajectoire réaliste n’est pas “100 % VPN” ou “100 % ZTNA”, mais un socle de connectivité VPN cloud managé, progressivement enrichi par des mécanismes ZTNA pour les usages qui exigent le plus fort niveau de contrôle et de réduction de surface d’attaque.