Accéder aux applications internes sans VPN : proxy d'application, Private Access et plan de migration
Le VPN donne à un poste distant une adresse sur le réseau interne, et avec elle l'accès à bien plus que ce dont l'utilisateur a besoin. Les passerelles VPN sont en outre une cible privilégiée des attaquants. Les services d'Entra permettent désormais de publier les applications internes une par une, derrière les mêmes contrôles que le cloud.
Ce que l'on reproche au VPN
Le VPN repose sur un modèle de périmètre : une fois authentifié, l'utilisateur est « dedans ». Sauf segmentation fine, rarement maintenue, il peut joindre des serveurs, des contrôleurs de domaine et des interfaces d'administration sans rapport avec son travail. Un poste compromis connecté au VPN devient une tête de pont sur le réseau interne. Par ailleurs, les concentrateurs VPN exposés sur Internet font régulièrement l'objet de vulnérabilités critiques exploitées à grande échelle.
L'objectif n'est pas de supprimer le VPN par principe, mais de réduire progressivement ce qui en dépend, pour arriver à un accès accordé application par application, à une identité vérifiée sur un appareil évalué.
Le proxy d'application Entra
Le proxy d'application publie des applications web internes via Entra ID. Des connecteurs installés sur le réseau interne établissent uniquement des connexions sortantes vers le service : aucun port entrant n'est ouvert. L'utilisateur s'authentifie auprès d'Entra ID avant que la moindre requête n'atteigne l'application, ce qui place cette dernière sous l'accès conditionnel (MFA, appareil conforme, risque).
Il convient bien aux applications web, y compris celles qui utilisent l'authentification Windows intégrée grâce à la délégation Kerberos contrainte, ou l'authentification par en-têtes. Il est inclus dans certaines licences Entra ID ; vérifiez les conditions applicables.
Global Secure Access et Private Access
Private Access, composant de Global Secure Access, étend ce modèle au-delà du web. Un client installé sur le poste achemine le trafic destiné aux applications privées définies vers le service Microsoft, qui le transmet aux connecteurs internes. Il prend en charge des protocoles autres que HTTP, comme RDP, SMB ou SSH, selon les possibilités actuelles du service, que nous vous invitons à vérifier.
Deux modes de publication coexistent :
- Accès rapide : on déclare de larges plages d'adresses ou de noms, ce qui reproduit rapidement le périmètre du VPN ; utile pour démarrer, mais sans gain de segmentation ;
- Accès par application : chaque application est déclarée avec ses noms, ports et utilisateurs autorisés, et peut recevoir ses propres stratégies d'accès conditionnel.
Le piège de l'accès rapide. Publier tout le réseau interne en accès rapide revient à recréer un VPN avec un autre client. C'est une étape de transition acceptable, à condition de planifier dès le départ le découpage en applications.
Intégrer l'accès conditionnel
L'intérêt de ces services tient à l'accès conditionnel. Pour chaque application publiée, on peut exiger une méthode d'authentification forte, un appareil conforme ou joint, ou bloquer certains risques. Les applications d'administration (consoles, accès RDP aux serveurs) méritent des exigences plus fortes que les applications métier courantes, idéalement un poste d'administration dédié.
Les serveurs qui hébergent les connecteurs méritent également attention : ils relaient le trafic vers l'interne et, lorsqu'ils utilisent la délégation Kerberos, détiennent des droits d'emprunt d'identité. Ils doivent être durcis, mis à jour et classés au niveau des applications qu'ils servent.
Un plan de migration en étapes
- Inventorier les usages du VPN à partir de ses journaux et des flux réseau : qui accède à quoi, par quel protocole.
- Publier d'abord les applications web les plus utilisées via le proxy d'application ou Private Access.
- Piloter Private Access sur un groupe restreint, en commençant éventuellement par l'accès rapide.
- Découper l'accès rapide en applications distinctes avec leurs propres stratégies.
- Réduire le VPN aux usages résiduels identifiés, puis aux seuls utilisateurs concernés.
- Retirer le concentrateur une fois les derniers usages traités.
Ce qu'un audit vérifie
- L'exposition et le niveau de correctifs des passerelles VPN restantes.
- Le périmètre réseau réellement accessible aux utilisateurs du VPN.
- Les applications publiées et la couverture par l'accès conditionnel.
- L'usage de l'accès rapide et le plan de découpage en applications.
- Le durcissement et la délégation Kerberos des serveurs de connecteurs.
- Les exigences renforcées pour les applications d'administration.