Le VPN d'entreprise est-il mort ?

Éditorial

Le « zero trust » est présenté comme le remplaçant du VPN, alors qu'il répond surtout à une autre question : que donne-t-on à quelqu'un une fois qu'il est entré. Cet éditorial démonte le modèle périmétrique, examine ce que l'accès par application change réellement, ce qu'il déplace vers le fournisseur d'identité et le proxy d'accès, et ce qui reste valable dans le bon vieux tunnel.

Mis à jour le 25 septembre 2026~25 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Une nécrologie qu’on republie chaque année

Le VPN d’entreprise est mort. On l’a lu l’an dernier, on l’avait lu l’année précédente, et l’on devine sans grand effort d’imagination qu’on le relira l’an prochain, sous une plume différente et avec la même infographie. Rarement un défunt aura été enterré avec autant de constance, et rarement il aura continué de payer ses factures de licence avec autant de régularité.

Il faut dire que l’annonce a des parrains intéressés. Chaque éditeur qui vend un successeur a besoin d’un cadavre, et le VPN s’y prête à merveille : il est vieux, il est laid, ses concentrateurs exposés sur internet ont connu ces dernières années une série de vulnérabilités exploitées à grande échelle qui ont fait les beaux jours des équipes de réponse à incident, et personne n’a jamais aimé le client qu’il faut lancer le matin, ni la déconnexion qui survient au milieu d’une visioconférence.

Face à lui se dresse le « zero trust », expression qui a le rare mérite de pouvoir désigner, selon l’interlocuteur, une philosophie de sécurité, une architecture de référence, une gamme de produits, un projet de transformation sur trois ans, ou une ligne budgétaire. La confiance zéro, dans les plaquettes, s’accompagne d’ailleurs d’une confiance totale dans le fournisseur qui la vend, ce qui est un joli paradoxe pour commencer.

Cet éditorial voudrait faire ce que les plaquettes ne font pas : retirer le discours, regarder le mécanisme, et répondre honnêtement à la question posée. Ma réponse, que je donne tout de suite pour épargner au lecteur pressé le reste de la lecture, est la suivante : ce qui meurt n’est pas le VPN, c’est une hypothèse que le VPN servait. Le tunnel chiffré se porte très bien. Ce qui agonise, c’est l’idée qu’être entré dans un réseau vaut autorisation d’y faire ce qu’on veut. Et ce qui la remplace ne supprime pas la confiance : il la déménage, avec ses meubles, chez quelqu’un d’autre.

Ce que le modèle périmétrique supposait

Avant de dire qu’un modèle est mort, il faut savoir ce qu’il affirmait. Le modèle périmétrique, celui du château fort avec ses douves, reposait sur quatre hypothèses rarement énoncées, et c’est justement parce qu’elles n’étaient pas énoncées qu’on a mis si longtemps à s’apercevoir qu’elles étaient fausses.

Première hypothèse : l’intérieur est un lieu de confiance. Une machine qui a une adresse dans le réseau interne est présumée appartenir à l’organisation et se comporter honnêtement. Le filtrage se concentre à la frontière ; à l’intérieur, les flux circulent assez librement, parce qu’on filtre les étrangers et non les voisins.

Deuxième hypothèse : l’accès au réseau vaut autorisation. Si l’on peut joindre un serveur, c’est qu’on a le droit de le joindre. L’autorisation fine, quand elle existe, est laissée à chaque application, qui s’en acquitte avec des bonheurs divers. Le réseau, lui, ne pose qu’une question : dedans ou dehors ?

Troisième hypothèse : le poste qui entre est sain. Le poste de l’entreprise, administré par l’entreprise, est présumé conforme. On vérifie qui se connecte, rarement avec quoi.

Quatrième hypothèse : le périmètre est un lieu. Il y a un dedans et un dehors, séparés par une ligne qu’on peut tracer sur un schéma, avec un pare-feu au milieu et un gardien devant.

