ZTNA ou VPN site-to-site : ce que le zero trust peut remplacer

Le ZTNA peut remplacer un VPN site-to-site pour tout ce que font les personnes : des utilisateurs qui accèdent à des applications, des partenaires qui ont besoin d'un seul système, une entreprise tout juste rachetée qui doit accéder à votre ERP. Il ne peut pas remplacer le tunnel pour ce que les machines font entre elles : la réplication entre contrôleurs de domaine, la supervision qui interroge les équipements des agences, la téléphonie, la réplication du stockage et le trafic de contrôle industriel. La plupart des organisations qui comptent plus d'une poignée de sites finissent avec les deux, et la vraie question est de savoir jusqu'où le tunnel peut se réduire.

Cette distinction manque dans la plupart des comparatifs. Cherchez « ZTNA vs site-to-site VPN » et presque chaque résultat compare un client VPN d'accès distant sur un portable avec un agent ZTNA. C'est une autre décision, que nous traitons dans VPN IPsec ou ZTNA pour l'accès distant. Cet article porte sur le tunnel entre vos bâtiments.

Ce que chacun relie réellement

Un VPN site-to-site relie des réseaux. Le ZTNA relie une identité à une application. Un tunnel entre le siège et une agence fait fonctionner les deux plages d'adresses comme un seul réseau routé : tout ce qui se trouve d'un côté peut atteindre tout ce qui se trouve de l'autre, sauf si une règle de pare-feu l'en empêche. Le ZTNA donne à un utilisateur vérifié, sur un appareil contrôlé, l'accès à une application précise et à rien d'autre.

L'IPsec site-to-site fonctionne au niveau de la couche réseau. Il chiffre les paquets IP entre deux passerelles et transporte tout ce qu'ils contiennent, y compris les protocoles de routage lorsque le tunnel est route-based.

Le ZTNA fonctionne au niveau de la couche application. Dans le modèle que décrit le NIST dans la SP 800-207, un policy decision point vérifie chaque requête et un enforcement point sert d'intermédiaire pour la session. En pratique, un connector placé à côté de l'application ouvre une connexion sortante vers le broker. Les utilisateurs ne reçoivent jamais d'adresse sur le réseau cible. Ils atteignent une application publiée par son nom, après vérification de l'identité et de l'appareil, et le réseau qui se trouve derrière reste invisible.

Le SD-WAN s'invite souvent dans la discussion. C'est du transport : des overlays chiffrés sur plusieurs liens, chaque application étant orientée vers le meilleur chemin. Il produit toujours un réseau routé entre les sites et ne devient une architecture zero trust que lorsqu'on y ajoute un accès fondé sur l'identité, comme dans une plateforme SASE. Le guide SD-WAN couvre le volet transport.

	VPN IPsec site-to-site	ZTNA
Relie	Réseau à réseau (couche 3)	Utilisateur ou appareil à une application (couche 7)
Modèle de confiance	Tout ce qui se trouve dans la plage distante est joignable, sauf si une règle le bloque	Rien n'est joignable, sauf si une politique l'autorise
Qui peut initier une connexion	Les deux côtés	L'utilisateur ou le client demandeur, via le broker
Protocoles	Tout trafic IP, y compris UDP, ICMP et protocoles de routage	Surtout TCP et certaines applications UDP ; pas de broadcast ni de multicast
Exposition à Internet	La passerelle écoute sur UDP 500 et 4500	Le connector établit uniquement des connexions sortantes ; aucun port entrant
Plages d'adresses qui se chevauchent	Nécessite du NAT ou une renumérotation	Aucun problème ; les applications sont publiées par leur nom
Visibilité	Adresses IP et ports	Utilisateur, appareil, application et requête

Sources : IETF RFC 4301 et RFC 7296 (IPsec et IKEv2), NIST SP 800-207 (Zero Trust Architecture).

Là où le ZTNA ne peut pas remplacer un tunnel site-to-site

Le ZTNA ne peut pas transporter le trafic qui part du datacenter vers un équipement en agence, le trafic qui dépend du broadcast ou du multicast, ni les protocoles qui ne fonctionnent que sur un chemin routé. Une architecture 100 % ZTNA est donc exclue pour la réplication entre contrôleurs de domaine, la supervision et le scan centralisés, les téléphones de bureau, les serveurs d'impression, la réplication du stockage et la majeure partie du trafic de contrôle industriel.

