Quels sont les risques de sécurité liés au fractionnement des tunnels VPN ?
La tunnellisation fractionnée fait passer une partie du trafic par le VPN et envoie le reste directement sur l’internet. Il en résulte quatre risques : la fuite de DNS qui expose les noms d’hôtes internes, la diffusion de logiciels malveillants via le chemin non protégé, l’exfiltration de données par des connexions directes à l’internet et les réseaux domestiques compromis qui se connectent aux systèmes de l’entreprise. Dans le cadre du NIS2, ces angles morts violent les exigences de l’article 21 en matière de contrôle d’accès et de gestion des risques. ZTNA élimine entièrement le dilemme en remplaçant le tunnel par un accès basé sur l’identité et par application.
La séparation des tunnels a commencé comme une solution de performance. Pendant la pandémie, les concentrateurs VPN ont plié sous le poids des configurations à tunnel complet, et Microsoft a recommandé d’acheminer le trafic des équipes autour du tunnel pour réduire la latence. Ce conseil avait du sens lorsque la priorité était de maintenir les appels vidéo. Il a moins de sens maintenant que les auditeurs NIS2 posent des questions précises sur la visibilité du trafic et le contrôle d’accès.
Le problème est simple. Chaque paquet qui contourne votre VPN contourne également votre pile de sécurité. Pas d’inspection de pare-feu, pas de filtrage de passerelle web, pas de contrôles DLP. Pour les responsables informatiques qui utilisent encore des configurations de tunnel divisé, la question n’est plus de savoir si cela crée un risque. C’est le cas. La question est de savoir si vous pouvez défendre cette configuration lors d’un audit de conformité NIS2.
Qu’est-ce que le split tunnelling et pourquoi les équipes informatiques l’utilisent-elles ?
Le tunnelage fractionné divise le trafic réseau au niveau du point d’extrémité. Certains paquets transitent par le tunnel VPN crypté jusqu’à la passerelle de l’entreprise. Les autres vont directement sur l’internet via la connexion locale de l’utilisateur.
Il existe trois configurations courantes. Le tunnel complet fait transiter tout le trafic par le VPN, ce qui permet à l’équipe de sécurité d’avoir une visibilité totale, mais augmente la latence et sollicite la bande passante. Le tunnel divisé (basé sur l’inclusion) n’achemine que le trafic destiné à des plages d’adresses IP spécifiques de l’entreprise à travers le VPN, tandis que tout le reste du trafic est acheminé directement. Le tunnel inversé (basé sur l’exclusion) envoie tout via le VPN sauf les destinations explicitement exclues comme Microsoft 365 ou Zoom.
Les équipes informatiques mettent en place un tunnel divisé pour des raisons pratiques. Les configurations à tunnel complet acheminent le trafic lié au cloud via une passerelle centrale, ce qui ajoute une latence qui nuit à la qualité des appels vidéo et ralentit les applications SaaS. Lorsque votre employé basé à Bruxelles a besoin d’accéder aux serveurs Microsoft 365 à Amsterdam, acheminer ce trafic via un concentrateur VPN à Anvers est une perte de temps. Le fractionnement des tunnels résout le problème de performance.
En contrepartie, vous perdez la visibilité sur tout ce qui est direct.
Les risques de sécurité sous-estimés par les équipes informatiques
La tunnellisation fractionnée crée un point d’extrémité à double appartenance. L’appareil se trouve à la fois sur le réseau de l’entreprise (via le VPN) et sur le réseau local, quel qu’il soit, à partir duquel l’utilisateur se connecte. Cette combinaison est à l’origine de tous les risques ci-dessous.
Les fuites de DNS exposent votre infrastructure interne
Lorsque la tunnellisation fractionnée est active, les requêtes DNS pour des destinations non professionnelles sont souvent résolues par le serveur DNS du réseau local au lieu du résolveur de l’entreprise. Cela entraîne des fuites de noms d’hôtes internes et révèle la structure de votre réseau à toute personne surveillant le trafic DNS local.
Un routeur domestique compromis peut exploiter cette situation en détournant le DNS, en redirigeant l’utilisateur vers une page de connexion falsifiée pour les services de l’entreprise. Comme la requête voyage en dehors du tunnel VPN, aucun de vos contrôles de sécurité ne la voit. L’utilisateur saisit ses informations d’identification sur ce qui semble être une page légitime, et l’attaquant les récupère. Notre guide sur la sécurité DNS dans le cadre de la confiance zéro couvre ce vecteur d’attaque en détail.
Les logiciels malveillants pénètrent par le chemin non protégé
Un utilisateur naviguant sur le web en dehors du tunnel télécharge un fichier malveillant. La passerelle Web sécurisée de l’entreprise ne le voit jamais, car ce trafic contourne entièrement le VPN. Une fois le logiciel malveillant exécuté, il a deux options : exfiltrer les données directement via la connexion internet non protégée ou passer par le tunnel VPN actif pour pénétrer dans le réseau de l’entreprise.
Le deuxième scénario est le plus dangereux. Le tunnel VPN est authentifié et fiable. Les logiciels malveillants qui empruntent ce tunnel ont l’air d’un trafic interne légitime. Les équipes de sécurité qui surveillent le concentrateur VPN voient des connexions d’apparence normale provenant d’un utilisateur de confiance, alors que la compromission initiale s’est produite entièrement en dehors de leur champ de vision.
Exfiltration de données via des connexions directes à l’internet
Toute application s’exécutant en dehors du tunnel peut envoyer des données directement sur l’internet sans passer par les contrôles DLP. Un utilisateur qui copie des fichiers sensibles sur un compte personnel de stockage en nuage, une extension de navigateur compromise qui télécharge des jetons de session, un enregistreur de frappe qui envoie des informations d’identification à un serveur de commande et de contrôle, tout cela se produit de manière invisible lorsque la tunnellisation fractionnée est active.
Le rapport sur les risques liés aux anciens VPN montre comment les mouvements latéraux après la compromission initiale du VPN sont devenus le modèle d’attaque dominant dans les incidents de ransomware au Benelux.
Les réseaux domestiques compromis deviennent un pont
Les appareils connectés au VPN sur les réseaux résidentiels partagent ce réseau avec des téléviseurs intelligents, des appareils IoT, des consoles de jeu pour enfants et d’autres points d’extrémité avec une sécurité minimale. Un attaquant qui compromet n’importe quel appareil sur le réseau domestique peut potentiellement atteindre l’ordinateur portable professionnel connecté au VPN.
Lorsque le tunnelage fractionné est actif, l’attaquant peut utiliser l’ordinateur portable professionnel comme pont. Le trafic provenant du réseau domestique compromis atteint l’environnement de l’entreprise par le biais du tunnel VPN authentifié. L’incident du ransomware de l’hôpital AZ Monica en janvier 2026 a illustré la vulnérabilité des réseaux de santé lorsque les architectures d’accès à distance permettent ce type de pontage latéral.
Lorsque le split tunnelling est en conflit avec NIS2
L’article 21, paragraphe 2, de la NIS2 énumère les mesures minimales de cybersécurité que les organisations doivent mettre en œuvre. Les tunnels fractionnés sont en contradiction avec au moins quatre de ces exigences.
Article 21, paragraphe 2, point a) : analyse des risques et politiques de sécurité des systèmes d’information. Vous ne pouvez pas effectuer une analyse de risque adéquate sur un trafic que vous ne pouvez pas voir. La tunnellisation fractionnée achemine délibérément une partie du trafic des terminaux en dehors de votre périmètre de surveillance. Un auditeur vous demandera quel pourcentage du trafic de vos utilisateurs distants contourne vos contrôles de sécurité. Si la réponse est supérieure à zéro, vous avez besoin d’une justification documentée.
Article 21, paragraphe 2, point e) : sécurité dans l’acquisition, le développement et la maintenance des réseaux et des systèmes d’information. L’exploitation d’une infrastructure VPN présentant des faiblesses architecturales connues, alors que la communauté des fournisseurs a largement reconnu ces faiblesses et proposé des solutions de remplacement, est difficile à défendre en tant que mesure proportionnée. La chronologie de la suppression du VPN SSL par les fournisseurs montre à quel point l’industrie s’éloigne rapidement de l’accès à distance traditionnel.
Article 21, paragraphe 2, point g) : pratiques de base en matière de cyberhygiène et formation à la cybersécurité. Le NIS2 fait explicitement référence aux principes de la confiance zéro dans le cadre d’une bonne cyberhygiène. Le tunnelage fractionné fonctionne sur la base d’une confiance implicite : une fois le tunnel établi, les décisions d’acheminement du trafic sont prises sans vérification continue. C’est le contraire de la confiance zéro.
Article 21, paragraphe 2, point i) : politiques de contrôle d’accès. Les VPN accordent généralement un accès au niveau du sous-réseau après authentification. Le fractionnement des tunnels ajoute une autre couche de faiblesse en permettant aux points d’extrémité de maintenir des connexions non contrôlées parallèlement à cet accès déjà large. Les auditeurs attendent l’application du principe du moindre privilège, et non des exceptions architecturales qui élargissent la surface d’attaque.
Le guide de mise en œuvre technique de l’ENISA, publié en juin 2025 pour soutenir le règlement d’application (UE) 2024/2690, traite directement de la sécurité de l’accès à distance. Ces orientations recommandent aux entités de désactiver ou de restreindre le fractionnement des tunnels pour l’accès à distance, en partant du principe que tout le trafic provenant d’appareils externes doit passer par les contrôles de sécurité de l’organisation. Pour les entités des secteurs réglementés par le NIS2, le fait d’ignorer ces orientations crée une lacune directe en matière de conformité.
Comment les niveaux de CyFun s’adressent à la configuration VPN en Belgique
Le cadre belge CyberFundamentals (CyFun) traduit le NIS2 en contrôles pratiques. La date limite d’avril 2026 pour la soumission d’auto-évaluations à la CCB signifie que les configurations VPN sont maintenant examinées de près.
Au niveau CyFun Basic, les organisations doivent démontrer que l’accès à distance est authentifié et crypté. Le tunnelling fractionné n’enfreint pas intrinsèquement cette exigence, mais la charge de documentation augmente car vous devez justifier pourquoi certains trafics sont exclus du cryptage et de l’inspection.
Aux niveaux Important et Essentiel de la CyFun, les exigences sont plus strictes. Les mesures de contrôle d’accès doivent suivre les principes du moindre privilège et le trafic réseau doit être surveillé pour détecter les anomalies. Le fractionnement des tunnels compromet ces deux aspects : il accorde un accès plus large que nécessaire en autorisant des connexions internet non contrôlées parallèlement à l’accès de l’entreprise, et il crée des angles morts dans la surveillance du trafic.
Les contrôles de la fonction Protect de CyFun (PR.AC-3, PR.AC-4) exigent des preuves documentées que l’accès est limité à ce dont chaque rôle a besoin. Une configuration VPN qui permet de diviser les tunnels est plus difficile à documenter comme étant conforme parce que vous excluez délibérément le trafic de votre cadre de contrôle. Le guide d’auto-évaluation de la CyFun décrit les attentes des évaluateurs.
Les organisations qui cherchent à obtenir la vérification de la CyFun constateront qu’une plateforme de sécurité consolidée génère les preuves dont les auditeurs ont besoin de manière bien plus efficace qu’une pile fragmentée avec des exceptions VPN documentées dans des feuilles de calcul.
Comment ZTNA élimine le dilemme des tunnels fractionnés
Le débat sur le fractionnement du tunnel existe en raison d’une limitation du VPN : le tunnel est tout ou rien au niveau du réseau, de sorte que vous pouvez soit tout acheminer à travers lui (lent), soit exempter une partie du trafic (risqué). Le ZTNA supprime entièrement le tunnel, ce qui rend le dilemme sans objet.
Avec ZTNA, il n’y a pas de tunnel à diviser. Les utilisateurs se connectent directement aux applications spécifiques auxquelles ils sont autorisés à accéder, après vérification de l’identité et de la position de l’appareil à chaque demande. Le trafic vers les applications en nuage telles que Microsoft 365 est direct, sans détour par une passerelle centrale, mais il passe tout de même par une passerelle Web sécurisée native qui inspecte et applique la politique. Vous bénéficiez des performances d’un accès direct et de la sécurité d’une visibilité totale. Aucun compromis n’est nécessaire.
Le ZTNA de Jimber remplace entièrement le tunnel. Les utilisateurs se connectent aux applications dont ils ont besoin, après vérification de l’identité et de l’état de l’appareil, sans acheminer l’ensemble du trafic via une passerelle centrale. Il n’y a pas de concentrateur VPN écoutant sur l’internet public, donc pas de cible pour le balayage de port ou l’exploitation de type « zero-day ». Chaque connexion d’application est autorisée individuellement. Même si un appareil est compromis par une attaque du réseau local, l’attaquant ne peut pas passer à d’autres systèmes car ceux-ci sont invisibles et inaccessibles.
Le SWG de Jimber inspecte l’ensemble du trafic web, quelle que soit la localisation de l’utilisateur, comblant ainsi le manque de visibilité créé par le split tunnelling. Chaque demande d’accès est enregistrée avec l’identité de l’utilisateur, l’état de l’appareil, la cible de l’application et la décision politique. C’est précisément la piste d’audit que les évaluateurs NIS2 attendent, et elle est générée automatiquement plutôt qu’assemblée manuellement à partir de plusieurs outils.
Pour les responsables informatiques qui effectuent la migration du VPN vers ZTNA, la question de la séparation des tunnels disparaît dès le premier jour du projet pilote. Les premières applications publiées via ZTNA bénéficient immédiatement d’un accès granulaire et d’une journalisation complète, tandis que l’accès VPN traditionnel peut fonctionner en parallèle jusqu’à la fin de la migration.
Questions fréquemment posées
Le split tunnelling est-il toujours acceptable sous NIS2 ?
Le NIS2 n’interdit pas explicitement le split tunnelling par son nom. Les exigences de l’article 21 en matière de contrôle d’accès, de gestion des risques et de surveillance du trafic sont difficiles à satisfaire lorsqu’une partie du trafic des terminaux est invisible pour votre pile de sécurité. Si vous maintenez la séparation des tunnels, attendez-vous à devoir documenter une évaluation détaillée des risques justifiant l’exception.
Microsoft recommande-t-il toujours le split tunnelling pour Teams ?
Les recommandations initiales de Microsoft sur le tunnelling divisé, datant de 2020, étaient une réponse aux contraintes de capacité des VPN pendant la pandémie. La recommandation concernait spécifiquement le trafic multimédia de Teams, qui est déjà crypté au niveau de la couche application. Depuis, Microsoft a introduit des fonctionnalités telles que Global Secure Access qui achemine le trafic via des contrôles de sécurité dans le nuage sans nécessiter de tunnellisation VPN traditionnelle. La solution de contournement de l’époque de la pandémie n’est plus la seule option.
En quoi le ZTNA gère-t-il le trafic Microsoft 365 différemment du VPN à tunnel divisé ?
Avec le VPN à tunnel divisé, le trafic M365 va directement aux serveurs Microsoft sans aucune inspection de sécurité. Avec ZTNA et un SWG « cloud-native », le trafic M365 est toujours direct (pas de backhaul via une passerelle centrale), mais il passe par une application des politiques qui vérifie la perte de données, les logiciels malveillants et les violations de la conformité. Même performance, posture de sécurité différente.
Est-il possible de désactiver la tunnellisation fractionnée sans nuire aux performances ?
Pas avec un VPN traditionnel. Les configurations avec tunnel complet obligent tout le trafic à passer par le concentrateur, ce qui augmente la latence et crée un goulot d’étranglement au niveau de la bande passante. C’est pourquoi le ZTNA est la solution pratique : il élimine complètement le besoin d’un tunnel, de sorte qu’il n’y a pas de pénalité de performance à éviter. La comparaison entre le VPN IPsec et le ZTNA met en évidence les différences de performances.
Que dois-je vérifier en premier lieu si j’utilise actuellement un tunnel divisé ?
Commencez par la configuration DNS. Vérifiez si les points d’extrémité de votre tunnel partagé utilisent le DNS de l’entreprise ou des résolveurs locaux. Si les requêtes DNS fuient vers les résolveurs locaux, la structure de votre réseau interne est exposée. Vérifiez ensuite quelles applications sont exclues du tunnel et évaluez si certaines d’entre elles traitent des données sensibles. Documentez ces résultats, car un évaluateur CyFun vous les demandera.
En combien de temps puis-je passer d’un VPN à tunnel divisé à ZTNA ?
Une approche progressive est typique. Publiez d’abord deux ou trois applications à faible risque via ZTNA, validez l’expérience de l’utilisateur, puis étendez la couverture application par application. La plupart des entreprises de taille moyenne achèvent la migration en quelques semaines, et non en quelques mois. VPN et ZTNA fonctionnent en parallèle pendant la transition, de sorte qu’il n’y a pas de coupure brutale.
Prêt à combler le fossé des tunnels fractionnés avant la date limite de CyFun ? Réservez une démonstration et découvrez comment Jimber remplace une protection VPN partielle par une ZTNA à visibilité totale dans une plateforme unique gérée dans le cloud.
