# J'ai retiré le VPN des prestataires

Langue : fr

Identifiant : article:bastion-plutot-que-vpn

Noa Matout

Pourquoi un accès réseau pour un besoin applicatif est une mauvaise affaire, et ce que j'ai appris en le remplaçant par un bastion.

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.

## Périmètre de la mesure

providerAccessCoveragePercent : 100 %. Part des connexions d'un prestataire externe vers un service interne qui passent par le bastion.