Serveur Bastion en 2026 : Définition, Architecture et Déploiement pour les Entreprises

Un serveur bastion (ou bastion host) est un serveur durci, exposé sur un réseau non sécurisé ou en zone démilitarisée (DMZ), dont le rôle unique est de servir de point d’entrée contrôlé vers les ressources internes sensibles d’un système d’information. En 2026, le serveur bastion constitue la pièce maîtresse de toute stratégie d’accès privilégié en entreprise : il centralise l’authentification, l’autorisation et la journalisation de chaque session administrateur, qu’elle soit initiée depuis un réseau interne ou depuis Internet.

Qu’est-ce qu’un serveur bastion et comment fonctionne-t-il ?

Un serveur bastion est un hôte réseau à fonction unique, positionné à l’intersection entre une zone non fiable (Internet, réseau partenaire) et les systèmes de production internes. Il n’expose qu’un nombre minimal de services — typiquement SSH sur le port 22 (TCP) ou HTTPS sur le port 443 pour les interfaces web — et refuse toute autre connexion entrante.

Principe de fonctionnement : l’administrateur se connecte d’abord au bastion via SSH ou HTTPS avec authentification multi-facteurs (MFA). Le bastion valide l’identité, vérifie les autorisations, ouvre une session vers la cible interne, et enregistre l’intégralité du flux (session recording). L’utilisateur ne dispose jamais d’un accès direct aux serveurs cibles : le bastion est le seul chemin autorisé.

• Port d’écoute standard : TCP/22 (SSH), TCP/443 (HTTPS/WebSocket)
• Protocoles supportés : SSH v2, RDP over HTTPS, Kubernetes API, bases de données via tunnel TLS
• Authentification : clé publique SSH + TOTP, clé matérielle FIDO2/WebAuthn, certificats x.509
• Journalisation : logs structurés (syslog/JSON), enregistrement vidéo de session (session replay), audit trail immuable

Le terme bastion vient de l’architecture militaire : une fortification avancée conçue pour résister aux assauts tout en protégeant l’arrière. En sécurité réseau, le concept a été formalisé dès les années 1990 par Marcus Ranum, architecte de l’un des premiers pare-feux commerciaux.

Bastion host vs VPN : quelle différence pour l’accès distant ?

Un VPN (Virtual Private Network) et un serveur bastion répondent à des besoins différents et complémentaires. Leur confusion est fréquente, mais leurs architectures de sécurité divergent fondamentalement.

Le VPN, qu’il s’appuie sur OpenVPN, WireGuard ou IKEv2, crée un tunnel chiffré qui donne à l’utilisateur une présence réseau complète dans le LAN distant. Cela expose l’ensemble du segment réseau à une machine potentiellement compromise. Le bastion, lui, ne propage pas de connectivité réseau : il relaie des sessions applicatives sous contrôle strict. Pour les accès administrateurs aux infrastructures critiques, l’ANSSI recommande explicitement le recours à un bastion plutôt qu’à un VPN simple.

Pour approfondir les protocoles de tunneling, consultez notre article sur OpenVPN comme VPN professionnel et notre guide sur le protocole IPSec.

Architecture d’un bastion : DMZ, SSH jump, PAM, MFA

Une architecture bastion robuste repose sur quatre composants interdépendants : le positionnement réseau en DMZ, le mécanisme de rebond SSH (SSH jump), le module PAM (Privileged Access Management), et l’authentification multi-facteurs.

Positionnement réseau : la DMZ isolée

Le bastion réside dans une DMZ dédiée, isolée du LAN de production par un pare-feu interne et d’Internet par un pare-feu périmétrique. Les règles de pare-feu autorisent uniquement :

• Entrant vers le bastion : TCP/22 ou TCP/443 depuis les plages IP autorisées
• Sortant depuis le bastion : TCP/22 vers les serveurs Linux, TCP/3389 vers les serveurs Windows, TCP/5432 vers PostgreSQL, etc. — uniquement vers les cibles explicitement listées
• Zéro flux de production vers le bastion (pas de retour non sollicité)

