Extension de l’identité dans les PME : ce que révèlent trois configurations AD-plus-Cloud sur la surface d’attaque réelle

6 min de lecture

La prolifération des identités est la règle, et non l’exception, dans les PME. En comparant trois configurations typiques – Active Directory avec synchronisation Entra ID et SaaS en parallèle, rôles hybrides sur hyperscalers, paysage d’IdP fragmenté avec héritages – on voit rapidement où la documentation et la structure réelle des droits d’accès divergent. Les attaquants voient la même chose, mais plus tôt.

En lienRisque de sécurité Copilot 2026   /  Ransomware 2026 : les entreprises paient

L’hypothèse selon laquelle les identités seraient gérées de manière centralisée résiste rarement à un inventaire rigoureux. Départs de collaborateurs, changements de projet, essais de SaaS, comptes de service pour des intégrations disparues : chacune de ces routines laisse des artefacts dans l’un des systèmes d’identité. La somme de ces artefacts constitue la véritable surface d’attaque – pas l’organigramme.

Trois configurations anonymisées issues d’environnements typiques de PME illustrent ce schéma. Toutes trois représentent des modèles génériques, et non des cas isolés. Si vous reconnaissez des détails dans l’une de ces configurations, il est temps de vérifier vos propres contrôles avant que quelqu’un d’autre ne le fasse. État des lieux : avril 2026.

Setup 1 : Active Directory, synchronisation Entra ID et SaaS non gérés

Le schéma le plus courant dans les PME : un Active Directory local comme système maître, Entra ID (anciennement Azure AD) synchronisé via Entra Connect, et Microsoft 365 comme base de productivité. En parallèle, un paysage SaaS se développe sans que personne n’en ait dressé l’inventaire complet.

Dans la documentation, il est écrit : l’AD est la source. Le offboarding désactive le compte AD, la synchronisation supprime l’utilisateur Entra, et l’accès à Microsoft 365 est coupé. Dans la réalité, 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éalisé il y a trois ans. Le offboarding n’atteint pas ces systèmes.

S’ajoute à cela un détail 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’anciennes intégrations ERP ou de systèmes de monitoring portent souvent des SPN et des mots de passe faibles, datant d’une époque où le domaine était plus restreint. Un utilisateur authentifié du domaine suffit pour demander des tickets de service et les casser hors ligne.

Le déséquilibre dans le Setup 1 réside entre la logique binaire on/off de l’AD et les outils SaaS, qui ne suivent pas cette logique. Renforcer uniquement l’AD, c’est ne sécuriser que la moitié du système.

Un inventaire pragmatique dans un environnement typique de cette taille révèle régulièrement entre huit et vingt outils SaaS non répertoriés 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ègles de mot de passe et n’a aucun lien avec le cycle de vie de l’AD. Lors des changements de personnel, les licences restent actives. Lors des changements d’outils, les anciennes données restent accessibles.

Setup 2 : Active Directory avec rôles hybrides chez les hyperscalers

Les PME plus ambitieuses exécutent en outre des charges de travail dans AWS ou Azure. Les développeurs obtiennent des rôles, les équipes DevOps automatisent les déploiements, et les comptes de service communiquent avec les ressources cloud via des clés d’accès ou des identités managées.

Dans la documentation, il est indiqué : l’accès cloud passe par Entra ID ou une intégration AWS SSO, et les rôles sont définis au plus juste. Dans la réalité, les ingénieurs ont conservé des rôles temporaires, prévus pour un sprint de migration en 2024. Une clé d’accès traîne depuis deux ans dans un script sur un serveur de build. Un rôle inter-comptes a été créé pour un ancien prestataire et n’a jamais été supprimé.

Le point critique réside dans la couche de transition. Lorsqu’un compte AD peut endosser un rôle dans Azure via Entra ID, et que ce rôle donne accès à des KeyVaults ou des comptes de stockage, un chemin se crée, rarement cartographié dans son intégralité. Le Pass-the-Hash ou le vol de jetons sur une machine locale ouvre, dans cette configuration, des possibilités bien au-delà du périmètre AD classique.

S’y ajoute une particularité du monde cloud, souvent négligée dans les audits AD : les permissions sont fréquemment basées sur des rôles, mais liées à des charges de travail qui possèdent elles-mêmes des identités. Une machine virtuelle avec une identité managée, une pipeline avec un jeton OIDC, une fonction avec une identité attribuée par le système – ce ne sont pas des utilisateurs au sens classique, mais elles disposent de droits d’accès. Ne pas inventorier ces identités de charge de travail, c’est ignorer toute une classe de surfaces d’attaque potentielles. Les audits de conformité selon la norme ISO 27001 ou les exigences NIS2 en matière de contrôle d’accès abordent rarement cette couche de manière explicite.

Configuration 3 : Fragmentée, plusieurs IdP, comptes de service obsolètes

Ce troisième schéma se rencontre souvent après des rachats, des réorganisations ou des structures de fabricants évolutives. Un AD local pour l’organisation centrale, un deuxième AD issu d’une filiale rachetée, un IdP séparé pour l’environnement de production, auxquels s’ajoutent Okta ou Google Workspace pour une branche d’activité.

La documentation présente souvent cette situation comme « transitoire ». La réalité, elle, persiste pendant des années. Les relations d’approbation entre les domaines AD ont été configurées une fois et jamais retouchées. 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égiés comme « Domain Admins » contiennent des comptes dont plus personne ne peut reconstituer l’usage initial.

Le principal facteur de risque dans la configuration 3 n’est pas la fragmentation en elle-même, mais l’hypothèse qu’elle serait temporaire. Tant qu’aucun processus de cycle de vie ne réduit les charges historiques, le nombre de comptes de service non attribuables augmente d’année en année.

