Bastion SSH : à quoi il sert

Réponse courte

Un bastion SSH est un serveur intermédiaire par lequel transitent toutes les connexions vers une infrastructure. Il concentre les accès en un point unique, ce qui permet de les journaliser, de les restreindre et de les révoquer sans toucher à chaque machine. On parle aussi de rebond ou de jump host.

Sur cette page

01 À quoi sert un bastion
02 À partir de quand cela se justifie
03 Les erreurs qui vident un bastion de son intérêt
04 Les repères en un tableau

À quoi sert un bastion

Un bastion est le point de passage unique par lequel transitent toutes les connexions vers les serveurs. Au lieu d'ouvrir chaque machine au monde extérieur, on n'en expose qu'une, surveillée et journalisée.

L'intérêt est de réduire la surface exposée : une seule machine à durcir, à mettre à jour et à surveiller, au lieu de toutes. Les serveurs applicatifs n'acceptent plus de connexion que depuis le bastion.

Le second intérêt est la traçabilité. Toutes les connexions passant par le même point, le journal du bastion dit qui s'est connecté, quand, et vers quelle machine, ce qu'aucun serveur isolé ne saurait dire à l'échelle du parc.

Le corollaire est que le bastion devient une cible et un point de défaillance unique. Il exige donc un niveau de soin supérieur à celui des machines qu'il protège.

À partir de quand cela se justifie

Dès que plusieurs personnes accèdent à plusieurs serveurs. En dessous, le coût d'exploitation dépasse le bénéfice ; au-dessus, l'absence de bastion rend l'inventaire des accès pratiquement impossible.

Le seuil n'est pas un nombre de serveurs mais un nombre de combinaisons personne-machine. Trois personnes sur cinq serveurs font quinze accès à suivre, ce qu'aucune mémoire ne tient.

Le déclencheur le plus fréquent est l'arrivée de prestataires externes. Leur donner un accès direct à chaque machine crée des autorisations qu'on oublie de retirer.

Pour une infrastructure d'une seule machine avec un seul administrateur, un bastion ajoute de la complexité sans réduire de risque.

Les erreurs qui vident un bastion de son intérêt

Laisser des accès directs subsister en parallèle, partager un compte sur le bastion, et ne jamais relire les journaux qu'il produit.

Le contournement est l'erreur la plus commune : le bastion est installé, mais les anciennes autorisations directes restent en place « au cas où ». Le point de passage cesse alors d'être unique, et la traçabilité disparaît.

Le compte partagé annule le bénéfice principal. Le journal indique alors qu'une connexion a eu lieu, sans dire qui l'a faite.

Enfin, un journal que personne ne lit ne sert qu'après l'incident. Une relecture périodique, même rapide, transforme un outil de constat en outil de détection.

Questions fréquentes

Un bastion est-il nécessaire pour une petite infrastructure ?

Pas pour une machine unique avec un seul administrateur : il ajoute de la complexité sans réduire de risque. Il devient utile dès que plusieurs personnes accèdent à plusieurs serveurs, parce que le nombre de combinaisons à suivre devient ingérable.

Le bastion ne devient-il pas un point de défaillance unique ?

Si, et c'est le prix à payer. Il exige donc un durcissement, des mises à jour et une surveillance supérieurs à ceux des machines qu'il protège. En contrepartie, il n'y a qu'une machine à traiter avec ce niveau de soin.

Peut-on garder des accès directs en parallèle ?

C'est l'erreur la plus fréquente et elle vide le dispositif de son intérêt. Si des autorisations directes subsistent, le point de passage n'est plus unique et la traçabilité disparaît.

Sources

OpenSSH : documentation officielle

Savoir où vous en êtes avant d'agir

Le Diagnostic IA relève ce que les moteurs, classiques et génératifs, affichent aujourd'hui à propos de votre activité, et pointe les écarts à corriger en premier.

Cartographier mes accès