Les projets qui coupent tous les tunnels d'un coup échouent ici, pour une seule raison : un connector ZTNA attend la requête d'un utilisateur et ne route pas.

Connexions initiées par le serveur

Une grande partie de l'administration IT part du centre vers l'extérieur. Configuration Manager qui pousse des logiciels vers les postes des agences, Ansible qui ouvre une session SSH vers un hyperviseur en agence, un serveur de supervision qui interroge un switch ou un onduleur en SNMP : tout cela part du siège et doit atteindre une adresse privée en agence. Un scanner de vulnérabilités a besoin d'un accès brut aux couches 3 et 4 pour identifier les hôtes et sonder les ports. Derrière un broker ZTNA, le scanner ne voit rien, et l'agence devient un angle mort de votre inventaire des actifs.

Réplication Active Directory

Les contrôleurs de domaine des agences répliquent avec le cœur dans les deux sens via RPC, en utilisant l'endpoint mapper sur TCP 135 et une plage dynamique de ports élevés (49152 à 65535), en plus de Kerberos, LDAP et SMB. Les administrateurs qui ont placé ce trafic derrière des connecteurs applicatifs signalent des échecs de réplication intermittents. Les solutions habituelles sont un tunnel verrouillé qui ne transporte que le trafic entre contrôleurs de domaine, ou le passage à une identité dans le cloud.

Téléphonie et impression

Quand un autocommutateur sur site fait sonner un téléphone en agence, le PBX initie la session SIP vers le téléphone, et l'audio circule sur des ports UDP négociés dynamiquement. Faire passer ce trafic par un broker cloud ajoute de la latence et de la gigue, et les équipes signalent de l'audio unidirectionnel et des enregistrements perdus. L'impression suit le même schéma : les imprimantes s'annoncent par découverte multicast, et un serveur d'impression central ouvre la connexion vers l'imprimante sur TCP 9100 ou 515.

Systèmes industriels et techniques du bâtiment

Les automates, contrôleurs et systèmes de gestion technique du bâtiment parlent des protocoles comme Modbus/TCP, DNP3 et EtherNet/IP. Certains, comme PROFINET et EtherCAT, fonctionnent directement sur des trames Ethernet. Ces équipements ne peuvent pas faire tourner d'agent, n'ont pas d'identité utilisateur et ne parlent pas les protocoles web. Un serveur SCADA qui dialogue avec des contrôleurs de terrain a besoin d'un chemin routé stable.

Réplication de masse

Les sauvegardes nocturnes et la réplication du stockage déplacent de gros volumes entre les sites. L'IPsec matériel gère cela à la vitesse de la ligne ; un broker cloud ajoute un goulot d'étranglement et parfois des frais de transfert de données.

Rien de tout cela ne rend le ZTNA plus faible. Cela en fait un autre outil. Le tunnel reste là où les machines parlent aux machines. L'idée est de ne plus l'utiliser pour tout le reste.

Là où remplacer le tunnel est rentable

Remplacer le tunnel est rentable pour chaque connexion établie par une personne. Faire passer l'accès des utilisateurs au ZTNA supprime le chemin routé qu'un attaquant emprunterait pour passer d'un portable compromis en agence à vos serveurs, retire la passerelle VPN d'Internet pour cet usage et rend les plages d'adresses qui se chevauchent sans importance.

Aucun chemin pour le mouvement latéral

Avec un tunnel site-to-site, un appareil d'agence victime d'hameçonnage peut atteindre les plages d'adresses du siège. Les scans, les balayages ARP et les tentatives d'exploitation traversent le tunnel comme n'importe quel autre trafic, et les hyperviseurs, contrôleurs de domaine et serveurs de sauvegarde sont à portée, sauf si les règles internes sont strictes. Avec le ZTNA, l'appareil de l'agence ne rejoint jamais le réseau du siège. Il peut atteindre les applications auxquelles son utilisateur a droit, et rien d'autre. Le rayon d'impact d'un portable compromis se réduit à ce portable et à une poignée de sessions applicatives. Le guide de la segmentation réseau couvre le passage des VLAN à l'isolation fondée sur l'identité.

