La question revient dans presque toutes les conversations que nous avons avec des DSI de PME et d’ETI : « nous avons déjà un VPN, pourquoi faudrait-il en plus un bastion ? »
C’est une bonne question, et la réponse ne tient pas dans un tableau comparatif. Les deux outils ne répondent pas au même besoin. Les confondre conduit à une situation très répandue : une organisation convaincue d’avoir sécurisé ses accès d’administration, alors qu’elle a seulement sécurisé le transport.
Ce que fait un VPN
Un VPN chiffre la liaison entre un poste distant et le réseau de l’entreprise. Il répond à une question précise : comment un collaborateur ou un prestataire peut-il joindre le réseau interne depuis l’extérieur sans que le trafic circule en clair sur Internet ?
Sur ce terrain, il fait exactement son travail. Le tunnel est chiffré, l’authentification peut être renforcée, et le poste distant se comporte comme s’il était sur le réseau local.
C’est précisément là que se situe la limite : le poste distant se comporte comme s’il était sur le réseau local. Une fois le tunnel établi, l’utilisateur voit ce que le réseau expose. Pas seulement le serveur sur lequel il doit intervenir : tout le reste aussi, dans les limites du cloisonnement en place, lequel est rarement aussi fin qu’on le croit.
Ce que fait un bastion
Un bastion d’accès ne raccorde personne à un réseau. Il ouvre une session vers une machine précise, pour un protocole précis, et il regarde ce qui s’y passe.
Concrètement, quand un administrateur passe par un bastion :
- il s’authentifie d’abord sur le bastion, avec MFA ;
- le bastion vérifie s’il a le droit d’atteindre cette cible, avec ce protocole, à ce moment ;
- le bastion ouvre la session en injectant les identifiants depuis un coffre-fort, sans les lui montrer ;
- la session est enregistrée du début à la fin.
À aucun moment l’utilisateur n’obtient un accès réseau généralisé. Et à aucun moment il ne détient le mot de passe du compte à privilèges qu’il vient pourtant d’utiliser.
La différence tient en une phrase
Le VPN vous donne accès à un réseau. Le bastion vous donne accès à une machine, et garde la trace de ce que vous y avez fait.
Tout le reste découle de là.
Le scénario qui tranche : l’intervention d’un prestataire
Prenez une situation banale. Votre éditeur de logiciel métier doit intervenir sur le serveur applicatif, un mardi après-midi, pour corriger un bug.
Avec un VPN seul, vous lui créez un compte, il se connecte, et il atteint le serveur applicatif. Il atteint aussi, potentiellement, le serveur de fichiers, l’hyperviseur et l’imprimante du service comptable. Vous lui communiquez le mot de passe administrateur du serveur, qui existe désormais dans son gestionnaire de mots de passe, dans un fichier sur son poste, ou dans le fil de discussion par lequel vous le lui avez transmis. À la fin de l’intervention, vous devez penser à désactiver le compte. Et vous ne savez pas ce qui a été fait, sauf à interroger les journaux du serveur, s’ils existent et s’ils sont exploitables.
Avec un bastion, vous lui ouvrez un accès à ce serveur, pour RDP, ce mardi-là. Il se connecte depuis son navigateur. Le mot de passe administrateur est injecté sans lui être révélé. La session est enregistrée. À l’issue de la fenêtre, l’accès se ferme. S’il faut, trois semaines plus tard, comprendre l’origine d’un dysfonctionnement, vous rejouez la session.
La différence n’est pas théorique. Ce sont ces deux scénarios qui séparent une organisation capable de répondre à un audit d’une organisation qui répondra « nous pensons que ».
Ce que le VPN ne trace pas
Un journal de connexion VPN vous dit qu’un compte s’est connecté au réseau, depuis telle adresse IP, à telle heure, et qu’il s’est déconnecté à telle autre.
Il ne vous dit pas quelles machines ont été atteintes, quelles commandes ont été passées, quels fichiers ont été consultés, ni si le compte utilisé était bien celui de la personne censée intervenir.
C’est exactement ce que réclament l’article 21 de la directive NIS2 sur les accès à privilèges, et la plupart des questionnaires de cyber-assurance : non pas la preuve que le lien était chiffré, mais la preuve que l’accès était contrôlé et que l’on sait ce qui en a été fait.
Faut-il choisir ?
Non, et c’est le point le plus important de cet article.
Un bastion ne remplace pas un VPN, pas plus qu’il ne remplace un pare-feu. Ces trois briques répondent à trois questions différentes : quel trafic réseau passe, comment on rejoint le réseau, et qui accède à quelle machine avec quels droits.
Beaucoup d’organisations conservent leur VPN pour les usages bureautiques des collaborateurs, et basculent les accès d’administration derrière un bastion. C’est généralement la trajectoire la plus simple, et elle ne demande pas de tout reprendre à zéro.
Le frein historique a disparu
Si le bastion est resté longtemps l’apanage des grands comptes, ce n’est pas faute de pertinence pour les autres. C’est que le ticket d’entrée était dissuasif : un serveur dédié à maintenir, un client lourd à déployer sur chaque poste, des règles de pare-feu à négocier, et un projet d’intégration de plusieurs semaines.
Heimlane Realm part d’un constat inverse. Les sessions SSH, RDP et VNC s’ouvrent dans le navigateur, sans logiciel client. Aucun serveur de rebond n’est exposé et aucune règle entrante n’est créée : un agent léger installé sur le réseau ouvre un tunnel sortant vers la plateforme. Les identifiants viennent de Vault et ne sont jamais affichés. Et l’ensemble est hébergé en France et en Allemagne.
Le besoin n’a pas changé depuis vingt ans. Ce qui a changé, c’est ce qu’il faut mettre en face pour y répondre.
Pour aller plus loin : qu’est-ce qu’un bastion d’accès, à quoi sert-il et comment en déployer un. Vous pouvez aussi demander une démonstration de Realm et ouvrir une session tracée en quinze minutes.