SSH ProxyJump et ProxyCommand

La configuration cliente SSH utilise les directives ProxyJump (SSH 7.3+) ou ProxyCommand pour établir un tunnel transparent via le bastion :

# Méthode ProxyJump (recommandée, OpenSSH 7.3+)
Host serveur-prod-01
    HostName 10.0.1.50
    User admin
    ProxyJump bastion.example.com

# Méthode ProxyCommand (compatibilité étendue)
Host serveur-prod-01
    HostName 10.0.1.50
    ProxyCommand ssh -W %h:%p bastion.example.com

PAM : Privileged Access Management

PAM (Privileged Access Management) est la couche logicielle qui gouverne les accès à privilèges élevés. Intégré au bastion, il assure :

• La gestion du cycle de vie des comptes privilégiés (provisioning/deprovisioning)
• Le coffre-fort de mots de passe et de clés SSH (rotation automatique, check-out/check-in)
• Le workflow d’approbation (just-in-time access, approbation 4-yeux)
• La corrélation des sessions avec les tickets ITSM (ServiceNow, Jira)

MFA : authentification multi-facteurs obligatoire

L’ANSSI, dans son guide sur la sécurisation des accès administrateurs (ANSSI-PA-022), impose une authentification forte pour tout accès à un système d’information sensible. Sur un bastion, le MFA combine obligatoirement :

• Un facteur de connaissance (mot de passe ou passphrase SSH)
• Un facteur de possession : TOTP (RFC 6238, algorithme HMAC-SHA1/SHA256, fenêtre de 30 secondes), ou clé matérielle FIDO2/WebAuthn (YubiKey, clé Titan)

Comment déployer un serveur bastion en entreprise ?

Le déploiement d’un serveur bastion suit une séquence rigoureuse en sept étapes.

Étape 1 : Conception de l’architecture réseau

Définir la DMZ dédiée, les règles de pare-feu entrantes et sortantes, et les plages IP sources autorisées. Documenter les flux dans une matrice de flux conforme aux exigences de l’ANSSI (guide ANSSI-BP-028).

Étape 2 : Sélection et durcissement de l’OS

Utiliser une distribution Linux minimale (Debian stable, Rocky Linux, Ubuntu LTS). Appliquer un CIS Benchmark niveau 2. Désactiver tous les services inutiles. Configurer sshd_config : PermitRootLogin no, PasswordAuthentication no, AllowUsers bastion-users, MaxAuthTries 3.

Étape 3 : Installation du logiciel bastion

Choisir une solution adaptée au contexte (voir section comparaison). Configurer l’intégration LDAP/Active Directory pour la synchronisation des identités.

Étape 4 : Configuration MFA et PKI

Déployer une PKI interne ou s’appuyer sur une CA cloud pour émettre des certificats SSH à courte durée de vie (TTL de 8 heures recommandé). Configurer le module TOTP ou l’intégration FIDO2.

Étape 5 : Intégration PAM et coffre-fort

Connecter le bastion au coffre-fort de secrets (HashiCorp Vault, CyberArk, Delinea). Configurer la rotation automatique des mots de passe des comptes de service (toutes les 24h pour les comptes à hauts privilèges).

Étape 6 : Configuration de l’audit et de la journalisation

Activer l’enregistrement de session (session recording) en format texte asciinema et/ou vidéo. Envoyer les logs vers un SIEM (Splunk, Elastic SIEM, Microsoft Sentinel) via syslog TLS (RFC 5425, port TCP/6514). Configurer les alertes sur les comportements anormaux (connexion hors plage horaire, volume de commandes anormal).

Étape 7 : Tests de pénétration et revue de configuration

Effectuer un pentest ciblé sur le bastion avant mise en production. Vérifier l’absence de chemins de contournement. Programmer des revues trimestrielles des droits d’accès et des comptes actifs.

Bastion dans une architecture Zero Trust en 2026

