Quand un prestataire externe devait intervenir sur un serveur, on lui ouvrait un accès VPN. C'était l'usage, il fonctionnait, et personne ne le remettait en question. Je l'ai remplacé par un bastion web. Aujourd'hui plus aucun prestataire ne passe par un VPN.

Je raconte ici le raisonnement plutôt que la procédure d'installation, parce que la procédure existe déjà et qu'elle n'est pas la partie difficile.

Le problème n'est pas le VPN

Un VPN fait bien ce qu'on lui demande : il place un poste distant sur le réseau. C'est justement l'ennui.

Un prestataire qui doit intervenir sur une application a besoin d'atteindre une machine, pour une tâche, pendant un temps donné. Ce qu'on lui donne, c'est une route vers un réseau. La différence entre les deux est invisible tant que tout se passe bien, et elle devient tout le sujet le jour où le poste du prestataire est compromis. Ce poste, je ne l'administre pas. Je ne connais ni son état de mise à jour, ni ce qui tourne dessus, ni qui s'en sert réellement.

Il y a une asymétrie désagréable dans ces accès. Ce sont ceux qu'on maîtrise le moins, et ce sont aussi ceux qu'on revoit le plus rarement. Un compte interne qui part fait l'objet d'une procédure. Un accès prestataire ouvert pour une migration il y a deux ans, personne ne se souvient qu'il existe.

Le déclencheur

Deux choses en même temps. L'outil d'accès distant en place devait être remplacé, et nos politiques de sécurité se durcissaient. Dans ce durcissement, le VPN des prestataires était le point noir évident : l'accès le plus large, accordé aux utilisateurs sur lesquels nous avions le moins de prise.

J'avais donc une contrainte de calendrier et une fenêtre favorable, ce qui est la combinaison qui fait passer un projet d'infrastructure. Le meilleur moment pour remplacer un accès hérité est celui où quelque chose d'autre force déjà la question.

Ce que j'ai comparé, et ce que j'ai retenu

J'ai d'abord testé une solution d'accès plus complète. Elle est sérieuse, mais sa configuration était lourde pour ce que j'avais à couvrir. Je ne dis pas qu'elle est mauvaise, je dis qu'elle répondait à une question plus large que la mienne.

J'ai retenu Apache Guacamole pour quatre raisons, dans cet ordre : libre et gratuit, bien documenté, simple à prendre en main pour ceux qui l'utilisent, et couvrant les protocoles dont j'avais besoin dans la même interface.

L'ordre compte. Sur un projet mené seul, la qualité de la documentation pèse autant que la fonctionnalité : c'est elle qui décide si le déploiement prend deux semaines ou deux mois.

Ce qui a réellement emporté la décision

Ce n'est pas la réduction de surface d'attaque. C'est l'enregistrement des sessions.

Quand une intervention externe se passe mal, la discussion qui suit oppose deux récits. Le prestataire dit qu'il n'a pas touché à cela. L'équipe interne pense l'inverse. Sans trace, cette discussion n'a pas de fin, et elle se termine généralement par un compromis commercial plutôt que par un fait.

Avec un bastion qui enregistre, la session est rejouable. Ce n'est pas une surveillance des personnes, c'est une pièce au dossier. J'ai trouvé cet argument bien plus efficace que la sécurité pour faire accepter le changement, y compris auprès des prestataires eux-mêmes : la trace les protège autant qu'elle nous protège.

Ce que le bastion change vraiment

L'accès cesse d'être une route réseau pour devenir une session applicative. Le prestataire ouvre un navigateur, s'authentifie, et obtient exactement la machine et le protocole prévus. Il n'a pas d'adresse à connaître, pas de client à installer, rien à configurer chez lui.

Le seul chiffre que je donnerai est aussi le seul qui compte : aujourd'hui, 100 % des connexions d'un prestataire externe vers un service interne passent par le bastion. Pas la majorité, pas les nouvelles. Toutes. Un projet de ce type ne vaut que s'il ferme l'ancien chemin, sinon il ajoute une porte au lieu d'en remplacer une.

La montée en version que je croyais ordinaire

Je traitais les mises à jour de la passerelle comme celles de n'importe quel service : une fenêtre de maintenance, la nouvelle version, un contrôle rapide. Pour une version mineure, ça passait.

La première montée en version majeure a échoué. Les nouveaux binaires de la passerelle n'étaient pas compatibles avec la version de sa base de données, et je ne l'avais pas vérifié avant. Le problème n'était pas la procédure, c'était de découvrir la dépendance en production.

