Avez-vous encore besoin d'un VPN si vous utilisez un Identity-Aware Proxy ?

L'hypothèse est la suivante : dès qu'un proxy qui connaît l'identité se place devant les applications internes, le VPN n'est que décoration et le client peut partir. Cela vaut pour un cas étroit, une application HTTPS interactive utilisée par une personne dans un navigateur, et cela échoue silencieusement partout ailleurs. Un proxy autorise une requête vis-à-vis d'une ressource ; un VPN admet un client dans un périmètre réseau, et ces deux frontières coïncident rarement. Avant de mettre un tunnel au rebut, comparez les opérations que vos équipes effectuent réellement, pas les étiquettes de produit sur le schéma.

Les deux portes autorisent des choses différentes

Une porte applicative décide si cette requête, de cette identité, peut atteindre cette ressource protégée. La présentation d'Identity-Aware Proxy de Google décrit exactement cette forme : une couche d'autorisation centrale devant les applications HTTPS, pilotée par un rôle IAM. La frontière est la ressource, et l'unité d'accès est la requête. Un VPN routé fait quelque chose de plus grossier et de plus large : il admet un client dans un périmètre réseau défini, après quoi l'application décide encore ce que ce client peut faire.

Aucun des deux modèles n'implique l'autre. Franchir la porte ne dit rien sur la lecture d'un enregistrement particulier, et être sur le réseau ne dit rien sur l'autorisation d'agir.

Ce que le proxy ne couvre pas, et que le VPN couvre

Les sessions SSH, les clients de bases de données, les courtiers de messages et les noms d'hôte internes qu'aucun navigateur n'ouvre jamais ne deviennent pas joignables parce qu'un proxy web existe. Chacun parle son propre protocole, et chacun a besoin soit de son propre chemin authentifié, soit d'un réseau qui le transporte. C'est l'écart que les gens découvrent le premier jour d'une migration, généralement par un ingénieur d'astreinte dont l'ordinateur portable ne résout plus un nom d'hôte.

L'écart inverse est tout aussi réel. Un VPN qui admet un client dans un sous-réseau n'authentifie pas la personne à l'intérieur, et un appareil compromis sur ce sous-réseau hérite de ce que le réseau autorise. Si l'exigence est une autorisation par requête avec une identité auditable, le routage seul ne peut pas la produire. La plupart des organisations finissent par exploiter les deux, et la question intéressante est de savoir quelles ressources chacun est autorisé à couvrir.

Le flux du client décide plus que le schéma d'architecture

Une connexion au navigateur avec redirection et un défi MFA occasionnel est une bonne expérience pour une personne qui clique sur un signet. Une tâche cron, une CLI ou un agent de build n'a pas de navigateur et ne peut pas répondre à une invite interactive, il a donc besoin d'un chemin non interactif documenté ou du tunnel. La découverte de cette exigence survient généralement après la validation de la conception.

Comptez les clients avant de compter les applications. Un tableau de bord peut servir cent personnes ; un port de base de données peut bloquer toute une équipe.

La posture de l'appareil n'est une propriété d'aucune des deux portes

L'installation d'un client VPN n'est pas un contrôle de conformité, et une conception fondée sur le navigateur n'est pas automatiquement incapable de respecter une politique d'appareils gérés. Les deux peuvent s'intégrer à des signaux de posture, et les deux peuvent être déployés sans eux. Demandez quelle application existe, à qui appartient la politique et ce qui arrive à un appareil qui y échoue, plutôt que de le déduire de la forme du produit.

La même prudence vaut pour le retrait de l'accès. Supprimer une appartenance à un groupe dans le proxy et révoquer un certificat pour le tunnel sont des opérations différentes avec des délais différents, et l'une d'elles est généralement oubliée lors du départ.

Trouvez les chemins alternatifs avant de mettre quoi que ce soit au rebut

Une origine non protégée derrière le proxy, un second nom d'hôte qui le contourne ou une large route privée héritée d'une conception antérieure décideront quelle porte est réellement en vigueur. Testez une opération autorisée et une opération refusée via le client réel, pas via la console, et testez-les depuis un appareil qui n'a jamais été inscrit. Le cas refusé est celui qui vous dit si la porte fait quoi que ce soit.

Écrivez ensuite la passation : inscription, mises à jour, retrait de l'accès et le chemin de récupération pour quelqu'un enfermé dehors à 2 heures du matin. Retirer une invite ou une application cliente déplace la responsabilité entre les équipes ; cela ne supprime pas la responsabilité.

Si vous décidez cette semaine, partez d'une liste d'opérations plutôt que d'une liste de produits, marquez celles qu'un navigateur peut effectuer, et laissez le reste justifier l'accès réseau qui survit.