Le bastion : la porte unique de l’administration

Un compte administrateur, c’est la clé de toutes les portes. Un bastion, c’est l’idée simple de n’avoir qu’une seule porte, bien gardée, où l’on sait qui entre, quand, et ce qu’il fait. Voici pourquoi c’est l’un des investissements les plus rentables de la sécurité opérationnelle, quelles solutions existent concrètement, et ce que chacune apporte ou coûte.

Pourquoi l’administration est la cible n° 1

Un attaquant qui compromet un poste bureautique gagne peu. Celui qui met la main sur un compte d’administration gagne tout : serveurs, sauvegardes, annuaire, hyperviseurs. Toute la sécurité d’un système d’information repose donc sur une question : comment les administrateurs se connectent-ils aux machines ?

Sans organisation particulière, la réponse est souvent la même : chaque serveur expose son propre accès (SSH, RDP…), chaque administrateur ou prestataire possède ses propres identifiants, et personne ne sait retracer facilement qui a fait quoi. C’est confortable au début, ingérable ensuite.

Que disent les chiffres ? Le rapport Verizon DBIR, référence annuelle fondée sur plus de 20 000 violations analysées, montre un paysage qui bouge :

  • DBIR 2025 : l’abus d’identifiants était le premier vecteur d’accès initial (22 %), devant l’exploitation de vulnérabilités (20 %) et l’hameçonnage (16 %) ;
  • DBIR 2026 : l’exploitation de vulnérabilités devient pour la première fois le premier vecteur (31 %), l’abus d’identifiants tombe à 13 %. Verizon précise que cette baisse est en partie due à un changement de classement (le « prétexting » a été ajouté comme vecteur distinct) : à périmètre comparable, l’abus d’identifiants serait de 16 %, et il reste présent à toutes les étapes des attaques ;
  • seules 26 % des vulnérabilités critiques du catalogue CISA KEV ont été entièrement corrigées en 2025 (38 % l’année précédente), avec un délai médian de 43 jours.
Graphique : exploitation de vulnérabilités 20 % en 2025 puis 31 % en 2026 ; abus d'identifiants 22 % puis 13 %
Vecteurs d’accès initial, Verizon DBIR 2025 et 2026.

La leçon n’est pas « le bastion règle tout » : il ne corrige pas une vulnérabilité. Elle est double. Les identifiants d’administration restent un maillon critique, et réduire le nombre de portes exposées limite mécaniquement ce que l’exploitation d’une faille peut atteindre. C’est exactement le rôle du bastion.

Qu’est-ce qu’un bastion, concrètement ?

L’ANSSI le définit comme « une déclinaison du rebond » : une machine intermédiaire par laquelle passent toutes les connexions d’administration vers les serveurs. Les bastions concentrent généralement plusieurs fonctions de sécurité :

  • Authentification centralisée : une seule authentification forte (MFA) en amont, au lieu d’un mot de passe par serveur ;
  • Traçabilité : qui s’est connecté, quand, à quoi, et souvent l’enregistrement de la session elle-même ;
  • Gestion des secrets : les mots de passe ou clés des serveurs sont stockés dans un coffre, injectés à la connexion, et renouvelés automatiquement, l’administrateur ne les voit jamais ;
  • Cloisonnement : les serveurs n’acceptent l’administration que depuis le bastion, ce qui réduit le nombre de ports exposés ;
  • Droits au juste besoin : accès par rôle, limité dans le temps, avec validation pour les opérations sensibles.
Schéma comparant une administration sans bastion, avec neuf chemins directs vers les serveurs, et avec bastion, avec une seule porte
Sans bastion, chacun atteint chaque serveur. Avec bastion, tout passe par un point unique de contrôle et de traçabilité.

Ce que recommande l’ANSSI, et ses avertissements

Le guide de l’ANSSI sur l’administration sécurisée des systèmes d’information (version 3.0, 2021, section 13.1) consacre un passage au bastion. Il ne l’impose pas : il encadre son usage. Trois points à retenir :

  • Un bastion ne remplace rien. Il ne se substitue ni au cloisonnement du SI d’administration ni à la sécurisation du poste d’administration ;
  • Il est lui-même une ressource critique, car il concentre potentiellement des secrets d’authentification et les journaux des actions d’administration. Il ne doit donc pas être exposé sur un SI de faible niveau de confiance, un SI bureautique par exemple ;
  • Il se déploie dans le SI d’administration. L’ANSSI juge « à proscrire » l’usage d’un bastion comme moyen d’interconnexion d’un SI bureautique et d’un SI d’administration : cela procurerait un faux sentiment de sécurité, le bastion devenant une « opportunité d’attaque considérable » depuis un poste bureautique connecté à Internet.