Le VPN d’accès distant, dans ce modèle, a une fonction très précise : transporter un poste de l’extérieur vers l’intérieur. Il ne crée pas de nouvelle autorisation ; il étend le réseau interne jusqu’au salon du collaborateur, et le fait bénéficier de toutes les présomptions attachées à l’intérieur. Une fois le tunnel monté, le portable posé à côté de la cafetière familiale est, du point de vue du réseau, dans la salle serveur.

Chacune des quatre hypothèses s’est effondrée pour des raisons distinctes. L’intérieur a cessé d’être un lieu de confiance le jour où l’on a compris que la plupart des compromissions sérieuses commencent par un poste interne piégé, puis progressent par mouvement latéral dans un réseau où rien ne les arrête. L’accès au réseau a cessé de valoir autorisation quand on a constaté que le même réseau hébergeait la paie, la messagerie et l’imprimante du troisième étage, toutes joignables par le même stagiaire. Le poste sain est une fiction qu’aucun responsable de parc n’a jamais crue en privé. Et le périmètre a cessé d’être un lieu quand les applications sont parties chez des fournisseurs d’informatique en nuage, les collaborateurs chez eux, et les données un peu partout, si bien que le château fort défend aujourd’hui avec vigilance une cour vide.

Le tunnel n’est pas coupable

Il faut ici faire une distinction que les nécrologies escamotent systématiquement, parce qu’elle ruine leur effet.

Un VPN, c’est deux choses emballées ensemble. D’une part, un tunnel : un canal chiffré et authentifié entre deux points, qui protège les paquets en transit contre l’écoute et la modification. D’autre part, une politique d’accès : ce que le poste peut joindre une fois le tunnel établi. Les protocoles de tunnel (IPsec, WireGuard, les VPN sur TLS) ne disent rien de la seconde ; c’est la configuration de la passerelle qui en décide.

Or tous les reproches sérieux adressés au VPN portent sur la seconde. On lui reproche de donner accès à tout le réseau interne : c’est un choix de configuration, pas une propriété du tunnel. On lui reproche de ne pas vérifier l’état du poste : rien n’empêche de le faire à l’établissement. On lui reproche de ne pas autoriser application par application : rien n’empêche de filtrer à la sortie de la passerelle. La page consacrée aux VPN, tunnels et bastions montre bien que le tunnel est une brique, et qu’on peut construire avec elle des choses très différentes.

Le VPN tel qu’on l’a déployé est coupable. Le VPN tel qu’on pourrait le déployer l’est beaucoup moins. Cela ne l’innocente pas : si presque tout le monde l’a déployé en « accès complet au réseau », c’est que c’était le plus simple, et en sécurité, le plus simple finit toujours par devenir la norme, puis la norme par devenir l’incident. Mais cela oblige à reformuler le débat. La question n’est pas « tunnel ou pas tunnel », elle est « où et comment décide-t-on de l’accès ».

Un exemple montre la nuance. Supposons une petite structure de vingt postes qui veut que ses collaborateurs n’atteignent, à distance, qu’un seul serveur applicatif. Côté poste, on pourrait être tenté d’écrire ceci :

Voir la configuration WireGuard du poste

# Configuration WireGuard du poste (extrait)
[Interface]
PrivateKey = <clé privée du poste>
Address = 10.8.0.12/32

[Peer]
PublicKey = <clé publique de la passerelle>
Endpoint = vpn.example.org:51820
AllowedIPs = 10.20.0.15/32

Le piège est que cette restriction vit sur le poste, donc entre les mains de son utilisateur, et de quiconque l’a compromis. AllowedIPs côté client décide de ce qui est envoyé dans le tunnel ; il n’interdit rien. Le contrôle d’accès, lui, doit être appliqué par la passerelle, qui seule est sous l’autorité de l’organisation.

On a ainsi, avec un tunnel des plus classiques, un accès restreint à une application. Ce n’est pas du « zero trust » : il n’y a ni vérification continue de l’identité, ni évaluation de l’état du poste, et l’identité du poste est une clé posée sur un disque. Mais c’est la preuve que l’essentiel du reproche ne vise pas le tunnel.

Le zero trust sans la plaquette