Moins de passerelles exposées

Les équipements de périmètre qui acceptent des connexions depuis Internet comptent parmi les systèmes les plus ciblés de ces dernières années. Le catalogue Known Exploited Vulnerabilities de la CISA recense CVE-2024-3400 dans GlobalProtect de Palo Alto, CVE-2024-21762 dans le VPN SSL de FortiOS, CVE-2024-40766 dans SonicOS de SonicWall, ainsi que les failles Cisco ASA exploitées lors de la campagne ArcaneDoor. La plupart se situent dans les services d'accès distant et d'administration plutôt que dans IPsec lui-même, mais elles résident toutes sur le même boîtier exposé à Internet. Un connector ZTNA n'ouvre aucun port entrant : en agence, un scanner n'a donc rien à trouver.

Aucune clé partagée à gérer

Les maillages IPsec reposent sur des clés pré-partagées ou des certificats. Une clé réutilisée dans plusieurs agences signifie qu'une seule sauvegarde de configuration divulguée expose tout le maillage ; les certificats règlent ce problème, mais imposent des renouvellements et le risque qu'un seul certificat expiré fasse tomber des dizaines de tunnels. Le ZTNA utilise des identifiants de courte durée liés à votre fournisseur d'identité, révocables en une seule modification.

Fusions et partenaires

Deux entreprises qui utilisent toutes deux 192.168.1.0/24 ne peuvent pas simplement être reliées par un tunnel. Il leur faut du NAT des deux côtés ou un projet de renumérotation. Le ZTNA publie les applications par leur nom, et le connector résout l'adresse au sein de son propre réseau : le chevauchement des plages n'a plus d'importance. La même logique s'applique aux fournisseurs : au lieu d'un tunnel vers votre réseau, le partenaire obtient une application. L'accès des tiers sans VPN détaille ce modèle.

Matrice de décision par scénario

La bonne réponse dépend de ce qui transite par le lien. Cette matrice couvre les six situations sur lesquelles les équipes des entreprises de taille intermédiaire nous interrogent le plus souvent.

Scénario	Modèle recommandé	Pourquoi	Points de vigilance
Deux sites (siège et une agence)	Tunnel IPsec route-based avec des règles strictes entre les zones ; ZTNA pour les utilisateurs distants	Les deux sites partagent la téléphonie, l'authentification de domaine et le stockage ; un broker apporte peu pour un seul lien	Une règle any-any à travers le tunnel met le siège à portée de chaque appareil de l'agence
Dix agences ou plus	SD-WAN entre les sites, ZTNA pour tout l'accès des utilisateurs aux applications	Un IPsec maillé ou en hub-and-spoke devient plus difficile à gérer à chaque nouveau site ; le SD-WAN assure le transport et l'accès Internet local (local breakout), le ZTNA gère l'accès	Dépendance à la disponibilité du fournisseur ; les équipements de périphérie doivent prendre en charge le déploiement zero-touch
Technologie opérationnelle ou site de production	Tunnel imposé par le matériel, avec inspection et segmentation stricte ; ZTNA vers un jump host pour la maintenance	Les contrôleurs et le SCADA utilisent des protocoles qui ne peuvent ni faire tourner d'agent ni passer par un proxy de couche 7	Un portable de maintenance compromis peut encore se déplacer latéralement, sauf si les zones OT sont strictement séparées
VPC ou VNet cloud	Hybride : interconnexion cloud ou IPsec pour les données backend, ZTNA pour l'accès des administrateurs	La réplication des bases de données et le trafic entre services exigent du routage ; les ingénieurs ont besoin d'un accès par application	Frais de sortie (egress) du cloud et deux endroits à superviser
Accès des partenaires ou fournisseurs	ZTNA uniquement, par application ou via l'isolation du navigateur	Le partenaire atteint des systèmes nommés et jamais vos plages d'adresses	Les systèmes partenaires qui doivent appeler vos API internes ont besoin d'un connector en sens inverse
Fusion ou acquisition, premier jour	Connectors ZTNA dans l'entreprise rachetée	Fonctionne malgré des plages d'adresses qui se chevauchent, sans NAT ; les applications sont joignables en quelques jours	Les relations d'approbation de domaine, les anciens partages de fichiers et les scripts d'administration auront encore besoin d'un chemin routé plus tard