L’ANSSI met aussi en garde contre l’effet « nom commercial » : comme tout produit de sécurité, un bastion demande de la vigilance sur son choix, son déploiement et son exploitation.

Un cas réel : Uber, septembre 2022

En septembre 2022, un attaquant s’introduit dans les systèmes d’Uber. Selon le communiqué officiel de l’entreprise, le point d’entrée est le compte d’un prestataire : l’appareil personnel du prestataire avait été infecté par un logiciel malveillant et son mot de passe aurait été mis en vente sur le dark web. L’attaquant a ensuite bombardé le prestataire de demandes d’authentification multifacteur jusqu’à ce qu’il en accepte une (la « fatigue MFA »). Uber a attribué l’attaque à un acteur affilié au groupe Lapsus$.

Une fois à l’intérieur, l’attaquant aurait trouvé sur le réseau interne un script PowerShell contenant en clair les identifiants d’administrateur de la solution de gestion des accès privilégiés (PAM) de l’entreprise, ce qui lui aurait ouvert de nombreux systèmes. Attention à l’attribution : ce détail vient d’informations relayées par la presse spécialisée (The Register, New York Times) d’après les déclarations de l’attaquant et de chercheurs, il ne figure pas dans le communiqué d’Uber.

L’enseignement est double. D’une part, la robustesse d’un bastion dépend de celle des secrets qui le protègent : un coffre-fort dont la clé traîne dans un script ne protège rien. D’autre part, l’authentification multifacteur par simple notification « accepter » est vulnérable à la fatigue : privilégier les méthodes résistantes à l’hameçonnage (clés FIDO2, correspondance de numéro).

Panorama : six familles de bastions, avec leurs avantages et leurs limites

Il n’existe pas de « meilleur » bastion, seulement un bastion adapté à un contexte. Voici les solutions les plus courantes, du plus simple au plus complet. Les éléments de licence et de fonctionnalités sont ceux constatés en septembre 2026 : à revérifier avant toute décision.

1. OpenSSH avec ProxyJump : le bastion minimaliste

Depuis OpenSSH 7.3 (août 2016), l’option -J (ProxyJump) permet de traverser une machine de rebond en une seule commande : ssh -J bastion serveur. Un simple serveur Linux durci suffit.

  • Avantages : gratuit, aucun logiciel supplémentaire, très facile à auditer, chiffrement de bout en bout entre le poste et le serveur cible, mise en place en quelques minutes ;
  • Limites : justement à cause de ce chiffrement de bout en bout, le rebond ne voit pas le contenu et ne peut pas enregistrer les sessions ; pas de coffre de secrets ni de MFA intégré (à ajouter via clés matérielles ou PAM) ; gestion manuelle des droits et des clés, qui devient pénible au-delà de quelques dizaines d’utilisateurs ; SSH uniquement, pas de RDP.

2. Apache Guacamole : le bastion web sans client

Projet de la fondation Apache (licence Apache 2.0), Guacamole est une passerelle « sans client » : l’administrateur accède en SSH, RDP ou VNC depuis un simple navigateur.

  • Avantages : gratuit et open source, un seul point d’entrée web pour plusieurs protocoles (utile pour les serveurs Windows en RDP), pas de logiciel à installer sur les postes, authentification renforçable par des extensions (TOTP, SSO), enregistrement des sessions possible ;
  • Limites : ce n’est pas un PAM complet : pas de coffre-fort avec rotation automatique des secrets, workflow d’approbation limité ; il faut l’exposer avec soin (l’interface web devient la cible) et assurer soi-même sa mise à jour ; l’expérience dans un navigateur est moins fluide qu’un client natif.

3. JumpServer : le PAM open source complet

JumpServer (licence GPLv3) se présente comme une plateforme de gestion des accès privilégiés open source : SSH, RDP, bases de données, Kubernetes, enregistrement des sessions, coffre de comptes.

  • Avantages : couverture fonctionnelle proche d’un PAM commercial, sans licence pour l’édition communautaire, traçabilité et enregistrement de sessions, interface unifiée ;
  • Limites : certaines fonctions avancées sont réservées à l’offre payante ; plateforme lourde à déployer et à maintenir ; et son historique montre que le bastion est lui aussi une cible : la faille CVE-2023-42442 (publiée le 15 septembre 2023, corrigée en 3.5.5 et 3.6.4) permettait à un utilisateur non authentifié de télécharger des enregistrements de sessions, donc potentiellement des secrets. Mise à jour rapide indispensable.