Retirons maintenant le papier cadeau. Le mouvement dit « zero trust » a une histoire respectable, antérieure à son marketing. Des réflexions sur la « dépérimétrisation » circulaient dès les années 2000 ; un grand acteur du web a publié à partir du milieu des années 2010 une série d’articles décrivant comment il avait supprimé le privilège accordé à son réseau interne, sous le nom de BeyondCorp ; et le NIST a publié en 2020 une architecture de référence, la publication spéciale 800-207, qui a l’immense mérite d’être sobre.

Réduit à son mécanisme, le modèle tient en trois propositions.

Aucune position réseau ne confère de droit. Être « dedans » ne donne rien. Chaque accès à une ressource est évalué pour lui-même, comme si la requête venait d’internet, ce qu’elle fait souvent.

La décision porte sur chaque requête, et elle combine plusieurs signaux. Qui est l’utilisateur, authentifié fortement ; depuis quel appareil, et dans quel état est cet appareil ; vers quelle ressource ; dans quel contexte (heure, lieu, comportement habituel). La décision est prise par un point de décision de politique, et appliquée par un point d’application placé devant la ressource.

Le moindre privilège est appliqué à la ressource, pas au réseau. On n’accorde pas l’accès à un sous-réseau, on accorde l’accès à une application, pour une durée, et on le réévalue.

Rien de tout cela n’est un produit. C’est une manière de répartir les responsabilités. La page consacrée au filtrage, à la segmentation et au zero trust le rappelle avec une prudence que je partage : le zero trust n’est pas quelque chose qu’on achète, c’est quelque chose qu’on cesse de présumer. Il est d’ailleurs assez savoureux de constater qu’une démarche fondée sur le refus de la présomption s’achète le plus souvent sur présentation d’une présentation.

Dans sa forme commerciale la plus répandue pour l’accès distant, le modèle prend la figure d’un proxy d’accès : le collaborateur ne se connecte plus au réseau, il se connecte à un service intermédiaire, souvent hébergé par le fournisseur, qui l’authentifie auprès du fournisseur d’identité, interroge l’agent installé sur son poste, applique la politique, puis relaie la requête vers l’application. L’application, elle, n’est plus exposée directement à internet : elle établit souvent une connexion sortante vers le proxy, qui lui amène les utilisateurs autorisés comme un maître d’hôtel amène les convives à leur table.

Ce que l’accès par application change vraiment

Soyons justes : ce déplacement apporte des bénéfices réels, et il serait aussi malhonnête de les nier que de les exagérer.

Il réduit le rayon d’action d’un poste compromis. C’est le gain principal, et il est considérable. Un poste en « accès complet » compromis donne à l’attaquant une vue sur tout le réseau interne, depuis laquelle il cartographie, rebondit et progresse. Un poste qui n’a accès qu’à trois applications, chacune derrière un point d’application, donne à l’attaquant trois applications. Le mouvement latéral, qui est le cœur de la plupart des intrusions graves, perd son terrain de jeu.

Il cesse d’exposer une passerelle réseau sur internet. Le concentrateur VPN est un équipement exposé, complexe, doté d’un serveur web, d’une pile d’authentification et d’un accès privilégié au réseau interne. Il est donc, par construction, l’une des cibles les plus rentables qui soient. Quand l’application initie elle-même la connexion vers le proxy, il n’y a plus de port ouvert à l’entrée. On ne supprime pas la cible, on la déplace chez le fournisseur du proxy ; mais on la déplace chez quelqu’un dont c’est le métier de la défendre, ce qui, selon les fournisseurs et selon les jours, peut être un progrès.

Il rend l’autorisation lisible. Une politique qui dit « le groupe comptabilité, depuis un poste géré et à jour, accède à l’application de paie » se lit, se discute et s’audite. Une règle de pare-feu qui ouvre un sous-réseau à un autre sous-réseau ne dit rien de qui y a droit ni pourquoi.

Il produit une journalisation par requête. Chaque accès passe par un point qui sait qui, quoi, quand, depuis quel appareil. Pour une équipe qui doit reconstituer un incident, c’est un luxe que les journaux d’une passerelle VPN, qui enregistrent surtout des connexions et des déconnexions, n’ont jamais offert.

