Définition et enjeux
Identity visibility désigne la capacité à voir chaque identité dans un environnement, les ressources auxquelles elle accède et la façon dont cet accès est réellement exploité en temps réel. Le concept combine l’inventaire, la cartographie des droits et la télémétrie comportementale en une image continue, contrairement à un instantané périodique. Selon le texte, les identités volées et réutilisées constituent l’un des vecteurs d’accès initiaux les plus fréquemment cités dans les études de violations, notamment le Verizon Data Breach Investigations Report. Cette prévalence rend la visibilité d’identité un point de départ incontournable pour toute stratégie Zero Trust.
Limites des solutions IAM traditionnelles
Les plateformes IAM classiques ne rapportent que la configuration : appartenances aux groupes, attributions de rôles et catalogues d’autorisations. Cette approche indique ce qui a été accordé, mais ne confirme pas si l’application applique réellement ces droits, si le compte possède encore un propriétaire humain ou s’il a été utilisé récemment. De plus, les outils de gouvernance ne vérifient pas la couverture des applications non intégrées, créant ainsi une illusion de conformité lorsqu’une application n’apparaît tout simplement pas dans le rapport.
Principes d’une visibilité d’identité efficace
Le texte identifie trois piliers : un inventaire précis, une cartographie des relations d’accès et une analyse contextuelle continue. L’inventaire recense tous les acteurs – utilisateurs, comptes de service, clés API – tandis que la cartographie révèle les chemins d’accès effectifs, souvent plus larges que les droits déclarés à cause de groupes imbriqués ou de comptes partagés. L’analyse continue transforme chaque découverte en priorité de risque : un compte dormant avec accès en lecture à un environnement de test est peu critique, alors qu’un credential d’automatisation sans expiration, doté de droits d’écriture en production et sans MFA, représente un risque élevé.
Défis du multicloud
Dans les environnements multicloud, la visibilité se complique parce que chaque fournisseur modélise les identités différemment. AWS utilise des rôles, des politiques basées sur l’identité ou les ressources et l’assomption de rôle inter‑compte. Azure/Entra ID repose sur des principes de répertoire, des affectations RBAC et des autorisations d’application déléguées. Google Cloud se base sur des comptes de service et des liaisons IAM hiérarchisées. Les SaaS ajoutent leurs propres modèles d’administration et leurs comptes locaux. Sans normalisation de ces vocabulaires, les équipes de sécurité doivent analyser chaque plateforme séparément, risquant de manquer les liens entre elles – le « dark matter » de l’identité.
