Pourquoi les hôtes bastion ajoutent des risques

Pour administrer des serveurs au sein d’un réseau privé, les équipes utilisaient traditionnellement un hôte bastion (également appelé serveur relais) : une instance renforcée et accessible depuis Internet à laquelle elles se connectaient d’abord en SSH, avant de rejoindre les machines internes. Bien que courant, ce modèle élargit votre surface d’attaque de plusieurs façons que l’examen SCS-C02 vous demande de reconnaître et d’éliminer.

Un hôte bastion se trouve dans un sous-réseau public, avec un port (généralement 22 pour SSH ou 3389 pour RDP) ouvert à Internet ou à une plage d’adresses IP d’entreprise. Les administrateurs s’y connectent, puis accèdent aux instances privées. Il constitue l’unique porte surveillée vers l’environnement, ce qui le rend à la fois essentiel et particulièrement ciblé.

Le principal risque vient du port entrant ouvert. Tout port SSH ou RDP accessible depuis Internet est constamment analysé et soumis à des attaques par force brute. Même avec une authentification par clé, un port exposé invite aux attaques, et une simple mauvaise configuration ou une vulnérabilité non corrigée sur le bastion peut donner aux attaquants un point d’appui dans l’ensemble de votre réseau.

L’accès au bastion repose généralement sur des paires de clés SSH à longue durée de vie distribuées aux administrateurs. Ces clés peuvent être copiées, perdues ou rester sur les ordinateurs portables d’anciens employés. Les renouveler sur tout un parc est laborieux, et il existe rarement un relevé fiable indiquant quelle clé a ouvert quelle session, ce qui compromet la traçabilité.

Il est difficile de suivre qui a fait quoi via un bastion. SSH natif fournit peu de journalisation centralisée des commandes exécutées sur les hôtes en aval. Enquêter sur un incident impose de rassembler les journaux des hôtes, et un bastion compromis pourrait permettre à un attaquant d’effacer ses propres traces : c’est exactement le manque de visibilité signalé par les auditeurs.

Le bastion est lui-même une instance que vous devez corriger et renforcer en continu. S’il prend du retard dans l’installation des mises à jour, il devient le maillon le plus faible. Maintenir un serveur relais hautement disponible et toujours sécurisé représente une charge opérationnelle permanente qui ajoute des coûts et des risques sans apporter de valeur métier.

Comme tout le trafic d’administration passe par le bastion, celui-ci constitue à la fois un point unique de défaillance et une cible de grande valeur. S’il tombe en panne, les administrateurs perdent l’accès ; s’il est compromis, l’attaquant dispose d’une base de lancement. Concentrer le risque dans un seul hôte exposé est une architecture que l’examen vous demande d’éviter.

AWS Systems Manager (SSM) Session Manager élimine entièrement le besoin de bastions. Il fournit un accès à un interpréteur de commandes aux instances via le service SSM, avec aucun port entrant ouvert, aucune adresse IP publique et aucune clé SSH. L’accès est contrôlé par IAM et chaque session est journalisée, ce qui remédie simultanément à toutes les faiblesses du modèle du bastion.

SSM fonctionne parce que l’instance exécute un SSM Agent qui établit une connexion sortante vers le service SSM ; rien n’est ouvert en entrée. Les groupes de sécurité peuvent refuser tout le trafic entrant et l’administration continue de fonctionner. Cette inversion, du sortant à la place de l’entrant, est l’idée clé qui rend les bastions obsolètes.

À l’examen, tout scénario décrivant des ports SSH/RDP ouverts, des paires de clés distribuées ou un serveur relais admet presque toujours une meilleure réponse : remplacer le bastion par Session Manager. Cette solution réduit la surface d’attaque, centralise le contrôle d’accès dans IAM et produit une piste d’audit complète : c’est la conception sécurisée et fondée sur le moindre privilège recommandée par AWS.

Un hôte bastion expose un port entrant, dépend de clés SSH persistantes, offre un audit insuffisant et doit être constamment corrigé, ce qui en fait une cible concentrée et attrayante. Le remplacement recommandé est SSM Session Manager, qui fournit un accès à l’interpréteur de commandes contrôlé par IAM et entièrement journalisé, avec aucun port ouvert, aucune adresse IP publique et aucune clé.

Testez pourquoi les bastions sont risqués.

Un hôte bastion ouvre un port SSH/RDP entrant, dépend de clés SSH à longue durée de vie, offre un audit insuffisant et exige l’installation constante de correctifs, concentrant ainsi le risque sur une seule cible exposée. SSM Session Manager le remplace par un accès contrôlé par IAM et entièrement journalisé, via une connexion d’agent sortante, sans nécessiter de port ouvert, d’adresse IP publique ni de clé.