Matrice fondée sur les modèles d'architecture de la NIST SP 800-207 et le cadre de services SD-WAN MEF 70, ainsi que sur des retours de terrain issus de migrations.

Si vos sites correspondent à la deuxième ou à la cinquième ligne, le moyen le plus rapide de voir la différence est de publier une application interne via le ZTNA en laissant tourner le tunnel en parallèle. Vous pouvez essayer Jimber gratuitement sur un seul site.

Exploitation et coûts

Au quotidien, les deux modèles tombent en panne de manière différente et coûtent de l'argent à des endroits différents.

Taille des paquets et transferts bloqués

IPsec ajoute environ 50 à 73 octets d'en-têtes à chaque paquet, davantage avec la traversée de NAT, ce qui laisse une taille utile d'environ 1 420 à 1 440 octets dans le tunnel. Lorsqu'un paquet de taille maximale portant le bit don't-fragment atteint cette limite et qu'un pare-feu supprime le message ICMP censé le signaler, on obtient le black hole classique : les connexions s'ouvrent, puis les gros transferts se figent. La solution est le MSS clamping sur chaque interface de tunnel. Les sessions ZTNA passent par des connexions TLS ou QUIC ordinaires : la pile TCP du système d'exploitation gère elle-même la taille des paquets, et ce type de panne ne se produit pas pour les applications publiées.

Rekey et basculement

Les tunnels IPsec renégocient leurs clés selon un calendrier. Une perte de paquets ou un CPU chargé pendant un rekey peut désynchroniser les deux extrémités jusqu'à ce que la dead peer detection reconstruise le tunnel, et les agences en adresses dynamiques exigent des contournements supplémentaires. Les connexions ZTNA sont sortantes, et des transports comme QUIC peuvent faire passer une session de la fibre à la 4G sans nouvelle authentification.

Ce que vous voyez

Un tunnel IPsec vous fournit des flux : adresses, ports et volumes, qu'il faut ensuite corréler avec les journaux DHCP et d'annuaire pour retrouver une personne. Un journal ZTNA enregistre qui s'est connecté, depuis quel appareil, à quelle application. La contrepartie : moins de dépannage saut par saut à travers le WAN.

Où va l'argent

Les architectures site-to-site dépensent en matériel : un pare-feu ou un routeur sur chaque site, souvent en paire, des contrats de support annuels et parfois des circuits MPLS. Une plateforme cloud transforme cette dépense en abonnement, généralement par utilisateur, et permet aux agences de fonctionner sur un accès haut débit ordinaire avec un équipement de périphérie plus léger. La solution la moins chère dépend du nombre de sites, du nombre d'utilisateurs et du fait qu'un renouvellement soit de toute façon prévu. Les économies sont les plus importantes là où des circuits privés coûteux peuvent disparaître ; le coût de sortie du MPLS détaille ce volet. Les organisations qui remplacent des pare-feu d'agence en fin de vie, comme les Cisco Meraki MX64 et MX65, font le même calcul au moment du renouvellement, comme expliqué dans Meraki MX en fin de support.

Ce que NIS2 et CyFun attendent en matière de segmentation

Ni NIS2 ni CyFun ne citent une technologie. Tous deux attendent que vous maîtrisiez quels systèmes peuvent atteindre lesquels, que vous limitiez l'accès au strict nécessaire et que vous puissiez le prouver.

L'article 21 de NIS2 énumère les mesures concernées. Trois d'entre elles touchent directement à la connectivité entre sites : la sécurité de la chaîne d'approvisionnement, qui couvre la manière dont les partenaires atteignent vos systèmes ; les politiques de cryptographie ; et le contrôle d'accès. Un tunnel à plat qui donne à un fournisseur ou à une agence un large accès au siège se concilie mal avec le principe du moindre privilège. D'anciens tunnels IKEv1 avec des algorithmes de chiffrement faibles et des clés partagées se concilient mal avec une politique de cryptographie. En vertu de l'article 20, les organes de direction approuvent ces mesures, en supervisent la mise en œuvre et peuvent être tenus responsables des manquements.

