Dans beaucoup d’entreprises, le sujet du Bastion cybersécurité arrive souvent après un incident : un prestataire qui a gardé un compte admin, un audit qui pointe des accès à privilèges totalement opaques, ou un ransomware qui a exploité un compte de domaine trop large. Le bastion vient justement répondre à ce problème très concret : reprendre la main sur les comptes à privilèges, tracer chaque session et limiter la casse quand un identifiant fuit. Une partie des équipes se tourne vers des solutions éditeurs, d’autres regardent de près les solutions PAM open source, notamment pour des contextes industriels ou des environnements hybrides. Entre le discours marketing et la réalité des consoles, il existe un écart que beaucoup découvrent trop tard.
Ce texte pose les choses à plat. D’abord en expliquant le rôle opérationnel d’un bastion dans une architecture de sécurité informatique qui mélange IT et OT, ensuite en détaillant son fonctionnement réel au quotidien, avec des exemples d’intégration à la gestion des identités et à l’authentification forte. Les usages concrets seront abordés à travers une PME industrielle fictive, MétalNord, qui doit sécuriser l’accès sécurisé de ses prestataires de maintenance sur des automates et des serveurs Windows. Enfin, l’article ouvrira le capot de quelques briques open source pour le PAM, avec leurs forces, leurs angles morts et une manière pragmatique de les assembler sans y passer deux ans. L’objectif n’est pas de rêver un SOC de grand groupe, mais de décrire ce qui tient, ce qui se déploie, et ce qui se maintient un lundi matin à 6 h.
- Un bastion cybersécurité sert à concentrer, filtrer et tracer tous les accès à privilèges, internes comme externes.
- Les solutions PAM reposent sur quelques briques clés : coffre-fort d’identifiants, rotation, proxy RDP/SSH et surveillance des accès.
- Il existe aujourd’hui un écosystème open source sérieux pour bâtir un bastion, à condition d’accepter un peu d’intégration maison.
- Un bastion mal paramétré crée un faux sentiment de protection des privilèges et peut masquer des failles de contrôle d’accès.
- Pour une PME, mieux vaut un périmètre réduit mais propre, avec quelques comptes critiques bien cadrés, plutôt qu’un bastion qui prétend tout couvrir sans profondeur.
Rôle concret d’un bastion cybersécurité dans une architecture hybride IT/OT
Dans les présentations, un bastion ressemble parfois à une boîte magique qui règle la sécurité informatique en une diapositive. Sur le terrain, son rôle se résume à trois axes : concentrer les flux d’accès sécurisé, contrôler et limiter les privilèges, puis enregistrer les preuves d’usage. Cette triple mission devient critique dès que plusieurs admins se partagent un même SI, avec des prestataires, des intégrateurs et parfois des équipes OT qui travaillent encore avec des comptes partagés « admin » sur des automates ou des serveurs SCADA.
Dans une PME comme MétalNord, on trouve ce cocktail classique : un domaine Active Directory vieillissant, quelques VM dans le cloud, des automates Siemens et Schneider, un MES un peu ancien, et deux intégrateurs externes qui se connectent à distance pour maintenir tout ça. Sans bastion, chacun a ses identifiants, les mots de passe transitent dans des fichiers chiffrés plus ou moins bien, et la moindre enquête post-incident se transforme en roman d’espionnage sans fin. L’ajout d’un Bastion cybersécurité change le modèle : les admins ne « voient » plus les mots de passe des comptes techniques, ils passent par une brique qui ouvre pour eux la session cible, tout en la journalisant.
Le bastion devient alors un passage obligé pour toute opération à privilèges. Non pas par lubie d’auditeur, mais pour une raison simple : en cas de compromission, il faut être capable de dire qui a fait quoi, quand, et depuis où. L’enregistrement des sessions RDP, des commandes SSH, ou au moins des métadonnées d’accès, permet de remonter un scénario d’attaque en quelques heures au lieu de quelques jours. Ce n’est pas qu’une question de conformité, c’est aussi une manière de limiter la surface d’improvisation quand l’équipe est sous pression.
Autre rôle souvent sous-estimé : la traduction entre mondes IT et OT. Dans un atelier, il n’est pas rare de voir des postes de supervision sans domaine, avec des comptes locaux « opérateur », « technicien » et « admin ». Le bastion peut servir de point d’entrée unique pour les opérateurs d’astreinte, avec un contrôle d’accès adapté aux horaires, aux profils et aux zones. Il n’éteindra pas d’un coup toutes les mauvaises habitudes, mais il constitue un point d’ancrage pour commencer à reprendre la main sur les comptes locaux élevés.
Du côté de la direction, le bastion sert aussi de levier de négociation avec les prestataires. Un intégrateur qui réclame un compte admin permanent sur le domaine reçoit plutôt une proposition claire : accès via le bastion, surveillance des accès, horaires limités, justification des sessions et journalisation. Ceux qui refusent en bloc envoient un signal assez clair sur leur maturité. Ceux qui acceptent montrent qu’ils ont l’habitude de travailler en environnement encadré. Cela aide à sélectionner ses partenaires sans discours grandiloquent.
Au final, le rôle du bastion n’est ni de tout contrôler ni de remplacer la gestion des identités existante. Il sert surtout de garde-fou sur la partie la plus sensible : les comptes techniques, les comptes d’administration, et toutes les opérations que l’on ne veut plus voir passer en direct entre un poste nomade et un serveur clé.
Fonctionnement d’un bastion PAM : du coffre-fort d’identifiants à la surveillance des sessions
Une fois le rôle posé, il faut descendre dans la mécanique. La plupart des solutions PAM modernes s’appuient sur quelques briques bien identifiables. D’abord un coffre-fort de secrets qui stocke les mots de passe des comptes à privilèges et les clés SSH. Ensuite un moteur de contrôle d’accès qui décide qui a le droit d’utiliser tel compte sur telle cible. Viennent ensuite les connecteurs de session (RDP, SSH, parfois VNC ou HTTP) qui jouent le rôle de proxy. Enfin, un module de surveillance des accès et de journalisation vient enregistrer ce qui se passe pendant la session.
Sur MétalNord, l’équipe IT a commencé par mettre dans le coffre-fort les comptes de domaine « Administrateur », les comptes de service d’applications et quelques comptes locaux très sensibles sur les serveurs OT. Les mots de passe ont été changés pour être longs et stockés uniquement dans le bastion. Concrètement, l’admin ne connaît plus le mot de passe, il déclenche une session RDP via le bastion qui se charge lui-même de remplir le champ d’identifiant sur le serveur cible. D’un point de vue sécurité informatique, cela réduit le risque de fuite de mot de passe dans un mail, un fichier ou une conversation rapide sur un chantier.
Le moteur d’autorisations décide ensuite qu’un admin système peut ouvrir une session sur n’importe quel contrôleur de domaine, mais seulement depuis le bastion et uniquement après une authentification forte, par exemple un couple mot de passe + application mobile ou clé hardware. Pour un prestataire, on ajoute parfois un flux de validation : l’astreinte interne reçoit une notification, approuve la demande, et le bastion ouvre la session pour un créneau donné. Une fois la fenêtre passée, l’accès retombe.
La surveillance des accès fait souvent débat. Faut-il tout enregistrer en vidéo, stocker des téraoctets de sessions RDP, ou se limiter à des logs textuels et quelques marqueurs ? Dans les faits, un équilibre raisonnable consiste à capturer les commandes SSH, consigner les métadonnées (source, cible, durée, type de session) et n’activer l’enregistrement vidéo que pour certains systèmes critiques ou pour des périodes d’audit. Stocker tous les écrans de toutes les sessions finit par coûter cher et décourage l’analyse. Mieux vaut un volume raisonnable de données exploitables qu’un océan de captures jamais relues.
Sur le plan opérationnel, un point ressort souvent : l’ergonomie. Un bastion qui complique la vie des équipes sera contourné. Certains admins garderont alors des chemins parallèles « pour aller plus vite ». Pour éviter cela, il est souvent utile de brancher le bastion sur les outils déjà utilisés : client RDP favori, terminaux SSH, voire portails web de prise de poste à distance. Un connecteur qui permet d’ouvrir une session en un clic depuis un annuaire de serveurs bien classé évite beaucoup de résistances.
Pour terminer sur le fonctionnement, il faut parler de la rotation des secrets. Un bon bastion PAM ne se contente pas de stocker les mots de passe, il les change périodiquement. Rotations hebdomadaires, mensuelles ou à l’usage, selon le risque et la sensibilité. Cette rotation enlève un pouvoir silencieux à beaucoup d’acteurs : garder un mot de passe admin « au cas où ». Une fois la rotation activée, le bastion devient le seul détenteur de la valeur, ce qui renforce fortement la protection des privilèges.
Accès sécurisé et authentification forte : articuler bastion, IAM et MFA sans casser le SI
Un Bastion cybersécurité seul, sans lien avec la gestion des identités, ressemble vite à une île. Pour qu’il apporte de la valeur, il doit travailler avec l’annuaire d’entreprise (Active Directory, LDAP, ou un IdP moderne type OIDC), les groupes de sécurité et les politiques d’authentification forte. Autrement dit, le bastion doit déléguer autant que possible la connaissance des utilisateurs à l’IAM, et se concentrer sur le contrôle et la protection des privilèges.
Sur MétalNord, la direction IT a d’abord nettoyé quelques groupes Active Directory qui servaient à tout et n’importe quoi. Les admins à privilèges ont été regroupés dans un nombre limité de groupes, avec une séparation claire entre administrateurs systèmes, administrateurs applicatifs et opérateurs d’astreinte OT. Le bastion s’appuie ensuite sur ces groupes pour décider qui peut lancer quels types de sessions. Une personne qui quitte l’entreprise est désactivée dans l’IAM, et perd mécaniquement ses accès au bastion.
L’authentification forte est souvent le point de friction. Entre les tokens physiques, les applications mobiles et les contraintes de réseau (zones blanches, ateliers isolés), il faut éviter les usines à gaz. Un compromis fréquent consiste à imposer un second facteur pour toute connexion au bastion, mais à ne pas multiplier les étapes ensuite. Une fois la session ouverte sur le bastion, celui-ci gère les connexions vers les ressources internes en utilisant des comptes techniques stockés dans son coffre-fort. L’utilisateur ne repasse pas à chaque bond par un MFA, ce qui resterait impraticable.
Sur les environnements OT mal connectés, certains choisissent une approche plus simple : le bastion est accessible depuis une salle de supervision protégée physiquement, avec des postes dédiés. Le second facteur reste présent, mais l’acheminement réseau jusqu’aux automates se fait sur un réseau interne maîtrisé. Cette configuration tient mieux le choc que des scénarios trop ambitieux où le moindre technicien extérieur doit jongler avec des applications de confirmation sur un smartphone sans réseau dans un sous-sol.
Une articulation efficace entre bastion et IAM suppose aussi de documenter une matrice d’accès sécurisé. Qui doit accéder à quoi, à quel moment, pour quelle raison, et avec quel niveau de journalisation. Ce travail paraît bureaucratique, mais il évite des situations absurdes où un stagiaire se retrouve, par héritage de groupe, avec un accès admin sur un hyperviseur de production. Le bastion ne corrigera pas tout seul une matrice d’autorisations bancale.
Au-delà de l’IAM, certains relient aussi le bastion à leur SIEM ou à une brique de centralisation de logs. L’idée est simple : les événements clés du bastion (échecs de connexion, ouverture de session à privilèges, accès en dehors des horaires habituels) déclenchent des alertes corrélées avec d’autres signaux. Là encore, rien n’oblige à viser des scénarios hollywoodiens. Quelques règles de détection bien choisies suffisent pour attraper les tentatives d’escalade les plus grossières.
Tableau de comparaison IAM + bastion, selon la taille de l’organisation
Pour aider à se repérer, le tableau ci-dessous synthétise quelques combinaisons typiques entre IAM et bastion selon le profil de l’organisation.
| Type d’organisation | IAM principal | Usage du bastion | Niveau d’authentification forte |
|---|---|---|---|
| PME industrielle 200 personnes | Active Directory on-premise | Accès RDP/SSH admin, prestataires, quelques comptes OT locaux | MFA pour admins et prestataires uniquement |
| Groupe multi-sites + cloud | AD + IdP OIDC (Azure AD, Keycloak…) | Portail central pour tous les comptes à privilèges IT/OT | MFA obligatoire, contextuel (horaire, IP, géoloc) |
| Site de production isolé | Annuaire local limité | Bastion dédié aux accès de maintenance OT | MFA partiel, complété par des contrôles physiques |
Ce genre de grille évite de plaquer la même recette partout. La bonne combinaison entre IAM, bastion et MFA dépend autant de la culture de l’entreprise que de la cartographie technique. Mais dans tous les cas, le bastion reste le point de passage logique pour encadrer les accès à privilèges.
Panorama des solutions PAM open source pour bâtir un bastion cybersécurité pragmatique
Lorsque MétalNord a étudié le marché, la question budgétaire est vite arrivée sur la table. Un éditeur de PAM complet facture souvent par compte, par cible ou par volume de sessions, ce qui peut représenter une somme conséquente pour une PME. D’où l’intérêt croissant pour les solutions PAM open source, qui offrent une base solide à condition de les assembler et de les maintenir correctement. Cette approche demande un peu plus de travail initial, mais donne aussi davantage de maîtrise sur les choix techniques.
Parmi les briques open source souvent citées, on trouve des coffres-forts de secrets comme HashiCorp Vault ou AKeyless (en version communautaire ou équivalente), des bastions SSH comme Teleport ou OpenSSH avec jump hosts, des proxys RDP, et des outils de gestion de sessions à privilèges développés par des communautés ou des éditeurs qui publient un noyau libre et des modules payants. Le paysage bouge vite, il vaut donc mieux regarder les dernières versions et la santé des communautés plutôt que des comparaisons datées.
Une approche pragmatique consiste à assembler trois blocs : un coffre-fort de secrets pour stocker et faire tourner les mots de passe, un composant de proxy SSH/RDP pour jouer le rôle de Bastion cybersécurité, et une couche d’authentification forte connectée à l’IAM. Par exemple, Vault peut gérer les secrets et les rotations, Teleport ou un proxy SSH avancé peut assurer les sauts de connexion, et Keycloak peut piloter les identités et le MFA. Ce montage reste volontairement minimaliste, mais il couvre déjà l’essentiel pour des admins Linux et Windows.
Le piège classique des projets open source tient au périmètre. Certains partent avec l’idée de reproduire toutes les fonctions d’un gros produit PAM du marché, mais avec uniquement des briques libres. Après un an de bricolage, le projet est en retard, les mises à jour de sécurité s’accumulent, et personne ne sait vraiment comment tout cela tient. Une autre option, souvent plus raisonnable, est d’accepter une certaine sobriété fonctionnelle : se concentrer sur la protection des privilèges les plus sensibles, laisser de côté des fonctions avancées peu utiles au quotidien, mais tenir un socle robuste.
Sur MétalNord, la mise en place a commencé par un pilote sur quelques serveurs non critiques. L’équipe a testé le mécanisme de rotation des mots de passe, la remontée de logs vers la solution de supervision existante et le comportement des admins en astreinte. Des scripts ont été écrits pour ajouter automatiquement de nouveaux serveurs dans le bastion lors de leur mise en service. Au bout de quelques semaines, la solution s’est étendue aux environnements de préproduction, puis à une partie de la production. Cette montée en charge progressive a limité les frictions et les retours en arrière.
Un autre avantage des solutions open source réside dans leur transparence. Quand un comportement étonne, les équipes peuvent lire la documentation, regarder le code, ouvrir un ticket ou adapter un module. Cette liberté a un revers : elle suppose des compétences internes ou un partenaire capable de tenir le rôle de guide. Pour une PME, miser sur un intégrateur qui connaît déjà ces briques et les a déployées ailleurs évite de tout découvrir seul, surtout sur des sujets aussi sensibles que le contrôle d’accès et la surveillance des accès.
Les choix open source dans le PAM ne se résument donc pas à une question de coût. Ils touchent aussi au degré de dépendance à un éditeur, à la capacité à auditer le code, et à la possibilité de garder la main sur les évolutions. Ce sont des critères souvent sous-jacents, mais qui pèsent lourd lorsque l’on parle de brique centrale de sécurité informatique.
Checklist opérationnelle pour sélectionner une solution PAM open source
Pour structurer la sélection, une courte liste de vérifications fait gagner du temps.
- Présence d’une communauté active, avec des commits récents et une documentation tenue à jour.
- Support clair des protocoles nécessaires (RDP, SSH, HTTP interne, éventuellement VNC) pour vos cas d’usage.
- Intégration documentée avec votre type d’annuaire IAM et vos mécanismes de MFA.
- Mécanismes de rotation des secrets adaptables à vos contraintes de production.
- Possibilité d’exporter les logs vers votre SIEM ou votre solution de centralisation existante.
Cette checklist n’est pas exhaustive, mais elle suffit souvent à filtrer les solutions prometteuses des projets trop expérimentaux pour un usage en production.
Bonnes pratiques, pièges fréquents et mise en œuvre progressive d’un bastion PAM
Dès que l’on parle de bastion et de solutions PAM, un réflexe fréquent consiste à lancer un gros projet transverse, avec des comités, des diagrammes complexes et un objectif de « tout couvrir ». Les retours de terrain montrent qu’une approche plus découpée fonctionne mieux. Le fil conducteur peut être simple : commencer par un périmètre restreint mais à haute valeur, apprendre, automatiser, puis étendre.
Pour MétalNord, les premières semaines ont été consacrées à un inventaire de comptes à privilèges. Exercice parfois ingrat, mais riche en découvertes : comptes génériques utilisés par plusieurs équipes, anciens comptes de projets jamais supprimés, accès de prestataires qui n’interviennent plus depuis longtemps. Cet inventaire a servi de base pour choisir les dix premiers comptes à basculer derrière le bastion. Plutôt que de viser l’exhaustivité, l’équipe a sélectionné les comptes qui, s’ils étaient compromis, offriraient le plus de levier à un attaquant.
Parmi les pièges récurrents, l’un des plus coûteux reste le bastion non testé en situation de crise. Tout semble fonctionner en mode nominal, mais le jour où un contrôleur de domaine tombe, l’équipe découvre que l’accès au bastion dépendait lui-même de ce contrôleur, ou qu’aucune procédure de secours n’avait été prévue pour un accès en mode dégradé. Tester des scénarios d’incident, même simples, permet de révéler ces chaînes de dépendances avant qu’elles ne se retournent contre l’équipe.
Autre écueil : la sur-collecte d’informations. La surveillance des accès finit alors par produire des gigaoctets de logs sans hiérarchie, où il devient très difficile de repérer un comportement anormal. Une politique raisonnable consiste à définir quelques marqueurs forts (usage d’un compte à privilèges en dehors des horaires, accès depuis un pays inattendu, tentatives de rebond non autorisé) et à les remonter dans un tableau de bord dédié. Les sessions normales restent enregistrées mais moins mises en avant, ce qui laisse de l’espace mental pour ce qui cloche vraiment.
Du côté des bonnes pratiques, la formation des administrateurs reste décisive. Un Bastion cybersécurité ne doit pas être perçu comme une punition, mais comme un outil qui structure leur travail. Montrer, par exemple, comment le bastion simplifie la prise de contrôle d’un parc de serveurs via des favoris, des étiquettes ou des modèles de session, change souvent le ton des discussions. Des ateliers courts, avec des cas d’usage concrets, valent mieux que des présentations théoriques trop longues.
Pour finir, il faut accepter que la mise en place d’un bastion PAM reste un chantier vivant. Les systèmes évoluent, les applications se déplacent vers le cloud, les pratiques changent. Un bastion figé finit par se transformer en relique, contournée par des tunnels VPN improvisés et des accès directs. Prendre chaque trimestre une heure pour revoir les rapports du bastion, ajuster les règles de contrôle d’accès, retirer les accès obsolètes et ajouter de nouvelles cibles fait partie de la routine saine d’une équipe de sécurité informatique. Le bastion n’est pas une fin en soi, mais un outil qui accompagne ces ajustements successifs.
Quelle est la différence entre un bastion cybersécurité et un simple VPN ?
Un VPN chiffre le trafic entre un poste et un réseau, mais ne contrôle pas ce que l’utilisateur fait une fois connecté. Un Bastion cybersécurité, lui, concentre les accès à privilèges, applique un contrôle d’accès fin sur les comptes sensibles, masque les mots de passe techniques et journalise les sessions. Les deux peuvent coexister : le VPN donne accès au réseau, le bastion encadre les actions à privilèges sur les serveurs et équipements clés.
Une PME a-t-elle vraiment besoin de solutions PAM open source ou éditeur ?
Pour une petite structure, un projet PAM complet n’est pas toujours prioritaire, mais dès qu’il existe plusieurs admins, des prestataires et des systèmes critiques, un minimum de PAM devient utile. Cela peut commencer par un bastion SSH/RDP simple, avec un coffre-fort de mots de passe et une authentification forte, sans forcément adopter une suite éditeur lourde. Les solutions PAM open source offrent un bon point d’entrée pour cadrer les accès à privilèges sans exploser le budget.
Comment choisir les premiers comptes à basculer derrière le bastion ?
Le critère principal est l’impact en cas de compromission. On cible en priorité les comptes de domaine administrateur, les comptes de service des applications critiques, les comptes locaux admin sur les hyperviseurs et quelques comptes OT donnant accès aux systèmes de supervision. Un inventaire rapide, croisé avec l’analyse de risques, permet de sélectionner une dizaine de comptes pour un pilote, avant d’étendre progressivement la couverture.
L’authentification forte est-elle obligatoire pour un bastion PAM ?
Sur un bastion qui donne accès à des ressources à privilèges, une simple authentification par mot de passe constitue un point faible. L’ajout d’un second facteur, via une application mobile, un token physique ou une clé de sécurité, réduit nettement le risque de compromission de comptes administrateurs. Certaines organisations démarrent sans MFA pour faciliter l’adoption, mais l’objectif reste d’y passer rapidement, au moins pour les comptes les plus sensibles et les accès distants.
Peut-on utiliser un bastion pour sécuriser des systèmes industriels anciens ?
Oui, dans de nombreuses usines, le bastion sert justement à encadrer l’accès à des automates et systèmes SCADA qui ne supportent pas nativement les mécanismes modernes de sécurité. Le bastion agit alors comme un point d’entrée unique vers ces équipements, en forçant la centralisation des accès, la traçabilité et parfois des contraintes horaires. Il ne corrige pas toutes les faiblesses des vieux systèmes, mais il évite que n’importe qui puisse s’y connecter directement avec un compte partagé difficile à tracer.