Il améliore souvent l’expérience. Pas de client à lancer, pas de tunnel qui tombe, pas de trafic personnel qui transite par le siège. Cet argument fait sourire les puristes ; il ne devrait pas. Une mesure de sécurité que les utilisateurs contournent n’est pas une mesure de sécurité, c’est une décoration.

Ce qu’il déplace

Voici maintenant la partie qu’on trouve rarement dans les brochures, pour des raisons qui ne tiennent pas seulement à la place disponible.

Le fournisseur d’identité devient le périmètre

Dans un modèle où aucune position réseau ne confère de droit, tout repose sur l’identité. Le fournisseur d’identité n’est plus un service parmi d’autres ; il devient le point unique où se décide l’accès à tout. On a supprimé la muraille autour du château pour la remplacer par un portier, et le portier est seul.

Cela a trois conséquences.

Sa compromission ouvre tout. Un attaquant qui obtient des droits d’administration sur le fournisseur d’identité, ou qui parvient à y créer ou modifier des comptes, à y enregistrer ses propres facteurs d’authentification, à y inscrire une application frauduleuse, n’a plus besoin de traverser un réseau : il se présente par la grande porte, avec une identité impeccable, depuis un appareil qu’il déclarera conforme. Les attaques publiquement documentées de ces dernières années contre des fournisseurs d’identité et leurs clients ont montré que cette cible était parfaitement comprise de ceux qui s’y intéressent.

Sa panne arrête tout. Quand le VPN tombe, les collaborateurs distants ne travaillent plus, mais le siège continue. Quand le fournisseur d’identité tombe dans un modèle où tout passe par lui, plus personne n’accède à rien, nulle part. On a remplacé une dépendance partielle par une dépendance totale, ce qui s’appelle, dans d’autres domaines, mettre tous ses œufs dans un seul panier certifié.

Son authentification devient critique au sens fort. Si l’identité est le périmètre, alors l’authentification est la serrure, et une serrure qui accepte un mot de passe et un code à six chiffres relayable par une page d’hameçonnage en temps réel n’est pas à la hauteur d’un périmètre. Le modèle suppose des facteurs résistants à l’hameçonnage, liés au domaine d’origine, ce que la page sur l’authentification des personnes et des services détaille. Un « zero trust » bâti sur une authentification faible est un château sans muraille dont on a confié la clé au premier venu poli.

Le proxy d’accès devient un intermédiaire omniscient

Le proxy voit passer toutes les requêtes. Pour appliquer une politique au niveau de l’application, il doit souvent terminer la session TLS, donc voir le contenu en clair. Lorsqu’il est hébergé par un fournisseur, cela signifie qu’un tiers voit en clair tout le trafic applicatif de l’organisation, détient les secrets nécessaires pour le faire, et opère dans une juridiction qu’il faut connaître.

Ce n’est pas nécessairement inacceptable. C’est une décision, et elle mérite d’être prise en connaissance de cause plutôt que découverte dans l’annexe technique du contrat. On a longtemps reproché au VPN de faire transiter tout le trafic par le siège ; il est piquant de s’en émanciper pour le faire transiter par le centre de données de quelqu’un d’autre.

Le proxy est aussi une dépendance de disponibilité, et une dépendance de performance. Chaque requête fait un détour par lui. Quand il ralentit, toutes les applications ralentissent ; quand il tombe, elles tombent ensemble.

L’état du poste devient une déclaration

La décision prend en compte l’état de l’appareil : chiffrement du disque actif, système à jour, protection des terminaux présente. Mais cet état est rapporté par un agent installé sur le poste. Sur un poste compromis avec des privilèges suffisants, l’agent peut être trompé ou remplacé, et il déclarera ce qu’on lui fera déclarer. L’évaluation de posture est utile contre la négligence, beaucoup moins contre la malveillance. Elle filtre le portable jamais mis à jour ; elle ne filtre pas l’attaquant qui a pris soin de le mettre à jour.

Les attestations matérielles, qui s’appuient sur une puce de sécurité du poste pour prouver certains éléments de son état, améliorent la situation. Elles ne la règlent pas, et leur déploiement est inégal selon les systèmes.