Le modèle Zero Trust (NIST SP 800-207) repose sur le principe fondamental : aucune confiance implicite n’est accordée à aucun utilisateur, aucun appareil, aucun réseau — même interne. Chaque accès doit être authentifié, autorisé et journalisé, à chaque tentative.

Le serveur bastion est l’implémentation opérationnelle naturelle du Zero Trust pour les accès d’infrastructure :

• Verify explicitly : chaque session est authentifiée par MFA + certificat à courte durée de vie. L’identité est vérifiée à chaque connexion, sans session persistante.
• Use least privilege access : le bastion n’ouvre que la session demandée vers la cible demandée, pour la durée demandée (just-in-time access). Aucune connectivité réseau permanente n’est accordée.
• Assume breach : toutes les sessions sont enregistrées intégralement. En cas de compromission d’un compte, l’audit trail permet une analyse forensique complète.

En 2026, les bastions modernes s’intègrent nativement aux Identity Providers (IdP) OIDC/SAML2 (Okta, Microsoft Entra ID, Ping Identity), permettant une propagation instantanée des révocations de droits. La combinaison bastion + IdP + SIEM constitue le socle technique d’une architecture Zero Trust for Infrastructure Access.

L’ANSSI, dans ses recommandations sur la sécurisation des systèmes d’information (ANSSI-PA-022 et guide d’hygiène informatique), impose l’usage d’un bastion pour tout accès administrateur distant aux systèmes qualifiés, y compris dans les Organismes d’Importance Vitale (OIV) et les Opérateurs de Services Essentiels (OSE) soumis à la directive NIS2.

Bastion open source vs solutions cloud (AWS, Azure, GCP, Teleport, Boundary)

Pour les entreprises soumises à des contraintes de souveraineté des données (hébergement en France, qualification SecNumCloud), les solutions auto-hébergées comme Teleport ou une implémentation sur mesure basée sur OpenSSH restent préférables aux services cloud américains.

Questions fréquentes sur le serveur bastion

Quelle est la différence entre un serveur bastion et un jump server ?

Les termes bastion host et jump server (ou jump box) sont souvent utilisés comme synonymes, mais ils diffèrent par leur niveau de sécurisation. Un jump server est simplement un serveur intermédiaire permettant de rebondir vers d’autres machines — sans nécessairement intégrer d’audit, de MFA ou de session recording. Un serveur bastion est un jump server durci et instrumenté : il intègre le contrôle d’accès, l’enregistrement de session, l’authentification forte et l’intégration PAM.

Le serveur bastion peut-il être compromis ? Quels sont les risques ?

Oui. Le bastion est une cible de choix pour les attaquants précisément parce qu’il est exposé et donne accès aux systèmes internes. Les vecteurs d’attaque principaux sont : exploitation de vulnérabilités du service SSH, attaques par force brute (mitiger avec fail2ban, rate limiting, IP allowlisting), et compromission de comptes (mitiger avec MFA obligatoire et rotation des secrets).

Faut-il un bastion si l’entreprise utilise déjà un VPN ?

Oui, les deux ne sont pas substituables pour les accès administrateurs. Le VPN élargit le périmètre réseau accessible — ce qui augmente la surface d’attaque en cas de compromission du poste utilisateur. Le bastion, lui, restreint chaque accès à une session applicative précise, avec authentification et enregistrement.

SSH sur quel port pour un bastion en production ?

Par défaut, SSH écoute sur le port TCP/22. La pratique recommandée est de maintenir TCP/22 en combinant une allowlist IP stricte au niveau pare-feu, une authentification par clé publique uniquement (PasswordAuthentication no), et un MFA secondaire.

Quelle norme ou recommandation encadre l’usage des bastions en France ?

L’ANSSI publie plusieurs guides applicables : le guide ANSSI-PA-022 (administration sécurisée des SI), le guide d’hygiène informatique (mesure 14 : sécuriser les accès distants), et les recommandations NIS2 pour les OSE/OIV. Ces documents imposent l’usage d’un bastion pour tout accès administrateur distant, avec MFA obligatoire, journalisation centralisée et revue régulière des droits.