English
Cet article s’appuie sur l'étude rédigée par Alexandre Pujol (Ingénieur système et sécurité Linux), au sein de l'équipe OSSA dirigée par Gaël Lago.
Au sein de LINAGORA se trouve ce que certains appellent notre dernier rempart contre le chaos, le département OSSA pour Open Source Software Assurance. Derrière cette formule se cache une mission bien réelle : servir de support et de maintenance pour tous les logiciels open source.
Une part essentielle de leur travail consiste à aider les organisations à faire les bons choix. Cela passe par un travail continu de veille, d’analyse et de recommandation. C’est dans ce cadre que nous avons mené une étude dédiée aux bastions de sécurité. Pourquoi ce sujet ? Parce que dans des systèmes d’information où les accès se multiplient et où l’identité devient le nouveau périmètre de sécurité, le bastion est et restera une pièce centrale.
1. Le bastion reste un pilier du contrôle des accès et nous vous recommandons de le traiter comme tel
Dans les infrastructures modernes, le bastion agit comme un point de passage contrôlé entre les administrateurs et les systèmes critiques. Toutes les connexions sensibles transitent par lui : accès aux serveurs, aux bases de données ou aux environnements de production.
Ce rôle permet de concentrer à un seul endroit le contrôle et la traçabilité des accès. Chaque session peut être supervisée, enregistrée et analysée. Cette visibilité est essentielle, que ce soit pour comprendre un incident, répondre à une exigence d’audit ou détecter un comportement anormal.
Mais le bastion n’est pas une protection suffisante à lui seul. Il introduit une couche supplémentaire dans l’architecture et doit être correctement intégré et maintenu. Mal configuré, il peut devenir lui-même un point de faiblesse. Il doit donc être considéré comme un composant parmi d’autres, au sein d’une stratégie de sécurité plus globale.
2. Ce que nous vous conseillons d’exiger d’un bastion moderne
Les travaux de veille menés par l’OSSA montrent qu’un bastion n’est jamais isolé. Son efficacité dépend directement de sa capacité à s’intégrer dans l’écosystème existant.
Le premier point concerne l’intégration avec les systèmes d’identité. La compatibilité avec des annuaires LDAP et des mécanismes d’authentification multi-facteurs permet de centraliser la gestion des accès et d’éviter la multiplication de comptes locaux difficiles à maintenir et à auditer. Le bastion devient alors une extension naturelle du système d’identité, et non un silo supplémentaire.
La supervision constitue l’autre fonction essentielle. Un bastion doit permettre de visualiser les sessions en temps réel, d’enregistrer les connexions et d’exporter ces informations vers des outils de supervision ou de SIEM. Cette capacité de journalisation est indispensable pour enquêter sur un incident, répondre à des exigences de conformité ou simplement comprendre ce qui s’est produit sur un système.
L’interopérabilité avec les outils d’infrastructure modernes est également un facteur déterminant. L’intégration avec des outils comme les gestionnaires de secrets ou les outils DevOps permet d’inscrire le bastion dans les pratiques opérationnelles existantes, sans créer de rupture dans les workflows.
Enfin, l’étude met aussi en lumière un point plus contre-intuitif : la limitation des commandes directement sur le bastion. Cette fonctionnalité est souvent perçue comme un élément de sécurité important. Elle vise, en théorie, à éviter une erreur d’un administrateur, empêcher l’exfiltration de données ou bloquer l’exécution de commandes malveillantes.
En pratique, son efficacité reste très limitée. Comme le souligne Alexandre Pujol dans son analyse, ce type de mécanisme repose généralement sur du filtrage de commandes, souvent basé sur des expressions régulières, qui peuvent être facilement contournées. Une commande interdite comme rm -rf data/ peut par exemple être encodée, puis exécutée sous une autre forme : echo cm0gLXJmIGRhdGEvCg== | base64 --decode | sh.
Pour le bastion, la commande originale n’est plus visible, et l’action n’est pas bloquée.
Ces éléments doivent guider le choix d’une solution adaptée à votre contexte et à vos priorités.
3. Les solutions existantes : ce que nous recommandons, et les points de vigilance
La veille menée par l’OSSA met en évidence une réalité claire : à ce jour, aucune solution open source ne répond parfaitement à l’ensemble des exigences identifiées. Cela ne signifie pas qu’il n’existe pas de bonnes options, mais plutôt que chaque choix implique des compromis qu’il est important de comprendre.
Parmi les outils analysés (Teleport, HashiCorp Boundary, Apache Guacamole, OVH The Bastion, JumpServer et Warpgate) Teleport apparaît aujourd’hui comme la solution la plus aboutie sur le plan fonctionnel. Son architecture moderne, son utilisation de certificats pour gérer les accès et son niveau d’intégration avec les infrastructures existantes en font une référence. Il répond à la plupart des besoins opérationnels que rencontrent les organisations.
Mais cette maturité s’accompagne d’une limite importante. Certaines fonctionnalités clés, notamment l’intégration avec LDAP, nécessitent l’utilisation d’une licence entreprise. Ce modèle pose une question qui dépasse le simple aspect technique : celle de la gouvernance et de la maîtrise de l’outil. Peut-on encore parler d’une alternative pleinement open source lorsque des briques essentielles dépendent d’une offre commerciale ?
Face à ce constat, Apache Guacamole constitue l’alternative la plus évidente. Entièrement libre, il permet de construire un bastion sans dépendance à des fonctionnalités propriétaires. Ce choix offre une maîtrise complète de la solution et de son fonctionnement. Néanmoins cette liberté a un coût opérationnel, car Guacamole fournit les briques nécessaires, mais il implique de construire et de maintenir une architecture plus large autour de lui pour répondre à l’ensemble des besoins.
Entre ces deux approches, l’étude met également en lumière l’émergence de nouveaux projets particulièrement prometteurs. Warpgate en fait partie. Le logiciel répond déjà à plusieurs des exigences fonctionnelles identifiées, avec une approche moderne et cohérente avec les pratiques actuelles. Il reste encore immature, mais son positionnement et ses choix techniques en font une solution à suivre de près. À ce stade, notre recommandation est moins de le déployer immédiatement que de surveiller activement son évolution.
Ce constat illustre une réalité plus large de l’open source : les solutions existent, progressent, et continuent de s’améliorer grâce aux usages et aux contributions..
Conclusion : Et parfois, la meilleure recommandation est de contribuer
Le rôle de l’OSSA chez LINAGORA est d’aider les organisations à comprendre l’écosystème open source et à faire des choix éclairés, en s’appuyant sur des analyses concrètes, comme cette veille sur les bastions.
Ces travaux montrent qu’il existe aujourd’hui de bonnes solutions, mais aussi des limites, des compromis, et des projets encore en devenir. Dans ce contexte, la veille n’est qu’une première étape. L’open source fonctionne grâce aux contributions, à celles et ceux qui s’impliquent pour améliorer l’existant ou proposer de nouvelles approches.
C’est dans cette continuité que notre expert sécurité et identité, Xavier Guimard, a initié Open Bastion. Ce projet open source vise à répondre aux enjeux actuels de contrôle des accès, avec une intégration directe dans les systèmes d’identité, notamment LemonLDAP::NG.
Le projet est disponible ici
Si vous souhaitez échanger avec nos équipes sur ces sujets, bénéficier de nos retours d’expérience ou être accompagnés dans vos choix, l’OSSA est à votre disposition.
L'étude complète de Alexandre Pujol sur les bastions est à retrouver ici