La politique devient une dette

Un pare-feu périmétrique a quelques centaines de règles, dont personne ne sait plus à quoi servent la moitié. Un modèle par application a des politiques par ressource, par groupe, par état d’appareil, par contexte. Elles sont plus lisibles une à une, et beaucoup plus nombreuses. Sans gouvernance (un propriétaire par politique, une revue périodique, une suppression des accès devenus inutiles), elles connaîtront exactement le destin des règles de pare-feu, avec davantage de dimensions dans lesquelles se perdre. Le moindre privilège n’est pas un état qu’on atteint, c’est un entretien qu’on s’impose, et l’on sait ce que deviennent les entretiens quand le budget se resserre.

Ce que l’accès par application sait mal faire

Le modèle du proxy d’accès est né dans le monde des applications web, et il y excelle. Dès qu’on en sort, il s’essouffle, et c’est là que le VPN, qu’on croyait enterré, se remet à respirer.

Les protocoles qui ne sont pas du web. Partage de fichiers, bureau à distance, bases de données interrogées directement par un client lourd, protocoles industriels, téléphonie. Les offres savent souvent transporter certains d’entre eux, généralement en réinstallant sur le poste un agent qui encapsule le trafic dans un tunnel. Ce qui ressemble, à s’y méprendre, à un VPN, avec un autre nom sur la facture.

L’administration. Un administrateur doit pouvoir atteindre des machines par SSH, par des consoles de gestion, par des interfaces qui n’ont jamais été pensées pour être publiées derrière un proxy. Les bastions d’administration, avec enregistrement des sessions et accès à privilège élevé temporaire, répondent à ce besoin depuis longtemps, et ils reposent souvent sur un accès réseau restreint plutôt que sur un proxy applicatif.

Les flux entre machines. Le zero trust dans sa version « accès distant » parle d’utilisateurs. Or une bonne part du trafic d’une organisation va de serveur à serveur, de site à site, de l’usine au siège. Pour ceux-là, la réponse n’est pas un proxy d’accès, c’est l’authentification mutuelle des services, par exemple par TLS mutuel, et la segmentation. Et pour relier deux sites à travers internet, le tunnel IPsec ou WireGuard reste l’outil évident, qu’on l’appelle comme on voudra.

Le fonctionnement dégradé. Un site qui perd son accès à internet et dont toutes les applications internes passent par un proxy hébergé ailleurs perd l’accès à ses propres applications, installées dans sa propre salle, à trois mètres de ses propres utilisateurs. C’est un scénario de continuité que peu de dossiers d’architecture examinent, et qui a pourtant la netteté des choses absurdes.

Ce qui reste valable dans le VPN

Si l’on remet les choses à leur place, le VPN garde des usages où il est simplement le bon outil.

L’interconnexion de sites et d’environnements. Relier un siège à une agence, un centre de données à un environnement en nuage, deux partenaires entre eux : c’est la fonction originelle du tunnel, et aucun proxy d’accès ne la remplace. La seule exigence est de ne pas en faire un pont ouvert, mais un lien filtré aux deux extrémités.

L’accès restreint pour les petites structures. Une organisation de vingt personnes, sans équipe dédiée, n’a pas les moyens d’exploiter un fournisseur d’identité complet, une politique par application et une surveillance de posture. Elle a les moyens d’exploiter un tunnel WireGuard moderne, simple, auditable, filtré à la passerelle vers les deux ou trois services nécessaires, avec une clé par appareil et une procédure de révocation. Ce n’est pas du « zero trust ». C’est, dans son contexte, plus sûr qu’un zero trust mal exploité, et bien plus sûr qu’un VPN en accès complet.

Le bastion d’administration. Pour les accès à privilèges, un tunnel vers un bastion unique, lui-même seul autorisé à joindre les interfaces d’administration, reste une architecture saine. Elle se combine d’ailleurs parfaitement avec une authentification forte et une journalisation des sessions.

La protection en réseau hostile. Sur un réseau sans fil public ou douteux, faire passer tout le trafic du poste dans un tunnel vers un point de confiance reste une protection utile, même si le chiffrement de bout en bout des applications en a réduit la nécessité.