En Belgique, le cadre CyberFundamentals (CyFun) du Centre pour la Cybersécurité Belgique (CCB) traduit ces obligations en contrôles, et une certification selon ce cadre confère une présomption de conformité avec la loi belge NIS2, en vigueur depuis le 18 octobre 2024. La fonction Protect de CyFun comprend le contrôle d'accès et la séparation des réseaux. Lors d'un audit, cela se traduit par des questions concrètes : quel trafic est autorisé entre les sites, qui a approuvé les règles et où se trouvent les journaux. Une règle any-any à travers un tunnel site-to-site est un constat facile. Des journaux d'accès fondés sur l'identité, qui montrent exactement qui a atteint quelle application, constituent une preuve solide. Le plan de migration du VPN vers le ZTNA explique comment migrer d'abord l'accès des utilisateurs et traiter le tunnel d'infrastructure en dernier.

Les arguments pour garder IPsec

Un ingénieur réseau expérimenté avancera trois bons arguments en faveur du tunnel.

« IPsec transporte n'importe quoi à la vitesse de la ligne. » C'est vrai. Un tunnel ne se soucie pas de ce qu'il contient, et les pare-feu dotés d'accélération cryptographique chiffrent à plusieurs gigabits par seconde avec une latence négligeable. Le ZTNA termine les sessions et vérifie l'identité, ce qui coûte du temps et de la puissance de calcul. Pour la réplication de masse, les gros transferts de fichiers entre sites et tout ce qui est sensible à la latence, le tunnel reste le meilleur outil. C'est pourquoi l'architecture hybride le conserve précisément pour ce trafic.

« Un tunnel entre mes propres pare-feu ne dépend de personne. » C'est vrai aussi. Les clés, les routes et les politiques se trouvent sur votre propre matériel, et une panne d'un broker cloud ou d'un fournisseur d'identité ne les touche pas. Faire passer le trafic entre sites par une plateforme cloud ajoute une dépendance, et celle-ci mérite une vraie réponse : qu'arrive-t-il à chaque application si la plateforme est injoignable ? Pour l'accès des utilisateurs, la réponse est généralement acceptable, car les utilisateurs qui accèdent à des applications SaaS dépendent déjà d'Internet et de leur fournisseur d'identité. Pour le trafic de production entre machines, elle ne l'est souvent pas, ce qui plaide là encore pour conserver un tunnel étroit.

« La moitié de mes équipements ne peuvent pas faire tourner d'agent. » Caméras, imprimantes, lecteurs de badges, contrôleurs du bâtiment et automates n'ont pas d'utilisateur et ne parlent aucun protocole web. Un tunnel les atteint par leur adresse IP, sans composant supplémentaire. Les forcer derrière le ZTNA implique des jump hosts et des connectors inversés. L'ingénieur a raison : ici, le tunnel est l'outil le plus simple. Le désaccord porte uniquement sur les personnes : les portables, les prestataires et le personnel à distance ont bel et bien une identité, et leur donner un chemin routé vers le réseau est la partie qui n'a plus de sens.

Conclusion

Le ZTNA ne remplace pas le VPN site-to-site. Il remplace l'essentiel de ce pour quoi le VPN site-to-site était utilisé. Gardez un tunnel étroit et strictement filtré, ou un chemin SD-WAN, pour le trafic entre machines qui a besoin de routage, et faites passer chaque personne, chaque partenaire et chaque entreprise rachetée à un accès fondé sur l'identité. Le tunnel rétrécit, le réseau cesse d'être à plat, et la passerelle exposée à Internet perd la plupart de ses raisons d'exister.

Ce choix n'implique pas non plus deux fournisseurs. Jimber couvre le SD-WAN entre les sites et le ZTNA pour les utilisateurs sur une seule plateforme européenne, de sorte que l'architecture hybride se pilote depuis une seule console. Essayez gratuitement avec un site et une application, ou réservez une démo pour déterminer lesquels de vos tunnels peuvent rétrécir.