4. Teleport : l’accès moderne par certificats de courte durée

Teleport unifie l’accès à SSH, RDP, Kubernetes, bases de données et applications web. Son principe : plus de clés statiques, mais des certificats éphémères délivrés après authentification forte (SSO, MFA), avec audit et enregistrement des sessions.

  • Avantages : suppression des clés et mots de passe de longue durée (un secret volé expire vite), multi-protocoles, traçabilité fine, très adapté aux environnements cloud et Kubernetes ;
  • Limites : depuis la version 16 (juin 2024), l’édition Community est sous licence commerciale : gratuite uniquement pour les organisations de moins de 100 employés et de moins de 10 M$ de chiffre d’affaires (le dépôt de code reste en AGPLv3) ; les fonctions d’entreprise (SSO avancé, conformité) sont payantes ; demande un vrai effort d’apprentissage.

5. HashiCorp Boundary : l’accès par identité, sans exposer le réseau

Boundary donne accès à des ressources précises selon l’identité de l’utilisateur, sans lui ouvrir l’ensemble d’un réseau, et s’intègre à Vault pour les secrets. Il est réputé plus complexe à déployer que ses concurrents.

  • Avantages : modèle d’autorisation fin fondé sur l’identité, bonne intégration à l’écosystème HashiCorp (Vault, Terraform), pensé pour les infrastructures dynamiques et multi-cloud ;
  • Limites : licence BSL 1.1 depuis août 2023 (code visible, mais pas open source au sens de l’OSI) ; déploiement et exploitation exigeants ; gouvernance de l’éditeur à surveiller (HashiCorp a été rachetée par IBM, opération finalisée le 27 février 2025) ; surdimensionné pour un petit parc.

6. Les bastions du cloud : Azure Bastion et AWS Session Manager

Les fournisseurs de cloud proposent un accès administrateur « clé en main ». Azure Bastion est un service géré (offres Developer, Basic, Standard et Premium) : connexion RDP/SSH depuis le portail Azure en TLS sur le port 443, sans adresse IP publique sur les machines virtuelles. AWS Systems Manager Session Manager permet d’ouvrir une session sur une instance sans port entrant, sans bastion à héberger et sans clé SSH, avec des droits gérés par IAM et des journaux (CloudTrail, S3, CloudWatch).

  • Avantages : rien à installer ni à patcher côté client, intégration native à l’identité et à la journalisation du cloud, aucun port d’administration ouvert vers Internet ;
  • Limites : valables seulement pour les machines du fournisseur concerné (et dépendance à celui-ci) ; coût continu (Azure Bastion est facturé à l’heure, même sans usage) ; l’enregistrement de session vidéo n’existe qu’en offre Premium sur Azure ; sur AWS, les sessions SSH et les redirections de port ne sont pas journalisées dans Session Manager.

Et les PAM du commerce ?

Les solutions commerciales de PAM (WALLIX Bastion, CyberArk, Delinea, One Identity…) offrent la palette complète : coffre-fort, rotation automatique, workflows d’approbation, enregistrement, rapports d’audit. Exemple français : WALLIX Bastion, dont la version 6.0.102 a obtenu en 2020 une certification de sécurité de premier niveau (CSPN) de l’ANSSI, un gage utile pour les organisations soumises à des exigences réglementaires.

  • Avantages : couverture fonctionnelle la plus large, support éditeur, certifications, adapté aux exigences d’audit ;
  • Limites : coût de licence et de mise en œuvre élevé, projet d’intégration lourd, dépendance à un éditeur. Et rappel de l’ANSSI : le nom « bastion » ne garantit pas la sécurité, la qualification ou la certification d’une version précise est à vérifier.

Comparatif rapide

SolutionCoûtProtocolesEnregistrement des sessionsSecrets / rotationEffort d’exploitation
OpenSSH ProxyJumpGratuitSSHNonNonTrès faible
Apache GuacamoleGratuitSSH, RDP, VNCOui (possible)NonFaible à moyen
JumpServerGratuit (édition communautaire) / payantSSH, RDP, bases, KubernetesOuiOuiMoyen à élevé
TeleportGratuit sous conditions / payantSSH, RDP, Kubernetes, bases, webOuiCertificats éphémèresMoyen
HashiCorp BoundaryGratuit (BSL) / payantSSH, RDP, bases, TCPSelon éditionVia VaultÉlevé
Azure Bastion / AWS SSMÀ l’usageRDP, SSH (SSM : shell)Premium (Azure) / partiel (AWS)Via IAM / Key VaultTrès faible
PAM commercial (WALLIX…)Licence élevéeTrès largeOuiOuiMoyen à élevé