La maîtrise. Un tunnel qu’on opère soi-même, sur un logiciel libre, ne dépend d’aucun fournisseur tiers pour fonctionner, ne confie le trafic en clair à personne, et continue de marcher quand internet tousse. Pour certaines organisations, c’est un critère décisif ; pour d’autres, c’est un fardeau. Dans les deux cas, c’est un choix, et non une survivance.

Le meilleur argument contraire : le VPN hybride est une illusion confortable

Je dois maintenant exposer la position qui me contredit le plus, parce qu’elle est solide.

Elle dit ceci. En théorie, on peut filtrer finement derrière un VPN. En pratique, personne ne le fait. Les passerelles sont déployées en accès complet parce que c’est ce qui marche le premier jour, les exceptions s’accumulent, et au bout de trois ans le tunnel donne accès à tout ce qui a été demandé une fois par quelqu’un. Plaider pour un « VPN bien configuré », c’est plaider pour un animal que personne n’a jamais observé dans la nature.

Elle ajoute que le concentrateur VPN exposé est une cible structurellement mauvaise. C’est un équipement complexe, souvent fermé, mis à jour lentement, qui combine exposition sur internet et accès privilégié au réseau interne. Les séries de vulnérabilités exploitées massivement sur ces équipements ne sont pas des accidents : elles découlent de cette position. Supprimer le port ouvert à l’entrée, c’est supprimer une classe entière de risques, et aucune bonne configuration ne le fait.

Elle conclut que les architectures « hybrides » servent surtout à ne pas choisir. On garde le VPN pour les cas difficiles, on ajoute un proxy pour les cas faciles, et l’on se retrouve avec deux surfaces d’attaque, deux politiques à maintenir, deux ensembles de journaux, et une migration qui ne se termine jamais parce que les cas difficiles ne disparaissent pas d’eux-mêmes.

Cet argument me paraît juste sur le constat, et je n’ai pas de réponse satisfaisante sur le premier point. Il est vrai que le VPN à accès restreint est rare, et qu’une recommandation qui suppose une discipline que personne n’a n’est pas une recommandation, c’est un vœu. Sur le deuxième, il a également raison : un équipement exposé et privilégié est une mauvaise idée, et il faut au minimum le traiter comme l’actif le plus exposé de l’organisation, avec des correctifs appliqués en jours et non en trimestres.

Je m’en sépare sur la conclusion. L’argument compare un VPN réel, avec ses défauts d’exploitation, à un zero trust idéal, sans les siens. Or le zero trust réel a lui aussi ses exceptions qui s’accumulent, ses politiques trop larges créées un vendredi soir, ses agents de posture désactivés « temporairement », et son fournisseur d’identité dont personne n’a audité les administrateurs. La discipline qui manque pour bien configurer un VPN est la même qui manquera pour bien exploiter un zero trust. Changer d’outil ne l’installe pas ; cela donne seulement l’occasion de la réclamer une nouvelle fois, avec un nouveau budget. Ce n’est pas rien, d’ailleurs : une migration bien menée est parfois le seul moment où une organisation accepte de remettre ses accès à plat. Mais c’est un bénéfice du chantier, pas de la technologie.

Ce que je ne sais pas

Je ne sais pas comparer le risque réel des deux modèles. Je peux décrire les mécanismes, pas mesurer la fréquence des compromissions dans chaque architecture. Les chiffres qui circulent viennent le plus souvent de ceux qui vendent l’une ou l’autre, et je ne leur accorde pas plus de crédit qu’à un bulletin météo rédigé par un marchand de parapluies.

Je ne sais pas ce que vaut, dans la durée, l’évaluation de posture. Elle filtre à coup sûr les postes négligés. Contre un attaquant qui a pris la main sur un poste géré, son efficacité dépend de détails d’implémentation (attestation matérielle ou non, profondeur des vérifications) que je ne peux pas évaluer de façon générale.

Je ne sais pas comment évoluera la dépendance aux fournisseurs d’identité. La concentration du marché fait que beaucoup d’organisations dépendent des mêmes quelques acteurs. Ce que cela signifie en cas de compromission ou de panne majeure de l’un d’eux, je peux l’imaginer, pas le quantifier.

