Une entreprise peut disposer d’un annuaire centralisé, d’une authentification multifacteur, d’une politique de gestion des habilitations et de revues régulières des droits d’accès. Elle peut même avoir déployé une solution de gestion des accès privilégiés (PAM).
Mais sait-elle réellement quelles identités peuvent accéder à son système d’information ?
Derrière les comptes utilisateurs officiellement administrés se trouvent parfois des comptes locaux, des identités applicatives, des comptes de service oubliés, des clés API ou des mécanismes d’authentification hérités d’anciennes architectures. Ces accès continuent de fonctionner sans nécessairement apparaître dans les outils centraux de gouvernance.
Avec la multiplication des services SaaS, des environnements cloud, des automatisations et désormais des agents d’intelligence artificielle, le problème prend une dimension supplémentaire. La question n’est plus seulement de gérer les droits des identités connues. Il faut également découvrir celles qui échappent à cette gouvernance et déterminer ce qu’elles peuvent réellement faire.
L’IAM ne représente pas nécessairement toute la réalité
La gestion des identités et des accès (Identity and Access Management, IAM) permet d’organiser l’authentification, de définir les permissions et d’administrer les droits des utilisateurs et des applications.
Dans un environnement correctement intégré, ces mécanismes peuvent être particulièrement efficaces. Ils permettent notamment de centraliser les identités, d’appliquer des politiques d’accès, de gérer les habilitations et d’organiser leur révision périodique, mais leur visibilité dépend du périmètre effectivement couvert.
Une application qui conserve sa propre base de comptes locaux, un équipement utilisant une authentification indépendante ou un ancien service reposant sur des credentials intégrés peuvent échapper aux processus centralisés. L’entreprise dispose alors de deux représentations différentes de son système d’information : celle des identités administrées et celle des identités réellement utilisées.
Il faut également distinguer les droits attribués des droits exercés.
Un utilisateur peut disposer d’une permission sans jamais l’utiliser. À l’inverse, il peut bénéficier d’un accès indirect par une appartenance à un groupe, une délégation ou une relation de confiance insuffisamment prise en compte dans les revues d’habilitation.
Les solutions IAM modernes peuvent déjà analyser une partie de ces situations. Microsoft Entra, par exemple, propose des fonctions de revue des accès, d’analyse des permissions applicatives et d’exploitation des journaux d’authentification.
Mais ces capacités restent tributaires des ressources intégrées, des informations collectées et des fonctionnalités effectivement déployées. Une gouvernance des identités peut donc être correctement organisée sur son périmètre tout en laissant subsister des accès actifs en dehors de celui-ci.
La matière noire des identités
Cette couche invisible est parfois désignée par l’expression Identity Dark Matter, ou « matière noire des identités ». L’expression, employée notamment par l’éditeur Orchid Security, décrit les identités, credentials et mécanismes d’accès qui fonctionnent dans les applications et les infrastructures sans être connus ou administrés par les dispositifs habituels de gouvernance. L’image est intéressante, car ces identités ne sont pas nécessairement cachées volontairement, elles peuvent simplement résulter de l’histoire du système d’information.
Une application ancienne conserve son propre mécanisme d’authentification. Un projet abandonné laisse derrière lui un compte technique. Une intégration entre deux systèmes utilise toujours un mot de passe créé plusieurs années auparavant.
La migration vers un nouvel annuaire ne signifie pas automatiquement que tous les anciens mécanismes ont disparu. Et lorsqu’une entreprise réalise une revue des habilitations à partir de son référentiel central, ces identités peuvent tout simplement ne pas figurer dans les éléments examinés. Elles n’en continuent pas moins à disposer de droits.
Le problème ne réside donc pas uniquement dans l’existence de comptes oubliés. Il réside dans le fait que l’organisation peut considérer ses accès comme maîtrisés alors que son inventaire ne couvre qu’une partie de la réalité.
Les identités non humaines échappent au cycle de vie traditionnel
La gestion des identités a longtemps été structurée autour d’un processus relativement simple. Un collaborateur arrive dans l’entreprise. Un compte lui est attribué, des droits lui sont accordés, puis modifiés au gré de ses fonctions. Lorsqu’il quitte l’organisation, ses accès doivent être supprimés. Ce fonctionnement repose notamment sur les événements enregistrés par les ressources humaines.
Mais un compte de service ne possède pas de parcours RH, une identité applicative ne démissionne pas, une clé API ne quitte pas l’entreprise à la fin d’un contrat de travail.
Les applications, scripts, conteneurs et services automatisés ont pourtant besoin de s’authentifier auprès d’autres ressources.
Microsoft distingue ainsi les identités humaines des identités de machines, parmi lesquelles figurent les identités de workloads utilisées par les applications, services et traitements automatisés.
Microsoft.
Ces identités peuvent être créées directement par les équipes de développement, les administrateurs cloud, les pipelines CI/CD ou les outils d’orchestration. Il faut toutefois distinguer l’identité elle-même de ses moyens d’authentification : une clé API ou un secret n’est pas nécessairement une identité distincte, mais il peut permettre à un système d’agir sous celle d’une application ou d’un compte technique.
Prenons un exemple :
Un développeur crée une identité pour permettre à un pipeline de déploiement d’accéder à un environnement cloud. Le projet évolue, le pipeline est remplacé. L’identité reste active parce que personne n’a été chargé de sa suppression. Quelques mois plus tard, elle dispose toujours de permissions qui ne correspondent plus à aucun besoin opérationnel.
Ce risque est suffisamment concret pour que Microsoft recommande de documenter systématiquement le propriétaire, la finalité, les permissions, la durée de vie et les modalités de révision de chaque compte de service.
La difficulté n’est donc pas uniquement technique, chaque identité non humaine doit aussi posséder un responsable et un cycle de vie.
Le cloud et le SaaS multiplient les chemins d’accès
La visibilité devient plus complexe lorsque le système d’information repose sur plusieurs fournisseurs et de nombreuses applications SaaS, chaque environnement possède ses propres mécanismes d’autorisation.
AWS combine notamment des politiques attachées aux identités, aux ressources et à différents niveaux de contrôle. Son service IAM Access Analyzer peut analyser les permissions effectives sur certaines ressources, identifier des accès externes ou internes et repérer des permissions inutilisées.
Dans Microsoft Entra ID, les rôles, les groupes, les permissions applicatives et les consentements accordés aux applications déterminent différents niveaux d’accès.
Google Cloud utilise également une hiérarchie de ressources dans laquelle certaines permissions accordées à un niveau supérieur sont héritées par les ressources situées en dessous.
Les applications SaaS ajoutent leurs propres mécanismes : administrateurs locaux, rôles métiers, comptes techniques ou intégrations OAuth.
Chaque système peut donc présenter une vision exacte de son propre périmètre sans fournir une vision globale de l’entreprise.
Une identité peu privilégiée dans un environnement peut disposer d’une autorisation lui permettant d’endosser un autre rôle ou d’accéder à une application bénéficiant de permissions plus importantes. Le risque n’apparaît alors pas nécessairement lors de l’examen isolé du premier compte.
Il apparaît lorsqu’on reconstitue l’ensemble du chemin d’accès, C’est précisément l’intérêt d’une cartographie des relations entre identités, permissions, ressources et mécanismes de délégation.
Elle ne doit pas seulement répondre à la question : « Quel rôle possède ce compte ? »
Elle doit aussi permettre de déterminer : « Jusqu’où ce compte peut-il réellement accéder, directement ou indirectement ? »
Un accès légitime peut masquer une intrusion
Cette problématique rejoint directement celle de la détection. Lorsqu’un attaquant exploite une vulnérabilité pour exécuter un code malveillant, certains événements peuvent révéler une activité inhabituelle.
Mais lorsqu’il utilise un compte valide ou un token dérobé, ses actions peuvent emprunter les mêmes mécanismes d’authentification que celles de l’utilisateur légitime. Les journaux enregistrent alors une identité connue.
Cela ne signifie pas pour autant que son utilisation est autorisée. Il faut donc replacer chaque événement dans son contexte : provenance de la connexion, ressource consultée, privilèges utilisés, comportement habituel et éventuelle succession d’actions inhabituelles.
Une identité peut être parfaitement connue de l’IAM et néanmoins être utilisée frauduleusement. Inversement, un compte absent du référentiel central peut fonctionner normalement depuis plusieurs années sans avoir jamais été intégré aux dispositifs de surveillance.
La visibilité doit donc couvrir trois dimensions distinctes :
- les identités existantes ;
- les permissions dont elles disposent effectivement ;
- les actions qu’elles réalisent.
C’est cette combinaison qui permet de différencier un accès simplement autorisé d’un usage réellement attendu. Elle apporte également au SOC un contexte indispensable pour qualifier les événements.
Les agents IA ajoutent une nouvelle dimension
L’arrivée des agents d’intelligence artificielle rend cette distinction encore plus importante. Contrairement à un script exécutant une succession prédéterminée de commandes, un agent peut sélectionner des outils, prendre certaines décisions intermédiaires et réaliser plusieurs opérations pour accomplir une tâche.
Pour agir, il utilise des permissions : celles d’un utilisateur, d’une application ou d’une identité qui lui est propre, selon son architecture.
Microsoft considère d’ailleurs les agents IA comme une catégorie particulière d’identités de machines et développe des mécanismes de gouvernance prenant notamment en compte leur propriétaire humain et leur cycle de vie.
Le problème dépasse alors la simple attribution des droits. Un utilisateur autorise un agent à préparer un environnement de développement. L’agent décide de consulter un fichier de configuration, d’utiliser une API ou d’accéder à un secret pour effectuer cette opération.
Toutes ces actions peuvent être exécutées avec une identité parfaitement légitime, mais l’utilisateur n’a pas nécessairement demandé explicitement chacune d’elles.
On retrouve ici le problème abordé dans notre précédent article sur les SOC : un agent IA peut adopter un comportement ressemblant à celui d’un attaquant sans être malveillant.
La visibilité des identités devient donc essentielle pour déterminer quelles permissions ont été accordées, sous quelle identité l’agent agit et quelles ressources sont réellement utilisées.
Avec les agents IA, il ne suffit plus de savoir à qui appartient un compte. Il faut également comprendre quels systèmes sont autorisés à agir sous cette identité. La visibilité ne se résume pas à acheter une nouvelle plateforme
Face à ces difficultés, les plateformes de visibilité et d’intelligence des identités proposent de réunir inventaire, analyse des permissions, découverte des comptes non gouvernés et observation des usages.
Elles peuvent compléter l’IAM, l’IGA, le PAM et les outils du SOC, mais il serait réducteur de considérer qu’une nouvelle solution suffit à résoudre le problème. La visibilité dépend d’abord de la capacité à couvrir effectivement les environnements concernés.
Une démarche progressive peut commencer par les ressources les plus sensibles : annuaires, infrastructures cloud, applications critiques, comptes privilégiés et identités techniques disposant de permissions importantes.
Il faut ensuite confronter les inventaires existants à la réalité des applications et des infrastructures. Les comptes découverts doivent être rattachés à un propriétaire, une finalité et un périmètre de permissions. Les accès indirects doivent être examinés et les privilèges inutilisés réévalués.
Enfin, les journaux d’authentification et d’activité permettent de vérifier l’usage observé des permissions, dans la limite de leur couverture et de leur durée de conservation. Cette dernière précision est importante : l’absence d’utilisation dans les journaux ne démontre pas à elle seule qu’un droit est inutile. Un accès de secours ou un compte de reprise d’activité peut être rarement employé tout en restant indispensable.
La gouvernance doit donc confronter les preuves techniques aux besoins métiers, et non automatiser aveuglément la suppression des comptes inactifs. Gouverner les identités commence par les connaître.
Les entreprises ont considérablement renforcé leurs mécanismes d’authentification et de gestion des accès, la généralisation du MFA, le développement du PAM, les revues d’habilitation et les démarches Zero Trust témoignent de cette évolution. Ces dispositifs ne produisent pleinement leurs effets que sur les identités et les ressources qu’ils couvrent. Un compte local oublié, une identité technique sans propriétaire, une permission héritée ou une intégration non répertoriée peuvent maintenir des chemins d’accès en dehors des processus habituels.
Le cloud, le SaaS et l’automatisation ne créent pas entièrement ce problème, ils en augmentent l’étendue et la complexité. Les agents IA y ajoutent une dimension supplémentaire en multipliant les actions réalisées automatiquement au nom d’identités humaines ou applicatives.
La réponse ne consiste donc pas seulement à renforcer l’authentification ou à multiplier les contrôles d’accès. Elle suppose de confronter régulièrement la représentation officielle du système d’information à son fonctionnement réel.
Car une organisation peut posséder des procédures IAM rigoureuses, des outils performants et des comptes correctement administrés tout en laissant subsister une partie de ses accès hors de son champ de vision.
Avant de se demander si les droits sont correctement attribués, encore faut-il connaître toutes les identités auxquelles ils ont été accordés.