Ce tableau est un repère de synthèse : les capacités évoluent selon les versions et les éditions, vérifiez la documentation de l’éditeur avant de choisir.

Le bastion est lui-même une cible

C’est le paradoxe : en concentrant les accès, on crée un objet de valeur. Ce constat est celui de l’ANSSI, et il se vérifie : la faille de JumpServer citée plus haut permettait de récupérer des enregistrements de sessions, et l’affaire Uber a montré ce que devient un coffre-fort dont l’accès administrateur est stocké en clair. Un bastion mal protégé est pire que pas de bastion, car il donne un faux sentiment de sécurité.

Il faut donc le traiter comme l’actif le plus sensible de l’administration :

  1. Le placer dans la zone d’administration, jamais sur le réseau bureautique, et n’exposer sur Internet que ce qui est strictement nécessaire ;
  2. Imposer une authentification forte résistante à l’hameçonnage (clés FIDO2) pour tous les comptes qui l’utilisent, sans exception pour « les urgences » ;
  3. Fermer les accès directs : les serveurs n’acceptent l’administration que depuis le bastion (pare-feu), sinon le contournement annule tout l’intérêt ;
  4. Le mettre à jour en priorité et s’abonner aux avis de sécurité de l’éditeur : c’est un service exposé, donc exposé aux failles, la première cause d’intrusion dans le DBIR 2026 ;
  5. Ne jamais laisser de secrets en clair à côté (scripts, dépôts, notes) : rechercher régulièrement les identifiants oubliés ;
  6. Journaliser hors du bastion : envoyer les logs vers un système séparé (SIEM), sinon un attaquant qui prend le bastion efface aussi ses traces ;
  7. Sauvegarder et tester la restauration : le bastion ne doit pas devenir le point de panne unique de l’exploitation ; prévoir une procédure d’accès de secours contrôlée (« break glass »), stockée hors ligne ;
  8. Sécuriser aussi le poste d’administration : un bastion n’y change rien si le poste qui s’y connecte est compromis.

Comment choisir

Guide de choix : quelle solution de bastion selon le besoin, de OpenSSH ProxyJump aux PAM commerciaux
Repères de choix selon le contexte. Ce ne sont pas des règles absolues.

Quelques questions pour trancher :

  • Combien de serveurs et d’administrateurs ? Moins de dix machines Linux : un rebond OpenSSH durci et des clés matérielles valent déjà mieux que rien ;
  • Quels protocoles ? Du RDP Windows impose Guacamole, JumpServer, Teleport ou un PAM ; du Kubernetes et des bases orientent vers Teleport ou Boundary ;
  • Faut-il prouver ce qui s’est passé ? Exigence d’audit, de conformité ou de prestataires externes : l’enregistrement de sessions devient obligatoire, donc exit le simple ProxyJump ;
  • Qui l’exploite ? Sans équipe pour patcher et surveiller, préférer un service géré. Un bastion open source non maintenu est un risque ;
  • Où sont les machines ? Tout dans un seul cloud : l’outil natif est le plus simple. Infrastructure mixte : une solution indépendante du fournisseur.

En résumé

Un bastion n’est pas un produit magique, c’est un principe d’organisation : une seule porte, authentifiée, tracée, et fermée à tout le reste. Bien conçu, il réduit la surface d’attaque, apporte la traçabilité et supprime les secrets partagés. Mal placé ou mal entretenu, il concentre les risques. Commencez petit si nécessaire, mais commencez : un rebond SSH durci avec clés matérielles est déjà un progrès considérable par rapport à des accès ouverts partout.

Transparence : cet article a été rédigé avec l’aide d’un assistant Claude. Les faits, chiffres et références ont été vérifiés auprès des sources primaires listées ci-dessous lorsqu’elles existent, et les informations relayées par la presse ou les éditeurs sont signalées comme telles. Les caractéristiques des produits évoluent vite : consultez la documentation officielle avant toute décision. Les faits sont arrêtés à fin septembre 2026.

À lire aussi

Sources