Je ne connais pas le coût d’exploitation réel d’un zero trust pour une petite structure. Mon intuition est qu’il est disproportionné en dessous d’une certaine taille, et que la version « hébergée clés en main » échange ce coût contre une dépendance. C’est une intuition, pas une mesure.

Ce qui reste

Le VPN d’entreprise n’est pas mort. Il a perdu son monopole, et surtout il a perdu l’hypothèse qu’il servait. C’est plus humiliant qu’un décès, mais c’est beaucoup plus instructif.

Trois choses me semblent acquises. Que le débat ne porte pas sur le tunnel, mais sur ce qu’on accorde à celui qui en sort : un VPN en accès complet et un proxy d’accès aux politiques laxistes commettent la même faute avec des technologies différentes. Que le zero trust ne supprime pas la confiance, il la concentre dans le fournisseur d’identité, dans le proxy, dans l’agent du poste, et qu’une confiance concentrée se défend autrement qu’une confiance diffuse : avec une authentification résistante à l’hameçonnage, une administration du fournisseur d’identité traitée comme le bien le plus sensible de l’organisation, et un plan pour le jour où il tombe. Et que le moindre privilège est un travail, pas un achat : il demande des propriétaires, des revues et des suppressions, et aucun produit ne les fera à votre place, quoi qu’en dise la démonstration.

Pour une grande organisation avec une équipe d’identité solide, l’accès par application est un progrès réel, à condition de le payer en discipline plutôt qu’en licences. Pour une petite structure, un tunnel moderne, filtré à la passerelle, avec une clé par appareil, reste une réponse honorable, et préférable à une plateforme qu’on n’aura ni le temps ni les moyens d’exploiter.

Quant à la prochaine nécrologie du VPN, elle paraîtra sans doute l’an prochain. On pourra vérifier, ce jour-là, qu’elle aura été envoyée par un tunnel.

🐝 Ce qui arrive si on s’en passe

Tant que l’accès distant repose sur un tunnel ouvert sur tout le réseau et sur une clé posée sur le disque du poste, un portable perdu ou volé dont la clé n’a pas été révoquée reste une entrée complète dans le réseau interne, sans qu’aucun humain ait à s’authentifier de nouveau. La passerelle, qui n’enregistre guère que des connexions et des déconnexions, ne dira pas ensuite quelles ressources ce poste a visitées, si bien que le périmètre de l’incident se déclare au lieu de se démontrer. La ruche a posé une serrure à l’entrée du jardin et laissé toutes les alvéoles ouvertes.

🦫 Explication de la marmotte 🍫

Un réseau privé virtuel, ou VPN, réunit deux choses. La première est un tunnel : une connexion chiffrée et authentifiée entre le poste d’un salarié et une passerelle de l’entreprise, qui empêche de lire ou de modifier les données en route. La seconde est une politique d’accès : la liste de ce que le poste peut joindre une fois connecté. Dans l’ancien modèle, dit périmétrique, cette politique était très large : être connecté au réseau interne suffisait pour atteindre presque tous les serveurs, car l’intérieur était supposé sûr. Un seul poste piégé permet alors à un attaquant de se déplacer partout. Le modèle appelé « zero trust », ou confiance zéro, retire toute valeur à la position sur le réseau. Chaque demande d’accès à une application est évaluée séparément, selon l’identité de la personne, l’état de son appareil et le contexte, puis autorisée ou refusée par un intermédiaire placé devant l’application. Ce modèle limite ce qu’un poste compromis peut atteindre et enregistre chaque accès. Mais il concentre la confiance : si le fournisseur d’identité, qui vérifie qui est qui, est piraté ou en panne, tout est ouvert ou tout est bloqué. L’intermédiaire voit aussi passer le trafic en clair, et l’état de l’appareil est déclaré par un logiciel qu’un attaquant peut tromper. Un tunnel classique, filtré à la passerelle vers quelques services, reste une solution solide, notamment pour relier des sites ou pour une petite structure.