Ce que les attaquants trouvent systématiquement

Les techniques exploitant ces vulnérabilités sont documentées et stables depuis des années. 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ès au compte krbtgt. Aucune de ces méthodes ne nécessite de failles zero-day, mais simplement un domaine où la discipline de gestion du cycle de vie s’est relâchée au fil des ans.

Un chemin d’attaque typique peut être reconstitué. Il commence de manière discrète et se termine par un accès à des systèmes qui n’étaient jamais dans le périmètre initial.

Ce calendrier est générique, mais réaliste dans son ordre de grandeur. Celui qui ne détecte pas l’étape T+3 ne détectera généralement T+7 que lorsque les données auront déjà fuité.

De manière pragmatique, la situation peut se résumer ainsi : la surface d’attaque dans les environnements PME typiques ne se limite pas à l’AD seul, mais à la somme de l’AD, des identités cloud synchronisées, des SaaS non gérés et des comptes de service historiques. Si vous n’inventoriez pas l’une de ces couches, vous ne durcissez pas l’environnement réel, mais seulement sa documentation.

Concrètement, cela signifie pour le travail opérationnel : un inventaire de toutes les sources d’identité est la condition préalable à toute mesure ultérieure. Trois colonnes par source : compte, dernière connexion, propriétaire. Si vous ne pouvez pas remplir la deuxième colonne, vous ne maîtrisez pas la première. Si vous ne pouvez pas nommer la troisième, vous n’avez pas d’interlocuteur pour un offboarding. C’est dans cette simplicité que réside le plus grand levier – et en même temps le point où la plupart des projets échouent, faute de responsable permanent.

La deuxième couche concerne le durcissement des comptes déjà inventoriés. Comptes de service avec SPN : mots de passe d’une longueur et d’une complexité suffisantes, rotation à intervalles documentés. Groupes privilégiés : revues régulières, modèle d’administration en niveaux lorsque c’est possible. Compte krbtgt : double réinitialisation à un rythme semestriel. Mots de passe des administrateurs locaux : LAPS ou solutions équivalentes. Aucune de ces mesures n’est nouvelle, toutes sont documentées, beaucoup échouent dans leur mise en œuvre au quotidien.

L’ordre est crucial : l’inventaire précède le durcissement. Une mesure de durcissement sur un compte qui ne devrait plus être utilisé est une perte d’énergie. Une mesure de durcissement sur un compte dont personne ne connaît l’existence n’aura même pas lieu. Ces deux cas sont plus fréquents dans les PME que ne le suggère l’hypothèse d’un paysage de comptes propre. Un état des lieux honnête produit généralement plus de connaissances qu’un nouvel outil.

La troisième couche concerne les transitions vers le cloud. Accès conditionnel dans Entra ID, gestion des identités privilégiées pour les rôles temporaires, pas d’accès inter-comptes permanent dans AWS, identités de charge de travail au lieu de clés d’accès à longue durée de vie. Là encore, les concepts sont documentés, mais leur mise en œuvre nécessite une attention soutenue sur plusieurs trimestres.

La conséquence pragmatique n’est pas le grand projet IAM en fin d’exercice. C’est un inventaire simple : quelles identités existent, qui les a créées, qui les a utilisées en dernier, quels droits ont-elles aujourd’hui. Cette liste, tenue honnêtement, détermine l’écart entre l’état cible et l’état réel – et donc la surface d’attaque effective.

Questions fréquentes

Qu’est-ce que l’Identity-Sprawl exactement ?

L’Identity-Sprawl désigne la prolifération incontrôlée des identités d’utilisateurs et de services à travers plusieurs systèmes, sans qu’un processus centralisé de gestion du cycle de vie ne les maintienne de manière cohérente. Les principaux facteurs en sont la multiplication des solutions SaaS, les structures AD historiques et les rôles parallèles des hyperscalers. Ce terme est utilisé aussi bien dans les publications proches du BSI que dans les discussions internationales sur la gestion des identités et des accès (IAM).

En quoi l’Identity-Sprawl se distingue-t-il du Privilege Creep ?

Le Privilege Creep décrit l’accumulation progressive de droits pour un compte donné. L’Identity-Sprawl, lui, se situe à un niveau supérieur : il s’agit de l’augmentation du nombre d’identités et des systèmes dans lesquels elles existent. En pratique, ces deux phénomènes apparaissent souvent conjointement et se renforcent mutuellement.

Pourquoi un AD central ne suffit-il pas ?

Un Active Directory gère ce qui est documenté et connecté. Cependant, les outils SaaS avec authentification locale, les rôles cloud non intégrés à Entra ID et les héritages issus de rachats échappent souvent à ce contrôle. Le paysage réel des autorisations est donc plus vaste que ce qui est visible dans l’AD.

Quel est le levier le plus rapide pour réduire la surface d’attaque ?

Un inventaire rigoureux de tous les comptes de service, suivi d’une rotation des mots de passe et de la suppression des comptes inutilisés. En parallèle : un audit du groupe « Domain Admins » et des groupes disposant de privilèges similaires. Ces deux actions sont réalisables sans investissement dans des outils et ciblent les vecteurs d’attaque les plus courants.

Les attaques Kerberoasting ou Pass-the-Hash sont-elles encore pertinentes aujourd’hui ?

Ces deux techniques sont documentées depuis des années, restent stables et font partie du répertoire standard des tests d’intrusion. Elles ne fonctionnent pas parce qu’elles sont nouvelles, mais parce que les failles sous-jacentes des AD persistent dans de nombreux environnements.

Source de l’image d’en-tête : Pexels / Brett Sayles (px:4716292)

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik