6 min de lecture<\/p>\n
La prolif\u00e9ration des identit\u00e9s est la r\u00e8gle, et non l’exception, dans les PME. En comparant trois configurations typiques \u2013 Active Directory avec synchronisation Entra ID et SaaS en parall\u00e8le, r\u00f4les hybrides sur hyperscalers, paysage d’IdP fragment\u00e9 avec h\u00e9ritages \u2013 on voit rapidement o\u00f9 la documentation et la structure r\u00e9elle des droits d’acc\u00e8s divergent. Les attaquants voient la m\u00eame chose, mais plus t\u00f4t.<\/strong><\/p>\n L’essentiel en bref<\/p>\n En lien<\/span>Risque de s\u00e9curit\u00e9 Copilot 2026<\/a> \/<\/span> Ransomware 2026 : les entreprises paient<\/a><\/p>\n L’hypoth\u00e8se selon laquelle les identit\u00e9s seraient g\u00e9r\u00e9es de mani\u00e8re centralis\u00e9e r\u00e9siste rarement \u00e0 un inventaire rigoureux. D\u00e9parts de collaborateurs, changements de projet, essais de SaaS, comptes de service pour des int\u00e9grations disparues : chacune de ces routines laisse des artefacts dans l’un des syst\u00e8mes d’identit\u00e9. La somme de ces artefacts constitue la v\u00e9ritable surface d’attaque \u2013 pas l’organigramme.<\/p>\n Trois configurations anonymis\u00e9es issues d’environnements typiques de PME illustrent ce sch\u00e9ma. Toutes trois repr\u00e9sentent des mod\u00e8les g\u00e9n\u00e9riques, et non des cas isol\u00e9s. Si vous reconnaissez des d\u00e9tails dans l’une de ces configurations, il est temps de v\u00e9rifier vos propres contr\u00f4les avant que quelqu’un d’autre ne le fasse. \u00c9tat des lieux : avril 2026.<\/p>\n Qu’est-ce que la prolif\u00e9ration des identit\u00e9s ?<\/p>\n La prolif\u00e9ration des identit\u00e9s d\u00e9crit une situation o\u00f9 les identit\u00e9s des utilisateurs et des services se d\u00e9veloppent sur plusieurs syst\u00e8mes distincts, sans qu’un processus commun de gestion du cycle de vie ne les maintienne de mani\u00e8re coh\u00e9rente. Chacun de ces syst\u00e8mes \u2013 Active Directory, Entra ID, outils SaaS individuels, IAM cloud \u2013 g\u00e8re un sous-ensemble. L’ensemble complet est rarement connu dans son int\u00e9gralit\u00e9.<\/p>\n<\/div>\n Le sch\u00e9ma le plus courant dans les PME : un Active Directory local comme syst\u00e8me ma\u00eetre, Entra ID (anciennement Azure AD) synchronis\u00e9 via Entra Connect, et Microsoft 365 comme base de productivit\u00e9. En parall\u00e8le, un paysage SaaS se d\u00e9veloppe sans que personne n\u2019en ait dress\u00e9 l\u2019inventaire complet.<\/p>\n Dans la documentation, il est \u00e9crit : l\u2019AD est la source. Le offboarding d\u00e9sactive le compte AD, la synchronisation supprime l\u2019utilisateur Entra, et l\u2019acc\u00e8s \u00e0 Microsoft 365 est coup\u00e9. Dans la r\u00e9alit\u00e9, des outils SaaS avec des utilisateurs locaux coexistent, tout comme des outils avec une connexion Google pour le service marketing, ou un CRM avec une authentification par mot de passe depuis un test r\u00e9alis\u00e9 il y a trois ans. Le offboarding n\u2019atteint pas ces syst\u00e8mes.<\/p>\n S\u2019ajoute \u00e0 cela un d\u00e9tail technique bien connu des admins AD : les comptes avec Service Principal Name (SPN) sont des cibles potentielles pour des attaques par Kerberoasting. En pratique, les comptes de service d\u2019anciennes int\u00e9grations ERP ou de syst\u00e8mes de monitoring portent souvent des SPN et des mots de passe faibles, datant d\u2019une \u00e9poque o\u00f9 le domaine \u00e9tait plus restreint. Un utilisateur authentifi\u00e9 du domaine suffit pour demander des tickets de service et les casser hors ligne.<\/p>\n Le d\u00e9s\u00e9quilibre dans le Setup 1 r\u00e9side entre la logique binaire on\/off de l\u2019AD et les outils SaaS, qui ne suivent pas cette logique. Renforcer uniquement l\u2019AD, c\u2019est ne s\u00e9curiser que la moiti\u00e9 du syst\u00e8me.<\/p>\n Un inventaire pragmatique dans un environnement typique de cette taille r\u00e9v\u00e8le r\u00e9guli\u00e8rement entre huit et vingt outils SaaS non r\u00e9pertori\u00e9s dans le portefeuille officiel. Automatisation marketing, suites de design, outils de gestion de projet, solutions de suivi du temps pour certains sites. Chacun dispose de son propre administrateur, de ses propres r\u00e8gles de mot de passe et n\u2019a aucun lien avec le cycle de vie de l\u2019AD. Lors des changements de personnel, les licences restent actives. Lors des changements d\u2019outils, les anciennes donn\u00e9es restent accessibles.<\/p>\n Les PME plus ambitieuses ex\u00e9cutent en outre des charges de travail dans AWS ou Azure. Les d\u00e9veloppeurs obtiennent des r\u00f4les, les \u00e9quipes DevOps automatisent les d\u00e9ploiements, et les comptes de service communiquent avec les ressources cloud via des cl\u00e9s d\u2019acc\u00e8s ou des identit\u00e9s manag\u00e9es.<\/p>\n Dans la documentation, il est indiqu\u00e9 : l\u2019acc\u00e8s cloud passe par Entra ID ou une int\u00e9gration AWS SSO, et les r\u00f4les sont d\u00e9finis au plus juste. Dans la r\u00e9alit\u00e9, les ing\u00e9nieurs ont conserv\u00e9 des r\u00f4les temporaires, pr\u00e9vus pour un sprint de migration en 2024. Une cl\u00e9 d\u2019acc\u00e8s tra\u00eene depuis deux ans dans un script sur un serveur de build. Un r\u00f4le inter-comptes a \u00e9t\u00e9 cr\u00e9\u00e9 pour un ancien prestataire et n\u2019a jamais \u00e9t\u00e9 supprim\u00e9.<\/p>\n Le point critique r\u00e9side dans la couche de transition. Lorsqu\u2019un compte AD peut endosser un r\u00f4le dans Azure via Entra ID, et que ce r\u00f4le donne acc\u00e8s \u00e0 des KeyVaults ou des comptes de stockage, un chemin se cr\u00e9e, rarement cartographi\u00e9 dans son int\u00e9gralit\u00e9. Le Pass-the-Hash ou le vol de jetons sur une machine locale ouvre, dans cette configuration, des possibilit\u00e9s bien au-del\u00e0 du p\u00e9rim\u00e8tre AD classique.<\/p>\n S\u2019y ajoute une particularit\u00e9 du monde cloud, souvent n\u00e9glig\u00e9e dans les audits AD : les permissions sont fr\u00e9quemment bas\u00e9es sur des r\u00f4les, mais li\u00e9es \u00e0 des charges de travail qui poss\u00e8dent elles-m\u00eames des identit\u00e9s. Une machine virtuelle avec une identit\u00e9 manag\u00e9e, une pipeline avec un jeton OIDC, une fonction avec une identit\u00e9 attribu\u00e9e par le syst\u00e8me \u2013 ce ne sont pas des utilisateurs au sens classique, mais elles disposent de droits d\u2019acc\u00e8s. Ne pas inventorier ces identit\u00e9s de charge de travail, c\u2019est ignorer toute une classe de surfaces d\u2019attaque potentielles. Les audits de conformit\u00e9 selon la norme ISO 27001 ou les exigences NIS2 en mati\u00e8re de contr\u00f4le d\u2019acc\u00e8s abordent rarement cette couche de mani\u00e8re explicite.<\/p>\n Ce troisi\u00e8me sch\u00e9ma se rencontre souvent apr\u00e8s des rachats, des r\u00e9organisations ou des structures de fabricants \u00e9volutives. Un AD local pour l\u2019organisation centrale, un deuxi\u00e8me AD issu d\u2019une filiale rachet\u00e9e, un IdP s\u00e9par\u00e9 pour l\u2019environnement de production, auxquels s\u2019ajoutent Okta ou Google Workspace pour une branche d\u2019activit\u00e9.<\/p>\n La documentation pr\u00e9sente souvent cette situation comme \u00ab transitoire \u00bb. La r\u00e9alit\u00e9, elle, persiste pendant des ann\u00e9es. Les relations d\u2019approbation entre les domaines AD ont \u00e9t\u00e9 configur\u00e9es une fois et jamais retouch\u00e9es. Des comptes de service existent dans les deux annuaires, avec des droits qui se chevauchent et souvent des mots de passe identiques. Des groupes privil\u00e9gi\u00e9s comme \u00ab Domain Admins \u00bb contiennent des comptes dont plus personne ne peut reconstituer l\u2019usage initial.<\/p>\n Le principal facteur de risque dans la configuration 3 n\u2019est pas la fragmentation en elle-m\u00eame, mais l\u2019hypoth\u00e8se qu\u2019elle serait temporaire. Tant qu\u2019aucun processus de cycle de vie ne r\u00e9duit les charges historiques, le nombre de comptes de service non attribuables augmente d\u2019ann\u00e9e en ann\u00e9e.<\/p>\n IAM centralis\u00e9 – Avantages<\/p>\n Statu quo fragment\u00e9 – Avantages<\/p>\n IAM centralis\u00e9 – Inconv\u00e9nients<\/p>\n Statu quo fragment\u00e9 – Inconv\u00e9nients<\/p>\n Les techniques exploitant ces vuln\u00e9rabilit\u00e9s sont document\u00e9es et stables depuis des ann\u00e9es. Le Kerberoasting contre les comptes de service aux mots de passe faibles. Le Pass-the-Hash via des identifiants mis en cache localement. Les attaques Golden Ticket lorsqu’un attaquant a eu acc\u00e8s au compte krbtgt. Aucune de ces m\u00e9thodes ne n\u00e9cessite de failles zero-day, mais simplement un domaine o\u00f9 la discipline de gestion du cycle de vie s’est rel\u00e2ch\u00e9e au fil des ans.<\/p>\n Un chemin d’attaque typique peut \u00eatre reconstitu\u00e9. Il commence de mani\u00e8re discr\u00e8te et se termine par un acc\u00e8s \u00e0 des syst\u00e8mes qui n’\u00e9taient jamais dans le p\u00e9rim\u00e8tre initial.<\/p>\n T0 – Acc\u00e8s initial :<\/strong> E-mail de phishing, session compromise sur un ordinateur portable. L’attaquant se trouve dans l’environnement en tant qu’utilisateur normal du domaine.<\/p>\n T+1 jour – \u00c9num\u00e9ration :<\/strong> Inventaire du domaine, des groupes, des Service Principal Names. Des outils comme BloodHound ou des techniques similaires cartographient les chemins vers les comptes privil\u00e9gi\u00e9s.<\/p>\n T+2 jours – Kerberoasting :<\/strong> Demande de tickets de service pour les comptes avec SPN, brute-force hors ligne contre les mots de passe faibles. Plusieurs comptes de service sont compromis.<\/p>\n T+3 jours – Mouvement lat\u00e9ral :<\/strong> Un compte de service compromis a acc\u00e8s \u00e0 un serveur de rebond. Le Pass-the-Hash ou des jetons mis en cache \u00e9tendent la port\u00e9e.<\/p>\n T+5 jours – Transition vers le cloud :<\/strong> Un compte avec des r\u00f4les hybrides permet le saut vers l’environnement cloud. Des cl\u00e9s d’acc\u00e8s dans des scripts ou des r\u00f4les oubli\u00e9s acc\u00e9l\u00e8rent la progression.<\/p>\n T+7 jours – Objectif atteint :<\/strong> Acc\u00e8s aux espaces de stockage de fichiers, bases de donn\u00e9es ou syst\u00e8mes de sauvegarde. L’environnement est enti\u00e8rement cartographi\u00e9 du point de vue de l’attaquant.<\/p>\n<\/div>\n Ce calendrier est g\u00e9n\u00e9rique, mais r\u00e9aliste dans son ordre de grandeur. Celui qui ne d\u00e9tecte pas l’\u00e9tape T+3 ne d\u00e9tectera g\u00e9n\u00e9ralement T+7 que lorsque les donn\u00e9es auront d\u00e9j\u00e0 fuit\u00e9.<\/p>\n De mani\u00e8re pragmatique, la situation peut se r\u00e9sumer ainsi : la surface d’attaque dans les environnements PME typiques ne se limite pas \u00e0 l’AD seul, mais \u00e0 la somme de l’AD, des identit\u00e9s cloud synchronis\u00e9es, des SaaS non g\u00e9r\u00e9s et des comptes de service historiques. Si vous n’inventoriez pas l’une de ces couches, vous ne durcissez pas l’environnement r\u00e9el, mais seulement sa documentation.<\/p>\n Concr\u00e8tement, cela signifie pour le travail op\u00e9rationnel : un inventaire de toutes les sources d’identit\u00e9 est la condition pr\u00e9alable \u00e0 toute mesure ult\u00e9rieure. Trois colonnes par source : compte, derni\u00e8re connexion, propri\u00e9taire. Si vous ne pouvez pas remplir la deuxi\u00e8me colonne, vous ne ma\u00eetrisez pas la premi\u00e8re. Si vous ne pouvez pas nommer la troisi\u00e8me, vous n’avez pas d’interlocuteur pour un offboarding. C’est dans cette simplicit\u00e9 que r\u00e9side le plus grand levier \u2013 et en m\u00eame temps le point o\u00f9 la plupart des projets \u00e9chouent, faute de responsable permanent.<\/p>\n La deuxi\u00e8me couche concerne le durcissement des comptes d\u00e9j\u00e0 inventori\u00e9s. Comptes de service avec SPN : mots de passe d’une longueur et d’une complexit\u00e9 suffisantes, rotation \u00e0 intervalles document\u00e9s. Groupes privil\u00e9gi\u00e9s : revues r\u00e9guli\u00e8res, mod\u00e8le d’administration en niveaux lorsque c’est possible. Compte krbtgt : double r\u00e9initialisation \u00e0 un rythme semestriel. Mots de passe des administrateurs locaux : LAPS ou solutions \u00e9quivalentes. Aucune de ces mesures n’est nouvelle, toutes sont document\u00e9es, beaucoup \u00e9chouent dans leur mise en \u0153uvre au quotidien.<\/p>\n L’ordre est crucial : l’inventaire pr\u00e9c\u00e8de le durcissement. Une mesure de durcissement sur un compte qui ne devrait plus \u00eatre utilis\u00e9 est une perte d’\u00e9nergie. Une mesure de durcissement sur un compte dont personne ne conna\u00eet l’existence n’aura m\u00eame pas lieu. Ces deux cas sont plus fr\u00e9quents dans les PME que ne le sugg\u00e8re l’hypoth\u00e8se d’un paysage de comptes propre. Un \u00e9tat des lieux honn\u00eate produit g\u00e9n\u00e9ralement plus de connaissances qu’un nouvel outil.<\/p>\n La troisi\u00e8me couche concerne les transitions vers le cloud. Acc\u00e8s conditionnel dans Entra ID, gestion des identit\u00e9s privil\u00e9gi\u00e9es pour les r\u00f4les temporaires, pas d’acc\u00e8s inter-comptes permanent dans AWS, identit\u00e9s de charge de travail au lieu de cl\u00e9s d’acc\u00e8s \u00e0 longue dur\u00e9e de vie. L\u00e0 encore, les concepts sont document\u00e9s, mais leur mise en \u0153uvre n\u00e9cessite une attention soutenue sur plusieurs trimestres.<\/p>\n La cons\u00e9quence pragmatique n’est pas le grand projet IAM en fin d’exercice. C’est un inventaire simple : quelles identit\u00e9s existent, qui les a cr\u00e9\u00e9es, qui les a utilis\u00e9es en dernier, quels droits ont-elles aujourd’hui. Cette liste, tenue honn\u00eatement, d\u00e9termine l’\u00e9cart entre l’\u00e9tat cible et l’\u00e9tat r\u00e9el \u2013 et donc la surface d’attaque effective.<\/p>\n L\u2019Identity-Sprawl d\u00e9signe la prolif\u00e9ration incontr\u00f4l\u00e9e des identit\u00e9s d\u2019utilisateurs et de services \u00e0 travers plusieurs syst\u00e8mes, sans qu\u2019un processus centralis\u00e9 de gestion du cycle de vie ne les maintienne de mani\u00e8re coh\u00e9rente. Les principaux facteurs en sont la multiplication des solutions SaaS, les structures AD historiques et les r\u00f4les parall\u00e8les des hyperscalers. Ce terme est utilis\u00e9 aussi bien dans les publications proches du BSI que dans les discussions internationales sur la gestion des identit\u00e9s et des acc\u00e8s (IAM).<\/p>\n Le Privilege Creep d\u00e9crit l\u2019accumulation progressive de droits pour un compte donn\u00e9. L\u2019Identity-Sprawl, lui, se situe \u00e0 un niveau sup\u00e9rieur : il s\u2019agit de l\u2019augmentation du nombre d\u2019identit\u00e9s et des syst\u00e8mes dans lesquels elles existent. En pratique, ces deux ph\u00e9nom\u00e8nes apparaissent souvent conjointement et se renforcent mutuellement.<\/p>\n Un Active Directory g\u00e8re ce qui est document\u00e9 et connect\u00e9. Cependant, les outils SaaS avec authentification locale, les r\u00f4les cloud non int\u00e9gr\u00e9s \u00e0 Entra ID et les h\u00e9ritages issus de rachats \u00e9chappent souvent \u00e0 ce contr\u00f4le. Le paysage r\u00e9el des autorisations est donc plus vaste que ce qui est visible dans l\u2019AD.<\/p>\n Un inventaire rigoureux de tous les comptes de service, suivi d\u2019une rotation des mots de passe et de la suppression des comptes inutilis\u00e9s. En parall\u00e8le : un audit du groupe \u00ab Domain Admins \u00bb et des groupes disposant de privil\u00e8ges similaires. Ces deux actions sont r\u00e9alisables sans investissement dans des outils et ciblent les vecteurs d\u2019attaque les plus courants.<\/p>\n Ces deux techniques sont document\u00e9es depuis des ann\u00e9es, restent stables et font partie du r\u00e9pertoire standard des tests d\u2019intrusion. Elles ne fonctionnent pas parce qu\u2019elles sont nouvelles, mais parce que les failles sous-jacentes des AD persistent dans de nombreux environnements.<\/p>\n Suggestions de lecture<\/p>\n\n
Setup 1 : Active Directory, synchronisation Entra ID et SaaS non g\u00e9r\u00e9s<\/h2>\n
Setup 2 : Active Directory avec r\u00f4les hybrides chez les hyperscalers<\/h2>\n
Configuration 3 : Fragment\u00e9e, plusieurs IdP, comptes de service obsol\u00e8tes<\/h2>\n
IAM centralis\u00e9 vs statu quo fragment\u00e9<\/h3>\n
\n
\n Dimension<\/th>\n IAM centralis\u00e9<\/th>\n Statu quo fragment\u00e9<\/th>\n<\/tr>\n \n D\u00e9sengagement<\/strong><\/td>\n Un processus, cascad\u00e9 dans tous les syst\u00e8mes<\/td>\n Manuel pour chaque syst\u00e8me, incomplet<\/td>\n<\/tr>\n \n Visibilit\u00e9<\/strong><\/td>\n Une console pour toutes les identit\u00e9s<\/td>\n Plusieurs portails d\u2019administration, sans synchronisation<\/td>\n<\/tr>\n \n Audit<\/strong><\/td>\n Journal consolid\u00e9, \u00e9v\u00e9nements comparables<\/td>\n Fragments de journal dans chaque syst\u00e8me<\/td>\n<\/tr>\n \n Effort de configuration<\/strong><\/td>\n \u00c9lev\u00e9, n\u00e9cessite une discipline processuelle et technique<\/td>\n Faible, r\u00e9sulte d\u2019une absence de d\u00e9cision<\/td>\n<\/tr>\n \n Surface d\u2019attaque<\/strong><\/td>\n Clair\u00e9ment d\u00e9limit\u00e9e, durcissable de mani\u00e8re cibl\u00e9e<\/td>\n Peu lisible, charges historiques r\u00e9currentes<\/td>\n<\/tr>\n<\/table>\n<\/div>\n \n
\n
\n
\n
Ce que les attaquants trouvent syst\u00e9matiquement<\/h2>\n
Chemin d’attaque typique dans les environnements d’expansion des identit\u00e9s<\/h3>\n
Questions fr\u00e9quentes<\/h2>\n
Qu\u2019est-ce que l\u2019Identity-Sprawl exactement ?<\/h3>\n
En quoi l\u2019Identity-Sprawl se distingue-t-il du Privilege Creep ?<\/h3>\n
Pourquoi un AD central ne suffit-il pas ?<\/h3>\n
Quel est le levier le plus rapide pour r\u00e9duire la surface d\u2019attaque ?<\/h3>\n
Les attaques Kerberoasting ou Pass-the-Hash sont-elles encore pertinentes aujourd\u2019hui ?<\/h3>\n