Un bastion opérationnel, mais des accès directs toujours présents
Le bastion est en place. Les serveurs sont intégrés, les comptes privilégiés sont configurés et les connexions fonctionnent correctement.
Les administrateurs peuvent accéder à leurs environnements, les sessions peuvent être tracées et les mécanismes de contrôle prévus sont opérationnels.
Jusque-là, tout va bien.
Sauf qu'en vérifiant les règles de filtrage, on constate que certains serveurs restent accessibles directement depuis les réseaux d'administration.
Il est donc possible d'atteindre les mêmes ressources de deux manières : en passant par le bastion ou en utilisant les accès réseau historiques.
Dans le premier cas, les connexions bénéficient des contrôles configurés sur le bastion. Dans le second, ces contrôles ne s'appliquent pas nécessairement.
Le problème n'est pas que le bastion fonctionne mal. C'est qu'il reste possible de ne pas l'utiliser.
Des exceptions qui ont souvent une explication
Ce type de situation n'est pas forcément lié à une mauvaise configuration.
Avant le déploiement d'un bastion, les administrateurs avaient besoin d'accéder directement aux serveurs. Des règles de pare-feu ont donc été créées pour autoriser ces connexions.
Certaines concernent des équipes internes, d'autres des prestataires ou des besoins d'exploitation particuliers.
Lorsque le bastion arrive, les ressources sont intégrées progressivement. Les comptes sont configurés et les utilisateurs commencent à utiliser les nouveaux accès.
Mais les anciennes règles ne sont pas toujours supprimées immédiatement.
Elles peuvent être conservées pendant la migration, pour éviter de bloquer une intervention ou parce qu'il reste des usages à vérifier.
Et parfois, une fois la migration terminée, personne ne revient dessus.
On se retrouve alors avec un dispositif de contrôle des accès privilégiés opérationnel, mais des exceptions réseau qui permettent toujours de le contourner.
Retour terrain
Security Platform Engineering • Bastion • Accès privilégiés
Intégrer un serveur dans un bastion ne signifie pas que ses anciens accès ont été supprimés. Ce sont deux opérations différentes, qui doivent être prises en compte dans la démarche de sécurisation.
Le filtrage réseau fait aussi partie du dispositif
On a tendance à se concentrer sur la configuration du bastion : les ressources déclarées, les comptes, les habilitations ou encore l'enregistrement des sessions.
Tout cela est indispensable, mais ne suffit pas.
Un bastion ne peut contrôler que les connexions qui passent effectivement par lui.
Si une règle de pare-feu autorise toujours un administrateur à se connecter directement à un serveur, le bastion n'a aucun moyen d'appliquer ses contrôles à cette session.
Le filtrage réseau doit donc être cohérent avec l'utilisation attendue du bastion.
Pour les accès d'administration concernés, les connexions doivent être autorisées depuis le bastion et les accès directs qui ne sont plus nécessaires doivent être supprimés.
Cela ne signifie pas qu'il faut bloquer tous les flux utilisant des ports d'administration.
Certains outils de supervision, mécanismes automatisés ou traitements techniques peuvent utiliser des protocoles similaires sans relever d'une session d'administration interactive.
Il faut donc identifier précisément les usages avant de modifier les règles.
NOTE TERRAIN
Note terrain : le bastion et le pare-feu ont des rôles complémentaires. Le premier contrôle les accès et les sessions qu'il prend en charge. Le second permet de limiter les chemins réseau autorisés vers les ressources.
La fermeture des accès directs se prépare
Sur le principe, supprimer une ancienne règle de filtrage n'a rien de compliqué.
Mais en production, il vaut mieux éviter de supprimer une autorisation sans avoir vérifié ce qui en dépend.
La première étape consiste à s'assurer que les accès via le bastion sont réellement fonctionnels.
Les comptes doivent être correctement configurés, les utilisateurs doivent disposer des droits nécessaires et les opérations d'administration habituelles doivent pouvoir être réalisées.
Il faut ensuite identifier les équipes concernées et les informer du changement.
Une période de transition permet de vérifier que les nouveaux accès sont utilisés et de traiter les éventuels problèmes avant la suppression des exceptions.
L'analyse des logs de pare-feu peut également aider à identifier les dernières utilisations des règles historiques.
Mais il faut rester prudent : une règle qui ne présente aucun trafic pendant plusieurs jours n'est pas nécessairement inutile.
Certaines connexions sont utilisées uniquement lors de maintenances ponctuelles ou d'interventions exceptionnelles.
L'observation des flux doit donc être complétée par une vérification des besoins auprès des équipes concernées.
Une fois ces éléments validés, les accès directs peuvent être supprimés, avec un retour arrière prévu si nécessaire.
Il faut également prendre en compte les situations où le bastion serait indisponible. Les procédures d'accès de secours doivent être définies et encadrées, sans recréer une exception permanente qui annulerait les contrôles mis en place.
Déployer un contrôle ne suffit pas à le rendre obligatoire
Ce type de situation montre une différence importante entre le déploiement d'une solution de sécurité et son application réelle.
Un bastion peut être correctement installé, configuré et utilisé quotidiennement sans que tous les accès privilégiés concernés soient effectivement maîtrisés.
Tant que les anciens chemins restent disponibles, une partie du dispositif repose encore sur le choix des utilisateurs de passer ou non par le bastion.
C'est pour cette raison que la sécurisation des accès privilégiés ne doit pas se limiter à la configuration de la solution PAM.
Elle nécessite également de revoir les règles réseau existantes, d'identifier les exceptions et de vérifier que les accès autorisés correspondent bien à l'architecture attendue.
Ce travail est parfois moins visible que le déploiement du bastion lui-même, mais il fait partie intégrante de la démarche.
Conclusion
La mise en place d'un bastion constitue une étape importante pour sécuriser les accès privilégiés.
Mais pour que les contrôles soient réellement appliqués, encore faut-il que les connexions d'administration concernées passent effectivement par lui.
Cela implique de vérifier les accès historiques, de préparer leur migration et de supprimer les exceptions réseau devenues inutiles.
L'objectif n'est pas de faire passer tous les flux techniques par le bastion, mais de s'assurer qu'il constitue bien le point de passage imposé pour les accès privilégiés qu'il est censé contrôler.
Un bastion opérationnel, c'est bien. Un bastion qu'on ne peut pas contourner pour les accès concernés, c'est mieux.
POINT D’ATTENTION
Cette note s'appuie sur des situations rencontrées dans des environnements professionnels. Les exemples sont volontairement généralisés afin de ne pas exposer d'informations internes.
LE CARNET DE TERRAIN
Le prolongement naturel des Notes de Terrain.Chaque semaine, recevez une nouvelle publication, les avancées de MM Security Intelligence et une réflexion dans Le Coin de l’Ingénieur.