Les revues d'accès ont mauvaise réputation, et elle est méritée. Demandez à la plupart des responsables GIA ce qui se passe pendant la certification trimestrielle et vous entendrez une version de la même histoire : une feuille de calcul atterrit dans la boîte de réception d'un gestionnaire, celui-ci parcourt une liste de noms et de droits qu'il ne comprend pas pleinement, et clique sur approuver pour tout, parce que l'alternative est de traquer trente personnes pour leur demander ce qu'un rôle fait réellement. Ce n'est pas une revue d'accès qui détecte la dérive. C'est un rituel de conformité qui produit accessoirement un artefact d'audit.
Le problème est structurel, pas un manque de rigueur. L'accès s'accumule dans une seule direction. Quelqu'un rejoint un projet, est ajouté à un groupe, le projet se termine, et l'appartenance au groupe reste simplement là. Quelqu'un change d'équipe et hérite de nouvelles permissions sans que personne ne revoie les anciennes. Rien de tout cela n'est malveillant, et rien ne paraît anormal au moment où cela se produit. Cela ne devient un problème qu'en s'accumulant, des mois plus tard, quand plus personne ne se souvient pourquoi une personne donnée a accès à un système donné. Une revue qui n'est qu'une liste de vérification « en a-t-il encore besoin? oui/non » comparée à la référence de l'an dernier n'a aucun moyen de révéler ce type d'accumulation, parce que la référence de l'an dernier est justement ce qui a déjà dérivé.
Ce qu'une revue doit réellement vérifier
Une revue qui détecte la dérive doit être construite autour d'une question différente de « est-ce que ça a l'air correct ». Elle doit demander si l'accès correspond encore à un motif d'affaires actuel et articulable — pas s'il correspond à ce qui a été approuvé auparavant, mais s'il serait accordé aujourd'hui s'il était demandé à partir de zéro. Ce recadrage compte parce qu'il déplace le travail du réviseur : d'une comparaison avec l'historique vers une justification par rapport au besoin présent, et ces deux approches produisent des réponses très différentes. Cela signifie aussi que la revue a besoin d'assez de contexte associé à chaque droit pour qu'un gestionnaire puisse réellement raisonner à son sujet : à quoi sert l'accès, qui d'autre le possède, quand il a été utilisé pour la dernière fois. Sans ce contexte, on revient à l'approbation automatique, simplement avec une meilleure présentation.
Les données d'utilisation font ici bien plus de travail que l'historique d'approbation. Un droit que personne n'a exercé depuis des mois est un signal de dérive bien plus fort qu'un droit qui ne correspond pas à une référence antérieure, et c'est un signal qui ne demande pas au réviseur de comprendre les rouages internes du système — il lui suffit de remarquer qu'une chose est dormante et de demander pourquoi elle est encore accordée. Ancrer les revues autour de ce type de signal, plutôt qu'autour d'une comparaison avec une liste antérieure, c'est ce qui transforme l'exercice de paperasse en quelque chose qui trouve réellement les comptes et les groupes ayant discrètement survécu à leur raison d'être.
Rien de tout cela n'est propre aux utilisateurs humains non plus, et le traiter comme si c'était le cas fait partie de la façon dont la dérive s'installe sans être remarquée. Les comptes de service et les intégrations automatisées s'accumulent exactement de la même façon, habituellement avec moins de surveillance, parce que personne ne reçoit de courriel de certification pour un robot. La même question s'applique : cet accès correspond-il encore à un besoin réel et actuel, que ce qui le détient soit une personne, un compte de service, ou de plus en plus un agent d'IA agissant au nom de quelqu'un. Le contrôle d'accès n'a jamais vraiment porté sur la catégorie d'utilisateur — c'est la même discipline peu importe qui, ou ce qui, se trouve de l'autre côté de l'identifiant, et un processus de revue qui ne pense qu'aux personnes ne revoit déjà que la moitié du tableau.