Pourquoi le VPN full tunnel est un modèle à bout de souffle
Un VPN d'accès distant fait deux choses simultanément, et c'est exactement ce qui complique sa migration. Il transporte l'accès aux ressources internes — partages SMB, RDP, applications métier, Domain Controllers — et, dans la quasi-totalité des configurations auditées, il rapatrie aussi le trafic Internet des postes distants vers le datacenter pour le faire transiter par le Proxy et le Firewall d'entreprise. Ce backhaul explique pourquoi les utilisateurs se plaignent de la latence sur Teams depuis des années : chaque paquet SaaS fait un aller-retour inutile vers le site central.
Global Secure Access est la plateforme SSE de Microsoft. Ce terme couvre deux produits distincts qu'il faut absolument dissocier avant de commencer :
- Entra Private Access : le ZTNA, qui accorde un accès par application aux ressources privées sans jamais exposer le réseau sous-jacent. C'est lui, et lui seul, qui remplace le VPN.
- Entra Internet Access : le Secure Web Gateway identity-aware, qui filtre et inspecte le trafic vers Internet et les SaaS. Il remplace le Proxy sortant que votre VPN alimentait en backhaul — pas le VPN lui-même.
Les deux produits s'appuient sur le même client et le même réseau mondial Microsoft, réparti sur plus de 70 régions et 190 points de présence en edge. La différence fondamentale avec le VPN tient en une phrase : le VPN accorde un accès réseau, Private Access accorde un accès applicatif. Vous ne publiez plus un sous-réseau en /24, vous publiez un FQDN, un port et un protocole, auxquels vous attachez une Conditional Access.
Vocabulaire à retenir
Global Secure Access est le terme parapluie et le nom du portail dans le centre d'administration Entra. Internet Access et Private Access sont les deux produits sous-jacents. Beaucoup de projets confondent les trois et déploient le SWG en croyant remplacer le VPN. Vous déployez les deux, mais pas pour la même raison.
Prérequis : licences, rôles et infrastructure
Avant d'exécuter la moindre commande, validez chaque point de cette liste. Un prérequis manqué en production coûte plusieurs heures de diagnostic.
| Élément | Détail |
|---|---|
| Licences | Entra ID P1 ou P2 obligatoire. Par-dessus : add-on Entra Private Access seul, ou Entra Suite (embarque Private Access, Internet Access, ID Governance, ID Protection, Verified ID). Depuis le 1er mai 2026, Microsoft 365 E7 inclut l'Entra Suite. Vérifiez les tarifs actuels sur la page pricing Microsoft. |
| Rôles Entra | Global Secure Access Administrator ET Application Administrator simultanément. Un seul des deux ne suffit pas pour activer les profils. |
| Serveur connecteur | Windows Server 2016 minimum (2022 ou 2025 recommandé), joint au domaine, .NET 4.7.2 ou supérieur, TLS 1.2 activé. Sortie 80/TCP et 443/TCP vers les endpoints Microsoft. Aucun port entrant à ouvrir. |
| Postes clients | Windows 10 ou 11 64 bits, Entra joined ou Hybrid joined. Un poste simplement registered ne fonctionne pas. |
| DNS interne | Suffixes DNS de chaque forêt AD hébergeant des utilisateurs synchronisés, documentés et prêts à être déclarés. |
| Remote Network Connectivity | Minimum 50 licences P1 et Internet Access combinées sur le tenant pour la connectivité site-to-site. |
Étape 1 — Cartographier les flux réellement portés par le VPN
Aucune commande Azure dans cette étape, et pourtant c'est elle qui conditionne la réussite du projet. Vous ne pouvez pas publier en per-app access ce que vous n'avez pas identifié. Extrayez la configuration du concentrateur VPN, listez chaque règle et traduisez-la en triplet applicatif : FQDN ou plage IP, port, protocole.
Trois catégories émergent de cet exercice :
- Flux applicatifs identifiés : une application, un port, un usage connu → per-app access à l'étape 4.
- Flux d'infrastructure : Domain Controllers, DNS, serveurs de fichiers, outils d'administration → traitement à l'étape 5.
- Flux orphelins : règles dont personne ne connaît l'usage → ne migrez pas par défaut. Instrumentez, observez le trafic réel pendant deux semaines, puis décidez.
Croisez config déclarative et logs de flux
Sur un audit en environnement industriel, l'écart entre la configuration déclarée du concentrateur et le trafic réellement observé dans les logs Firewall représentait 11 règles sur 19 — plus de la moitié des accès réseau larges ne servaient plus à rien. Ne vous fiez jamais à la configuration seule.
Livrable de validation : un tableau où chaque ligne porte un nom applicatif, un ou plusieurs segments (FQDN ou IP + port + protocole), une population utilisatrice, et une catégorie parmi applicatif, infrastructure ou orphelin. Aucune ligne sans population identifiée. Ce tableau devient votre plan de publication.
Étape 2 — Activer Global Secure Access et les traffic forwarding profiles
Direction le centre d'administration Entra, section Global Secure Access. L'activation se fait profil par profil. Commencez par le profil Microsoft 365 : c'est le moins risqué et il sert de canari pour valider que l'acquisition de trafic fonctionne avant de toucher au reste.
Piège de l'assignation par défaut
Quand vous activez un traffic forwarding profile sans préciser de scope, il s'applique par défaut à tous les utilisateurs du tenant. Sur un pilote, c'est exactement ce que vous ne voulez pas. Assignez le profil à un groupe de pilotes AVANT de l'activer, jamais après. Cette inversion d'ordre est la cause n°1 des incidents en début de projet.
Le profil Private Access s'active depuis Global Secure Access > Connect > Traffic forwarding. Vous pouvez automatiser la lecture de l'état via Microsoft Graph pour intégrer la configuration dans votre IaC ou vos contrôles de conformité. Le module requis est Microsoft.Graph (version 2.x recommandée).
1# Module requis : Microsoft.Graph (Install-Module Microsoft.Graph)2Connect-MgGraph -Scopes "NetworkAccess.Read.All", "NetworkAccess.ReadWrite.All"3 4# Lecture de l'état des trois profils de forwarding5$uri = "https://graph.microsoft.com/beta/networkAccess/forwardingProfiles"6(Invoke-MgGraphRequest -Method GET -Uri $uri).value |7 Select-Object name, state, trafficForwardingTypeSortie attendue :
1name state trafficForwardingType2---- ----- ---------------------3Microsoft 365 enabled m3654Private access enabled private5Internet access disabled internetValidation : le profil Private access est en enabled, assigné au seul groupe de pilotes. Le profil Internet access reste en disabled jusqu'à l'étape 7. N'activez jamais les deux le même jour : vous perdriez toute capacité de diagnostic différentiel.
Étape 3 — Déployer les Private Network Connectors en haute disponibilité
Le connecteur établit une connexion sortante depuis l'intérieur de votre réseau vers le service Microsoft, puis relaie le trafic vers les ressources publiées. Aucun port entrant n'est ouvert sur le Firewall — c'est l'argument sécurité décisif face à un concentrateur VPN exposé sur Internet.
Téléchargez le connecteur depuis Global Secure Access > Connect > Connectors and sensors > Private Network Connectors. Depuis 2026, il est également disponible en preview sur les marketplaces Azure, AWS et GCP sous forme de VM Windows avec le connecteur pré-installé.
Jamais un connecteur unique
Un Connector Group avec un seul connecteur constitue un SPOF sur votre accès distant complet. Déployez systématiquement deux connecteurs par groupe, sur deux hyperviseurs distincts. Pensez également à étendre la plage de ports éphémères TCP et UDP sur le serveur connecteur : la configuration Windows par défaut sature sur les déploiements à forte densité d'utilisateurs.
Segmentez vos Connector Groups par zone réseau, pas par application : un groupe pour le datacenter principal, un pour le site secondaire, un pour la zone industrielle si elle est cloisonnée. Ce découpage permet de router chaque application vers les connecteurs qui la joignent réellement.
1# Sur le serveur connecteur — les deux services doivent être en Running2Get-Service -Name "WAPCSvc", "WAPCUpdaterSvc" |3 Select-Object Name, Status, StartType4 5# Vérifier la connectivité sortante 443 vers les endpoints d'enregistrement6Test-NetConnection -ComputerName "connectorregistration.msappproxy.net" -Port 4437Test-NetConnection -ComputerName "login.microsoftonline.com" -Port 443Validation : les services WAPCSvc et WAPCUpdaterSvc sont en Running sur chaque serveur. Dans le portail Entra, chaque connecteur remonte en statut Active avec un horodatage récent. Si un connecteur reste en Inactive plus de cinq minutes après l'installation, vérifiez le 443 sortant sur le Firewall — c'est la cause dans 100 % des cas rencontrés en production.
Étape 4 — Publier les applications privées en per-app access
Deux mécanismes de publication coexistent. Quick Access regroupe un ensemble de FQDN et plages IP dans une Enterprise Application unique. Per-app access crée une Enterprise Application par application métier, avec ses propres segments et sa propre Conditional Access.
Quick Access est présenté comme point d'entrée naturel pour un scénario de remplacement VPN, mais il reproduit exactement le défaut du VPN : un périmètre large, une seule policy, une seule population. Réservez Quick Access à l'infrastructure DNS et Kerberos de l'étape suivante. Tout le reste part directement en per-app access, en créant une application par ligne du tableau établi à l'étape 1.
Création depuis Global Secure Access > Applications > Enterprise applications : nommez l'application, choisissez le Connector Group qui dessert la zone réseau concernée, puis ajoutez les segments.
Les groupes imbriqués ne sont pas supportés
Les utilisateurs doivent être assignés directement à l'application, ou à un groupe lui-même assigné directement. Un groupe imbriqué dans un autre groupe assigné ne fonctionne pas. Si votre modèle d'habilitation AD repose sur des groupes en cascade, prévoyez des groupes plats dédiés à la publication avant le jour du pilote.
Pour les applications qui s'appuient sur l'adresse IP de sortie du connecteur pour leur authentification ou leurs ACL, activez la session persistence — cas typique des applications métier legacy qui filtrent par adresse source.
Validation : depuis un poste pilote avec le client installé, l'accès à l'application publiée fonctionne. Dans Global Secure Access > Monitor > Traffic logs, vous observez les connexions avec l'action Allow et le bon nom d'application. Comptez jusqu'à 20 minutes de délai d'apparition dans les logs. Vérifiez également que la colonne Through Global Secure Access affiche Yes dans les Sign-in logs.
Étape 5 — Configurer le Private DNS et le SSO Kerberos
C'est l'étape où les projets déraillent. Publier une application ne sert à rien si le poste distant ne résout pas son nom interne. Et sans accès aux Domain Controllers, aucun ticket Kerberos — donc aucun SSO sur les partages et applications intégrées à l'AD.
Activer le Private DNS
Depuis Global Secure Access > Applications > Quick Access, onglet Private DNS, activez la fonctionnalité et déclarez au minimum les suffixes de premier niveau de chaque forêt AD hébergeant des utilisateurs synchronisés.
Publier les Domain Controllers via Quick Access
Créez une application dédiée exposant les ports d'authentification AD :
88/TCP— Kerberos389/TCP— LDAP445/TCP— SMB135/TCP— RPC endpoint mapper
Si vous déployez des Private Access Sensors directement sur les DC pour l'authentification renforcée côté contrôleur, ouvrez également le port 1337/TCP entrant dans le Firewall Windows des DC — c'est un prérequis propre au sensor.
Le piège NRPT qui casse tout, en silence
Le client Windows configure des règles NRPT locales sur le poste pour rediriger les requêtes DNS vers le Private DNS. Si des règles NRPT sont poussées par GPO, elles écrasent les règles locales du client et le Private DNS ne fonctionne tout simplement pas. Aucune erreur, aucune alerte : la résolution échoue silencieusement. Auditez vos GPO avant de lancer le pilote. C'est la cause identifiée sur 4 des 5 projets de décommissionnement VPN observés en production.
Autre subtilité de production : le negative cache Kerberos. Quand le système demande un ticket pour un SPN et échoue, Windows met ce SPN en cache négatif. Vous corrigez la publication du Domain Controller, tout est correct côté portail, mais le poste continue d'échouer. Il faut purger le cache avec klist purge ou redémarrer la session.
1# 1. Règles NRPT actives sur le poste (locales ET issues de GPO)2Get-DnsClientNrptPolicy | Select-Object Namespace, NameServers3Get-DnsClientNrptRule | Select-Object Name, Namespace, NameServers4 5# 2. Résolution d'un nom interne via le Private DNS6Resolve-DnsName -Name "dc01.corp.local"7 8# 3. Purger le cache Kerberos avant tout re-test (negative cache)9klist purge10klist get host/dc01.corp.localValidation : depuis un poste distant hors réseau d'entreprise, Resolve-DnsName résout un nom interne et klist affiche un ticket TGS valide pour le SPN visé. Un accès à un partage SMB via \\serveur\partage s'ouvre sans demander de credentials. Si l'authentification tombe en NTLM au lieu de Kerberos, la publication des Domain Controllers est incomplète — vérifiez le port 88/TCP.
Étape 6 — Déployer le client et neutraliser les conflits réseau
Le client se déploie par Intune en mode silencieux sur le parc pilote. Il embarque le runtime .NET nécessaire, mais validez votre baseline avant un déploiement de masse. Le travail principal de cette étape n'est pas l'installation : c'est la neutralisation des mécanismes réseau qui entrent en conflit avec l'acquisition de trafic.
Quatre points critiques à traiter :
- DNS sécurisé (DoH/DoT/DNSSEC) : le client ne supporte aucun de ces modes. Vous devez les désactiver, sinon l'acquisition de trafic ne s'effectue pas.
- DNS sur TCP : le client ne gère pas le port 53 en TCP, or les navigateurs modernes embarquent leur propre client DNS qui l'utilise. Désactivez-le par registre.
- IPv6 : le client ne tunnelise que l'IPv4 et laisse passer l'IPv6 en direct. Sur un poste où l'IPv6 est actif et préféré, une partie du trafic échappe à votre policy.
- Microsoft Tunnel : la coexistence n'est pas supportée. Traitez ce point avant de démarrer la migration, pas pendant.
1# Désactiver le client DNS interne d'Edge (machine)2New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" `3 -Name "BuiltInDnsClientEnabled" -Value 0 -PropertyType DWord -Force4 5# Idem pour Chrome (utilisateur courant)6New-ItemProperty -Path "HKCU:\Software\Policies\Google\Chrome" `7 -Name "BuiltInDnsClientEnabled" -Value 0 -PropertyType DWord -Force8 9# Préférer IPv4 sans désactiver IPv610# DisabledComponents = 0x20 : préfère IPv4 sur IPv611# Microsoft déconseille de couper IPv6 complètement12New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `13 -Name "DisabledComponents" -Value 0x20 -PropertyType DWord -ForceTout utilisateur peut désactiver le client par défaut
Sans configuration supplémentaire, un utilisateur sans droits d'administration peut désactiver le client Global Secure Access depuis l'icône de la barre des tâches — ce qui revient à contourner votre Conditional Access d'un clic droit. Une clé de registre permet d'interdire cette action aux non-administrateurs. Poussez-la au passage en production, pas en phase pilote où vous avez besoin de cette soupape de secours.
Validation : dans l'outil de diagnostic avancé du client, l'onglet Connections affiche le trafic acquis et l'état des canaux. Testez spécifiquement le scénario veille-reprise réseau : c'est lui, et non le premier démarrage, qui révèle les conflits DNS résiduels.
Étape 7 — Activer Internet Access et le filtrage web
L'accès privé est stabilisé. Activez maintenant le profil Internet Access pour reprendre le trafic que votre VPN backhaulait vers le Proxy du datacenter.
La chaîne de policy se lit dans cet ordre :
- Une web content filtering policy définit des règles d'autorisation ou de blocage par catégorie, FQDN ou URL.
- Ces policies s'agrègent dans un security profile.
- Le security profile se rattache à une Conditional Access ciblée sur une population.
Le baseline profile est un cas à part : il s'applique à tout le trafic Internet tunnelisé sans passer par une Conditional Access. Réservez-le aux protections non négociables à l'échelle de l'organisation.
Connaissez vos quotas avant de concevoir le modèle de policy :
- 256 security profiles par tenant
- 1 000 policies
- 1 000 règles
- 8 000 destinations toutes catégories confondues (IP, FQDN, URL, catégorie web)
- TLS inspection : 100 policies, 1 000 règles, 8 000 destinations
Deux comportements à briefer au support N1
Premièrement : le filtrage par méthode HTTP nécessite la TLS inspection pour le trafic HTTPS. Sans inspection, seules les règles basées sur le SNI s'appliquent — votre filtrage URL fin est inopérant sur du HTTPS. Deuxièmement : un blocage en HTTPS se présente côté utilisateur comme une erreur de réinitialisation de connexion, pas comme une page de blocage explicite. Sans ce brief au support N1, vous recevez une vague de tickets « Internet est cassé » dès le premier jour.
Un gain additionnel accessible via ce chantier : les Universal Tenant Restrictions. Ce mode d'application de Tenant Restrictions v2 bloque l'usage d'identités de tenants externes non autorisés sur vos postes gérés. Il nécessite uniquement Entra ID P1 ou P2 et s'appuie sur le profil de forwarding Microsoft 365 du client Global Secure Access pour taguer le trafic sans aucun Proxy. C'est votre contrôle anti-exfiltration vers les tenants non autorisés — une capacité qu'aucun VPN n'offrait.
Validation : depuis un poste pilote, un site d'une catégorie bloquée est inaccessible et un site autorisé s'ouvre normalement. Dans les Traffic logs filtrés sur Action = Block, vous retrouvez les tentatives avec le bon User Principal Name. Vérifiez surtout qu'aucun flux métier légitime ne remonte en Block : c'est le faux positif de catégorisation qui fait échouer les déploiements de SWG.
Étape 8 — Verrouiller par Conditional Access et décommissionner le VPN
Tant qu'aucune Conditional Access ne conditionne l'accès aux applications privées, vous avez remplacé un tunnel par un autre. C'est maintenant que vous récupérez la valeur du projet.
Private Access s'intègre à la Conditional Access en ciblant l'Enterprise Application comme ressource. Construisez des policies par application, avec les conditions adaptées au niveau de sensibilité réel : conformité de l'appareil, force de la méthode MFA, risque utilisateur, risque de connexion, emplacement nommé. L'application de paie n'a pas besoin des mêmes contrôles que l'intranet — et c'est précisément ce que le VPN ne savait pas faire.
Ordre de bascule non négociable
Ne coupez jamais le VPN tant que la cohorte n'est pas validée sur Global Secure Access. La bascule se fait par vagues : pilote IT, puis deux directions métier, puis élargissement. Sur chaque vague, laissez le VPN accessible en repli pendant deux à trois semaines. Ne retirez les droits VPN d'un utilisateur qu'après une période complète sans ticket. Le concentrateur ne s'éteint qu'une fois le dernier utilisateur migré. Pas l'inverse.
Le décommissionnement du concentrateur est l'occasion de fermer les ports entrants correspondants sur le Firewall périmétrique. C'est la partie la plus visible du chantier pour le RSSI : la surface d'exposition externe qui disparaît. Un concentrateur VPN publié sur Internet est une cible permanente. Après bascule, tous les flux sont sortants — plus rien à attaquer de ce côté.
Validation : chaque application publiée porte une Conditional Access nommée et testée, y compris dans son cas de refus — un poste non conforme doit être bloqué et vous devez l'avoir vérifié. Les Sign-in logs affichent l'évaluation de la policy sur chaque accès. Les règles entrantes du concentrateur VPN sont fermées sur le Firewall, et l'inventaire de l'étape 1 est intégralement couvert ou explicitement abandonné pour les flux orphelins.
Checklist de validation finale et points de vigilance
Le déploiement est complet quand un utilisateur distant travaille exactement comme au bureau, sans jamais monter de tunnel, avec des contrôles plus fins que ceux qu'autorisait le VPN.
Checklist de validation production :
- Chaque flux de l'inventaire VPN est publié en per-app access, ou explicitement abandonné et documenté
- Chaque Connector Group compte au moins deux connecteurs actifs sur des hyperviseurs distincts
- La résolution DNS interne fonctionne depuis un poste distant, sans règle NRPT poussée par GPO en conflit
- Le SSO Kerberos est effectif : ticket TGS obtenu, accès SMB sans ré-authentification
- Le DNS sécurisé et le client DNS interne des navigateurs sont désactivés sur le parc
- Le comportement IPv6 est maîtrisé, aucun flux métier n'échappe au tunnel
- Le profil Internet Access est actif, avec un baseline profile et des security profiles liés à des Conditional Access
- Aucun faux positif de catégorisation ne bloque un flux métier légitime
- Chaque application privée porte une Conditional Access testée en autorisation ET en refus
- La désactivation du client est interdite aux utilisateurs non administrateurs
- Les Universal Tenant Restrictions sont configurées si le besoin anti-exfiltration existe
- Les ports entrants du concentrateur VPN sont fermés sur le Firewall périmétrique
Intelligent Local Access permet au client de détecter, via des sondes DNS, qu'il se trouve déjà sur le réseau interne, et de router le trafic localement plutôt que de le faire remonter vers l'edge Microsoft. C'est un gain de latence réel sur les sites à fort trafic local, qui évite le hairpinning. Contrainte à connaître : en accès local, le poste doit avoir une connectivité réseau directe vers la ressource cible. Si le routage interne ne le permet pas, le bypass local échoue. À valider segment par segment avant de généraliser — la fonctionnalité est encore en preview au moment de cet article.
Pour les sites distants, la Remote Network Connectivity monte un tunnel IPsec site-to-site depuis la passerelle de la branche (routeur ou CPE) vers l'edge Microsoft, sans installer le client sur chaque poste. Limite structurante : les remote networks portent le trafic Internet et Microsoft 365, mais pas le profil Private Access. Pour l'accès aux applications privées depuis un site, le client Global Secure Access reste obligatoire sur les postes. Prérequis : un total combiné d'au moins 50 licences P1 et Internet Access sur le tenant.
Depuis début 2026, Private Access propose un support BYOD en preview qui donne accès aux applications privées via un flux navigateur, sans installer le client complet. Ce mode répond au scénario du prestataire externe qui obligeait jusqu'ici à créer un compte VPN invité. À réserver au non-critique tant que la fonctionnalité reste en preview.
Deux points méritent d'être formalisés comme risques acceptés et temporaires dans votre documentation de sécurité. L'absence de support IPv6 côté client oblige à des contournements sur les parcs où l'IPv6 est déployé. Le support du DNS sécurisé (DoH) n'est pas encore disponible : désactiver DoH sur un parc en 2026 est une régression de sécurité à assumer et documenter, pas une best practice.
Conseil de séquencement final : ne cherchez pas à tout migrer d'un bloc. Prenez les applications les plus simples de votre inventaire — celles en HTTPS sans dépendance Kerberos — publiez-les en per-app, validez la chaîne complète sur une vingtaine d'utilisateurs, puis attaquez l'infrastructure AD. Le projet qui échoue est invariablement celui qui commence par les Domain Controllers.
Références utiles :