Votre environnement d'identités a probablement plus de comptes que vous ne le pensez, et moins de surveillance que vous ne le voudriez
Voici un scénario qui se produit plus souvent que la plupart des équipes TI ne sont à l'aise de l'admettre. Un employé quitte l'organisation. Son compte Active Directory est désactivé. Mais les comptes locaux qu'il avait sur trois systèmes internes, l'identifiant fournisseur partagé qu'il utilisait pour l'accès à distance, et le compte applicatif lié à son courriel ? Eux, ils restent actifs. Discrètement. Pendant des mois, parfois des années.
Ce n'est pas de la négligence. C'est le résultat prévisible d'une gestion des identités système par système, application par application, sans vue centralisée de ce qui existe et de qui a accès à quoi. Et selon les recommandations de la NSA et de la CISA, c'est l'une des lacunes les plus exploitables dans la GIA d'entreprise aujourd'hui.
Le vrai problème des comptes locaux à grande échelle
Les comptes locaux semblent gérables quand on a une poignée de systèmes. À grande échelle, ils deviennent autre chose. Chaque plateforme avec sa propre base d'utilisateurs, ses propres politiques de mots de passe et ses propres règles de session ajoute une couche de complexité qu'aucune équipe ne peut raisonnablement surveiller dans son ensemble.
La NSA et la CISA sont directes là-dessus : les volumes massifs de comptes locaux à travers les systèmes d'entreprise ne peuvent tout simplement pas être maintenus à un niveau de sécurité qui correspond au risque qu'ils représentent. Les problèmes s'accumulent rapidement. La surveillance des événements de sécurité devient inefficace parce qu'il n'y a pas de vue unifiée de l'activité d'authentification.
Les comptes partagés rendent l'attribution forensique pratiquement impossible après un incident. Et les attaquants qui obtiennent un point d'appui via un système géré localement peuvent utiliser cet accès pour sonder d'autres systèmes sans générer les alertes inter-systèmes qui signaleraient autrement le comportement.
Ce que la fédération d'identités et le SSO règlent vraiment
La fédération d'identités et le SSO sont souvent présentés comme des améliorations de l'expérience utilisateur. Une seule connexion pour toutes les applications. Moins de friction, moins de mots de passe à retenir. C'est réel, mais ça sous-estime ce que ces technologies font du point de vue de la sécurité.
Quand l'authentification est centralisée via une solution SSO liée à un fournisseur d'identités, les administrateurs obtiennent quelque chose qu'ils n'ont pas dans un environnement de comptes locaux fragmenté : une vue unique et fiable de qui accède à quoi, d'où, et à quel moment.
Les comportements anormaux deviennent visibles parce qu'il existe une base de référence pour comparer. L'application des politiques devient cohérente parce qu'elle se fait à un seul endroit, et non à travers des dizaines de systèmes configurés indépendamment.
La fédération permet aussi une amélioration opérationnelle essentielle dans la gestion du cycle de vie des accès. Quand un employé quitte l'organisation, désactiver l'identité centralisée désactive l'accès partout. Plus de listes de systèmes à mettre à jour manuellement, plus de comptes locaux oubliés encore ouverts.
Le SSO crée également la bonne base pour un déploiement d'AMF plus robuste. Intégrer l'AMF au niveau de la couche d'authentification centralisée signifie qu'on sécurise un seul système et qu'on couvre toutes les applications qu'il connecte, plutôt que de tenter de configurer et maintenir l'AMF dans chaque application indépendamment.
La surface d'attaque se réduit. La surveillance devient plus efficace. Et l'expérience utilisateur reste gérable.
Où la plupart des organisations ont encore des lacunes
Le point de départ honnête est une question d'inventaire. La plupart des équipes TI ont une image raisonnable de leur répertoire principal et de leurs applications cloud majeures. Ce qui tend à être moins clair, c'est la longue traîne : les systèmes hérités avec des comptes administrateurs locaux, les plateformes gérées par des fournisseurs avec des identifiants partagés, les applications qui précèdent l'architecture GIA actuelle et qui n'ont jamais été intégrées à la fédération.
Ce sont ces comptes qui n'apparaissent pas dans les rapports standard et qui ne génèrent pas d'alertes quand ils sont utilisés en dehors des heures normales ou depuis des emplacements inattendus. Ce sont exactement les types de comptes que les acteurs malveillants ciblent parce qu'ils existent en dehors de la visibilité centralisée.
La voie de remédiation n'est pas compliquée en principe. Elle commence par un inventaire complet des comptes locaux sur tous les systèmes. À partir de là, la question est directe : lesquels peuvent être éliminés en étendant le SSO à la plateforme ? Lesquels nécessitent un compte local pour des raisons opérationnelles et ont donc besoin de politiques de mots de passe explicites et d'une surveillance dédiée ? Et lesquels sont simplement des comptes hérités qui auraient dû être révoqués depuis longtemps ?
L'argument opérationnel, pas seulement l'argument sécurité
Il y a un argument de ressources qui mérite d'être présenté en parallèle de l'argument sécurité. Gérer plusieurs infrastructures d'identités à travers une organisation coûte cher. Chaque système avec sa propre logique d'authentification représente du travail de configuration continu, de la gestion de correctifs et une charge pour le service d'assistance.
L'authentification centralisée via la fédération et le SSO réduit considérablement ces coûts et facilite le maintien des standards de sécurité dans le temps, sans augmenter proportionnellement l'équipe nécessaire pour le gérer.
C'est en partie pourquoi la NSA et la CISA positionnent la fédération d'identités non pas comme une capacité avancée, mais comme une capacité fondamentale. Les organisations qui fonctionnent encore principalement avec des comptes locaux ne sont pas en mesure de gérer efficacement les risques d'identité qui existent dans les environnements hybrides et multi-cloud modernes.
Vous pensez à revoir votre environnement GIA ?
Si vous voulez faire le point sur où vous en êtes et ce qui aurait le plus d'impact, c'est exactement le genre de conversation qu'on a avec les équipes TI tous les jours.
Une prochaine étape concrète
Si votre organisation n'a pas fait un inventaire complet de ses comptes locaux récemment, c'est le bon point de départ. Non pas parce que le résultat sera nécessairement alarmant, mais parce qu'on ne peut pas prendre de bonnes décisions sur la stratégie de fédération et de SSO sans savoir avec quoi on travaille réellement.
Ensuite, évaluer quelles applications dans votre environnement prennent déjà en charge la fédération SSO et lesquelles ne le font pas est la deuxième étape. La plupart des plateformes modernes le supportent. Les lacunes se trouvent généralement dans les systèmes hérités et les applications gérées par des fournisseurs. Savoir où se trouvent ces lacunes, c'est ce qui rend possible une feuille de route de remédiation réaliste.
Sources :
-
Identity and Access Management Recommended Best Practices for Administrators