Questions fréquentes

Le ZTNA peut-il remplacer un VPN site-to-site ?

Pas entièrement. Le ZTNA remplace le tunnel pour l'accès des utilisateurs aux applications, l'accès des partenaires et la plupart des accès aux applications cloud. Il ne peut pas transporter le trafic initié par un serveur, les services qui dépendent du broadcast, la réplication entre contrôleurs de domaine, la téléphonie ni la plupart des protocoles industriels, qui ont besoin d'un chemin routé. La plupart des organisations multisites finissent avec une architecture hybride.

Quelle est la principale différence entre le ZTNA et un VPN site-to-site ?

Un VPN site-to-site relie deux réseaux en couche 3, de sorte que les appareils de chaque côté peuvent s'atteindre mutuellement, sauf si des règles les bloquent. Le ZTNA relie un utilisateur vérifié, sur un appareil contrôlé, à une application précise en couche 7, tandis que le réseau qui se trouve derrière reste invisible.

Pourquoi un VPN site-to-site représente-t-il un risque de sécurité ?

Il crée un chemin routé entre les sites. Si un appareil d'une agence est compromis, un attaquant peut scanner et attaquer les systèmes du siège à travers le tunnel, sauf si les règles internes sont strictes. La passerelle doit en outre accepter des connexions depuis Internet, ce qui en fait une cible à part entière.

Comment le ZTNA empêche-t-il le mouvement latéral entre agences ?

L'appareil de l'utilisateur ne reçoit jamais d'adresse sur le réseau cible. Il ne peut atteindre que les applications auxquelles son utilisateur a droit, via des connexions qui passent par le broker. Les autres sous-réseaux, serveurs et appareils ne sont pas routables depuis cet appareil : les scans et les tentatives d'exploitation n'ont rien à atteindre.

Qu'advient-il des imprimantes et des téléphones de bureau lors du passage au ZTNA ?

Ils cessent souvent de fonctionner dans une architecture 100 % ZTNA, car ils reposent sur la découverte par broadcast, des ports UDP dynamiques et des connexions initiées par le serveur. Gardez-les sur des segments réseau distincts, routés localement et filtrés, ou passez à l'impression cloud et à une téléphonie dans le cloud.

Comment garder la réplication Active Directory fonctionnelle sans tunnel complet ?

Soit vous gardez un tunnel route-based étroit qui n'autorise que le trafic entre contrôleurs de domaine sur les ports nécessaires, soit vous faites passer les agences à une identité dans le cloud. Les connecteurs applicatifs ne sont pas un chemin fiable pour une réplication multimaître sur des ports RPC dynamiques.

Comment le ZTNA gère-t-il les plages d'adresses IP qui se chevauchent ?

Les applications sont publiées par leur nom, et le connector résout l'adresse au sein de son propre réseau. Deux organisations peuvent toutes deux utiliser 10.1.1.0/24 en interne sans conflit, ce qui évite du NAT des deux côtés ou un projet de renumérotation lors d'une fusion.

Un connector ZTNA a-t-il besoin de ports entrants ouverts ?

Non. Une passerelle site-to-site écoute sur UDP 500 et 4500. Un connector ZTNA établit des connexions chiffrées sortantes vers le broker, généralement sur le port 443, de sorte que le site n'expose aucun service en écoute que des scanners Internet pourraient trouver.

Le SD-WAN peut-il remplacer le ZTNA pour sécuriser les agences ?

Non. Le SD-WAN est une technologie de transport. Il choisit le meilleur lien et chiffre le trafic entre les sites, mais il produit toujours un réseau routé avec le même risque de mouvement latéral. Il ne devient une architecture de sécurité qu'en combinaison avec un accès fondé sur l'identité, la sécurité web et le pare-feu dans une plateforme SASE.

Comment donner à un prestataire de maintenance l'accès aux systèmes de production sans tunnel ?

Placez un connector ZTNA à côté d'un jump host dans une zone distincte. Le prestataire se connecte avec une authentification multifacteur, n'atteint que ce jump host via le broker et administre les contrôleurs depuis celui-ci. Il n'existe aucun chemin réseau entre le prestataire et le réseau de production.