J'ai monté un serveur de test identique à celui de production. Toutes les montées en version majeures y passent d'abord. J'en sors les tenants et aboutissants, les étapes qui cassent et l'ordre dans lequel les faire, avant de toucher à la production. Sur un point d'accès unique, une mise à jour ratée ne coupe pas un service : elle coupe tous les prestataires en même temps.

Ce qu'Apache Guacamole ne fait pas

C'est une passerelle qui traduit les protocoles de bureau à distance et SSH vers le navigateur, sans rien installer côté client. Le poste du prestataire n'a besoin de rien : pas d'agent, pas de client lourd, pas de version à maintenir chez quelqu'un que je n'administre pas.

En revanche, je n'ai ni le support commercial ni les fonctions de découverte et de rotation de secrets que proposent les solutions payantes de gestion des accès à privilèges. C'était un arbitrage conscient et pas un oubli : je cherchais à supprimer les VPN prestataires, pas à déployer un coffre-fort d'identifiants. Un projet qui répond à une question plus large que la sienne ne se termine pas.

Trois choses à savoir avant de s'y engager. La passerelle détient les moyens de se connecter aux machines cibles : son durcissement et la protection de sa base de configuration ne sont pas optionnels. Le rendu passe par le navigateur, ce qui se paie sur les sessions graphiques chargées, et il faut l'essayer avec les vrais usages plutôt que sur une page de démonstration. Les enregistrements occupent de la place : je les compresse chaque jour, et leur empreinte sur le disque est devenue négligeable. Mais cette décision se prend avant le premier enregistrement, pas après.

J'ai mené le projet seul, de l'étude des solutions aux essais, puis à la communication, au déploiement en production, à la documentation et au maintien. C'est un travail d'ingénierie classique, et la partie technique n'en est pas le cœur.

La partie difficile

Elle est humaine.

Un prestataire qui travaille depuis dix ans avec un accès VPN n'a aucune envie de changer sa façon de faire pour arranger ma sécurité. La résistance est venue surtout des personnes présentes depuis longtemps, et elle se manifestait en télétravail, là où le VPN était devenu une habitude plutôt qu'un choix. Il faut annoncer, expliquer le bénéfice de leur point de vue, accompagner les premières connexions, et accepter que les premières semaines produisent plus de sollicitations que d'habitude.

J'ai aussi appris à ne pas couper les deux accès le même jour. Pendant une période, les deux chemins coexistent, et le nouveau devient le chemin par défaut avant que l'ancien ne soit fermé. Ce recouvrement coûte un peu de temps et évite l'incident qui aurait discrédité le projet.

La documentation compte autant que le déploiement. Un bastion que je suis seul à savoir administrer n'est pas une amélioration de la sécurité, c'est un risque déplacé.

Ce que j'ai accepté comme contrepartie

Le bastion devient un point de passage unique. S'il tombe, plus aucun prestataire ne travaille. Il concentre aussi les accès, donc il devient une cible de valeur : un attaquant qui l'atteint obtient d'un coup ce qui était auparavant dispersé. Cela se traite, par la supervision, la mise à jour, la séparation des droits et la sauvegarde, mais cela se traite sciemment.

L'enregistrement des sessions pose une question juridique, pas seulement technique. Ce sont des données qui concernent des personnes identifiées. Il faut informer, fixer une durée de conservation, décider qui peut relire un enregistrement et dans quelles circonstances. Une capacité d'enregistrement sans règle d'usage écrite est un problème en attente.

Enfin, un bastion ne remplace pas la gestion des comptes. Il contrôle par où l'on passe, pas qui a le droit d'entrer ni jusqu'à quand. Les revues d'accès restent nécessaires, simplement elles portent maintenant sur une liste que je peux lire.

Ce que je retiens pour la suite

Je formule désormais les demandes d'accès autrement. La question n'est plus « faut-il ouvrir un VPN », mais « quelle machine, pour quelle tâche, pendant combien de temps, et comment le saura-t-on après ». La plupart des demandes se réduisent beaucoup une fois posées ainsi.

Et je retiens qu'un projet de sécurité passe rarement grâce à un argument de sécurité. Celui qui a emporté la décision parlait de preuve en cas de litige, pas de surface d'attaque. Ce n'était pas un artifice de présentation : c'était le bénéfice que mes interlocuteurs pouvaient constater eux-mêmes.

J'ai retiré le VPN des prestataires