Bastions d’administration : comparer pour sécuriser les accès techniques
Les comptes à privilèges sont la cible prioritaire des attaquants, et le point faible de beaucoup d'organisations. Quatre façons de les protéger par un bastion d'administration, comparées sur les mêmes critères, et ce qui départage vraiment.
Le compte « admin » partagé, dont le mot de passe circule dans un tableur ou un message, reste l’une des failles les plus répandues et les plus exploitées. Les attaquants le savent : une fois un poste compromis, ils cherchent d’abord les comptes à privilèges, ceux qui ouvrent les serveurs, les annuaires et les sauvegardes. Les bastions d’administration répondent à ce risque en imposant un point de passage unique, contrôlé et tracé, pour tous les accès techniques. Encore faut-il choisir le bon, et surtout s’en servir pour de bon.
Ce qu’un bastion doit faire
Un bastion, que les éditeurs rangent souvent dans la catégorie de la gestion des accès à privilèges, s’interpose entre les administrateurs et les systèmes qu’ils administrent. Il remplit cinq fonctions : authentifier fortement l’administrateur, vérifier qu’il a le droit d’accéder à la cible demandée, ouvrir la session sans lui révéler le mot de passe du compte technique, tracer et parfois enregistrer ce qu’il fait, et conserver ces traces hors de sa portée.
L’ANSSI a publié des recommandations relatives à l’administration sécurisée des systèmes d’information, qui situent le bastion dans un ensemble plus large : postes d’administration dédiés, réseau d’administration séparé, comptes distincts pour l’administration et la bureautique. Un bastion posé sur une architecture où l’administrateur lit ses courriels et navigue sur internet depuis le même poste protège beaucoup moins qu’on ne le croit.
Quatre familles de solutions
Les suites commerciales de gestion des accès à privilèges. Proposées par des éditeurs établis, américains, israéliens ou européens (CyberArk, BeyondTrust, Delinea ou le français WALLIX, entre autres), elles couvrent l’ensemble des fonctions : bastion de sessions, coffre de mots de passe avec rotation automatique, gestion des secrets applicatifs, accès juste à temps, analyse des comportements. Elles se déploient dans l’infrastructure de l’organisation ou sous forme de service.
Les passerelles et bastions open source. Apache Guacamole, projet de la fondation Apache, offre une passerelle d’accès distant sans client, depuis un navigateur, avec enregistrement des sessions. JumpServer se présente comme un bastion open source complet. Ces outils couvrent bien le cœur du besoin, l’accès contrôlé et tracé, mais demandent davantage d’intégration pour les fonctions de coffre et de rotation.
Les services d’accès des fournisseurs de cloud. Les grands fournisseurs proposent des services gérés qui ouvrent des sessions d’administration vers leurs machines virtuelles sans les exposer à internet, avec journalisation. Simples à activer, ils sont limités à l’environnement du fournisseur.
L’approche sans bastion central. Certaines organisations reposent sur des postes d’administration durcis, un réseau d’administration isolé et des droits attribués juste à temps par l’annuaire, sans passerelle de sessions. L’approche est cohérente avec les recommandations de l’ANSSI, mais elle trace moins finement ce qui se passe pendant la session.
Le comparatif, critère par critère
Les appréciations ci-dessous décrivent des tendances par famille ; chaque produit doit être vérifié sur sa version courante.
| Critère | Suite commerciale | Open source | Service cloud | Sans bastion central |
|---|---|---|---|---|
| Protocoles couverts | Très larges : SSH, RDP, web, bases de données, applications métiers | SSH, RDP et VNC solides ; le reste variable selon l’outil | Principalement SSH et RDP vers les machines du fournisseur | Tous, puisque l’accès est direct depuis le poste dédié |
| Enregistrement des sessions | Natif, avec recherche et relecture | Disponible, outillage de relecture plus simple | Journalisation, enregistrement selon le service | Limité aux journaux des cibles |
| Coffre et rotation des secrets | Natifs, y compris secrets applicatifs | Partiels, souvent à compléter par un coffre dédié | Via les services de secrets du fournisseur | À organiser séparément |
| Accès juste à temps et approbation | Natifs | Variables | Via la gestion des identités du fournisseur | Via l’annuaire, avec outillage complémentaire |
| Déploiement | Sur site ou en service | Sur site | Service géré uniquement | Sur site |
| Maîtrise et souveraineté | Selon l’éditeur et le mode de déploiement | Forte, code ouvert et hébergement interne | Liée au fournisseur et à sa juridiction | Forte |
| Compétences requises | Moyennes, appui de l’éditeur ou d’un intégrateur | Élevées : intégration, maintien en conditions de sécurité | Faibles pour l’activation | Élevées : architecture et discipline |
| Modèle de coût | Licences par utilisateur, cible ou module | Pas de licence ; support et temps interne | Facturation à l’usage ou à l’heure | Postes dédiés et temps interne |
Forces et limites, entre les deux familles les plus comparées
Dans la plupart des consultations, le choix se resserre entre une suite commerciale et une solution open source.
- Périmètre fonctionnel complet, y compris secrets applicatifs
- Support, feuille de route et intégrations prêtes
- Certaines versions disposent de certifications de sécurité nationales
- Pas de coût de licence, maîtrise du code et de l’hébergement
- Charge d’intégration et de maintenance interne plus lourde
- Fonctions de coffre et de rotation souvent à compléter
Les certifications méritent une vérification attentive. Plusieurs bastions disposent de certifications délivrées par l’ANSSI ou par des autorités équivalentes, mais elles portent sur une version et un périmètre précis : la question à poser n’est pas « le produit est-il certifié ? », mais « la version que vous me livrez, configurée comme vous le proposez, est-elle couverte ? ».
Ce qui départage vraiment
Au-delà du tableau, quatre questions font souvent la décision.
Qui sont vos administrateurs ? Si une part importante des accès est le fait de prestataires (infogérance, maintenance applicative, éditeurs), l’enregistrement des sessions, l’approbation préalable et la révocation rapide deviennent prioritaires. C’est souvent là que se trouve le risque le plus élevé.
Où sont vos systèmes ? Une organisation entièrement hébergée chez un fournisseur de cloud peut se satisfaire de ses services natifs, au moins dans un premier temps. Dès qu’il existe des serveurs internes, des équipements réseau ou plusieurs fournisseurs, une solution transverse s’impose.
Que se passe-t-il quand le bastion tombe ? Un bastion devenu passage obligé est aussi un point unique de défaillance. Il faut le doubler, le sauvegarder, et prévoir une procédure d’accès de secours, avec des comptes sous scellés dont l’usage déclenche une alerte.
Le bastion concentre par ailleurs les accès les plus puissants de l’organisation : il devient une cible de choix. Il doit être durci, mis à jour en priorité, administré lui-même par un cercle très restreint, et surveillé comme un système critique.
Que deviennent les secrets des applications ? Les mots de passe inscrits dans des scripts, des fichiers de configuration ou des tâches planifiées échappent au bastion de sessions. Leur traitement, par un coffre et une rotation, est souvent un second projet, à prévoir dès le départ.
Comment le bastion s’insère-t-il dans la détection ? Les traces d’un bastion n’ont de valeur que si quelqu’un les lit. Leur envoi vers le système de détection de l’organisation, avec des règles simples (connexion hors des horaires habituels, accès à une cible inhabituelle, usage d’un compte de secours), transforme un outil de contrôle en outil de détection. C’est aussi ce qui permet de démontrer, lors d’un audit, que les accès à privilèges sont réellement surveillés.
Les étapes d’un projet réussi
Quel que soit l’outil retenu, les projets qui aboutissent suivent le même ordre. D’abord l’inventaire : comptes à privilèges, comptes partagés, comptes de service, accès des prestataires, avec pour chacun un responsable. Ensuite la définition des droits, cible par cible, en partant du principe du moindre privilège. Puis la migration progressive des usages, en commençant par les prestataires et les systèmes les plus sensibles. Enfin, et seulement alors, la fermeture des accès directs, vérifiée par un contrôle technique et non par une simple consigne. Chaque étape produit un livrable vérifiable, ce qui facilite le pilotage et la preuve de conformité.
Quel choix selon votre situation
Pour une organisation de taille moyenne, avec un parc mixte et des prestataires nombreux, une suite commerciale ou un bastion open source bien intégré par un partenaire compétent répondent tous deux au besoin ; le choix se fait sur les compétences internes disponibles et sur les exigences de souveraineté. Pour une organisation entièrement hébergée dans un seul cloud, les services natifs constituent un premier pas raisonnable, à condition de ne pas en rester là si le parc se diversifie. Pour une entité essentielle au sens de NIS 2, ou un opérateur dont les systèmes industriels sont administrés à distance, la combinaison d’un bastion, de postes d’administration dédiés et d’un réseau d’administration séparé reste la référence.
Dans tous les cas, le projet commence par un inventaire des comptes à privilèges et des accès existants, et se termine par la fermeture des accès directs. Notre expertise cybersécurité et conformité accompagne ce cadrage et la rédaction du cahier des charges, en restant indépendante des éditeurs, comme notre méthode pour conduire un benchmark sans parti pris.
- ANSSI, Recommandations relatives à l’administration sécurisée des systèmes d’information.
- Directive (UE) 2022/2555 du Parlement européen et du Conseil du 14 décembre 2022 (NIS 2), article 21.
- Documentation publique des projets Apache Guacamole et JumpServer, et des services d’accès des principaux fournisseurs de cloud.
Questions fréquentes
Un bastion est-il obligatoire pour être conforme à NIS 2 ?
La directive ne désigne pas d'outil. Elle exige des mesures de gestion des risques, dont la maîtrise des accès, l'authentification à plusieurs facteurs lorsque c'est approprié et la capacité à détecter et analyser les incidents. Pour l'administration des systèmes, un bastion est l'un des moyens les plus courants d'y répondre et d'en apporter la preuve, mais il doit s'inscrire dans une architecture d'administration cohérente.
Peut-on se contenter d'un VPN et d'une authentification forte ?
Un VPN protège le canal, pas l'usage. Il ne dit pas qui a fait quoi sur quel serveur, ne contrôle pas les droits par cible et n'enregistre pas les sessions. Pour les accès à privilèges, notamment ceux des prestataires, il ne remplace pas un bastion ; les deux sont souvent combinés.
Faut-il enregistrer toutes les sessions d'administration ?
L'enregistrement est très utile pour les accès des prestataires et pour les systèmes les plus sensibles. Il pose des questions de durée de conservation, de stockage et d'information des personnes concernées, à traiter avec le délégué à la protection des données. Beaucoup d'organisations enregistrent toutes les sessions sur les cibles critiques et se contentent des journaux ailleurs.
Combien de temps faut-il pour déployer un bastion ?
L'installation technique prend peu de temps. Le travail se trouve ailleurs : inventorier les comptes à privilèges, décider des droits par cible, migrer les usages et fermer les accès directs. Ce dernier point, souvent repoussé, conditionne l'efficacité de l'ensemble.