Une revue des accès privilégiés n’est terminée que lorsque les décisions ont été appliquées et vérifiées. Le courriel « accès validés » ne permet pas de comprendre quel droit a été examiné, pourquoi il reste nécessaire ou si le retrait demandé a réellement pris effet. Le dossier doit relier l’identité, le privilège, la ressource, le décideur et le résultat technique.
Cette méthode produit un registre de décision utilisable par une équipe informatique et par un auditeur. Elle s’appuie sur la distinction entre examen, entretien et test présentée dans NIST SP 800-53A. Le registre proposé est un outil interne ; sa périodicité et ses seuils doivent être adaptés au risque. Les références ont été consultées le 27 septembre 2026.
Fixer un périmètre que l’on peut réconcilier
Définissez les environnements concernés : annuaire, plateforme cloud, base de données, sauvegarde, outils de déploiement et applications sensibles. Pour chacun, identifiez la source d’extraction, la date et la personne responsable. Une revue qui couvre seulement l’annuaire peut manquer les comptes locaux, les rôles applicatifs et les secrets donnant un accès équivalent.
Distinguez droits permanents, droits éligibles à une activation et droits temporaires. Une personne sans rôle actif au moment de l’export peut encore être autorisée à l’activer. Un groupe peut hériter d’un autre groupe ou accorder un rôle sur une ressource différente. Conservez ces chemins dans le dossier plutôt que de réduire chaque ligne au nom de l’utilisateur. L’authentification centralisée par SSO facilite une partie de la gestion des identités, mais la revue doit toujours vérifier les autorisations propres aux applications et les accès qui contournent ce point central.
La politique de sécurité du système d’information doit fournir le cadre des responsabilités. Le dossier de revue en apporte la mise en œuvre : population examinée, limites connues et personnes habilitées à décider.
Préparer une ligne par droit attribué ou activable
| Champ | Contenu attendu | Exemple fictif |
|---|---|---|
| Identité stable | Identifiant, type et rattachement | Compte technique de sauvegarde |
| Droit et ressource | Rôle exact, portée et héritage | Lecture des volumes de production |
| Responsable | Personne qui répond de l’usage | Responsable exploitation |
| Justification | Opération nécessitant le privilège | Exécution des sauvegardes nocturnes |
| Éléments consultés | Configuration, usage, demande initiale | Export du rôle et journal des exécutions |
| Évaluateur / décision datée | Identité de l’évaluateur, date et référence de sa décision | Évaluateur E-17, décision REV-042 du 26 septembre 2026 |
| Décision | Maintenir, réduire, supprimer, exception | Réduire la portée aux volumes gérés |
| Exécution | Ticket, opérateur et horodatage | Modification réalisée après validation |
| Vérification | Lecture après changement ou essai | Autre volume devenu inaccessible |
La justification doit décrire une tâche. « Équipe IT » ou « besoin métier » ne suffit pas à expliquer le niveau d’accès. Demandez pourquoi un rôle plus limité ne permet pas la tâche, quelles ressources sont nécessaires et pendant quelle durée. Cette précision transforme une approbation automatique en décision examinable.
Choisir le bon évaluateur
Le supérieur hiérarchique connaît la fonction de la personne, mais pas toujours les implications d’un rôle technique. Combinez sa confirmation du besoin avec l’analyse du propriétaire du système. Pour un droit très sensible, un second regard indépendant peut être nécessaire selon votre organisation. Évitez qu’un détenteur de privilèges soit seul à confirmer tous ses propres accès.
Microsoft décrit les choix de périmètre, d’évaluateurs et d’application des résultats dans sa documentation de déploiement des revues d’accès. Les options réellement disponibles dépendent du contexte de déploiement et des droits du tenant. Vérifiez votre configuration avant de supposer qu’une décision saisie dans un outil provoque automatiquement une suppression.
Prévoyez aussi le cas où le responsable a quitté l’entreprise. La ligne reste ouverte jusqu’à la désignation d’un remplaçant ou à la suppression contrôlée du droit. Le silence n’est pas une justification positive. Documentez la règle d’escalade et le traitement temporaire lorsque l’accès soutient une opération essentielle.
Interpréter l’usage sans conclure trop vite
L’absence d’activité récente est un signal, pas une preuve suffisante d’inutilité. Un compte de secours doit précisément être rarement utilisé. À l’inverse, une activité régulière ne prouve pas que le privilège est légitime : un automatisme peut continuer après la disparition de son besoin initial.
Pour un compte de service, recherchez la tâche, son déclencheur, les ressources atteintes et le propriétaire de l’application. Pour un compte humain, rapprochez les opérations observées des tâches autorisées. La journalisation de sécurité aide à préciser les traces disponibles et leurs limites de conservation.
Lorsque les journaux ne couvrent que trente jours, indiquez-le. Ne présentez pas cette fenêtre comme une preuve d’absence d’usage sur un an. Si une tâche annuelle est invoquée, demandez une documentation ou une preuve de l’exécution précédente. La décision peut être de conserver un accès activable sur demande plutôt qu’un privilège permanent.
Exemple : fermer un accès après une migration
Une entreprise fictive migre son outil de support. L’ancien intégrateur conserve un compte administrateur dans l’annuaire et un secret applicatif utilisé par une synchronisation. La première extraction ne montre que le compte humain ; l’examen des intégrations révèle le second accès.
Le responsable du support confirme que la migration est terminée. L’équipe technique vérifie que la synchronisation n’alimente plus aucune application. La décision demande la suppression du rôle, l’invalidation du secret et la fermeture du chemin de maintenance. Les opérations sont planifiées avec un retour arrière documenté au cas où une dépendance non identifiée apparaîtrait.
Après exécution, un nouvel export confirme l’absence du rôle et de l’autorisation applicative. Un essai contrôlé confirme que l’ancien chemin ne permet plus d’accéder au service. Le dossier conserve les références de ces vérifications. Le simple changement de mot de passe aurait laissé une partie du problème intacte.
Encadrer les exceptions et les comptes de secours
Une exception doit nommer le risque accepté, le service concerné, la raison, les mesures compensatoires, le décideur et la date de réexamen. Une date d’expiration n’a d’effet que si quelqu’un surveille ou automatise son application. Testez le mécanisme sur un cas sans conséquence avant d’en faire une garantie opérationnelle.
Pour les comptes de secours, examinez le stockage des moyens d’accès, les conditions d’utilisation, les alertes, les essais et la remise en état après usage. La politique de mots de passe traite une partie des mécanismes d’authentification ; elle ne remplace pas la décision sur la portée des privilèges.
Ne supprimez pas massivement des accès sur la seule base d’un export ambigu. Vérifiez les dépendances et préparez la continuité. Si une réduction immédiate est impossible, enregistrez une mesure provisoire réellement applicable, par exemple une fenêtre d’accès accompagnée, et le travail nécessaire pour sortir de cette situation.
Prouver les retraits et les réductions
Séparez trois états : décision prise, changement réalisé, effet confirmé. Le ticket fermé par l’opérateur atteste une action déclarée. La lecture de la configuration après changement, complétée si nécessaire par un essai, établit le résultat sur la ressource concernée. Une suppression peut être incomplète si un autre groupe rend le même droit accessible.
Conservez l’identifiant du droit initial dans la preuve finale pour permettre le rapprochement. Masquez les secrets et limitez l’accès au dossier, qui peut révéler des chemins d’administration sensibles. Les mesures de sécurité de l’article 32 doivent être appréciées selon le contexte ; le dossier ne doit pas devenir un nouvel inventaire de secrets librement accessible.
Réconcilier la population avant d’envoyer les décisions
Commencez par comparer les sources d’identité, les rôles et les ressources. Un export de l’annuaire peut donner une liste de personnes, tandis qu’une plateforme cloud énumère des attributions à des groupes, des applications et des identités techniques. Le dossier doit expliquer comment ces listes se rejoignent. Conservez les identifiants stables, les dates d’extraction et les règles de correspondance ; un nom affiché ne suffit pas lorsqu’une personne possède plusieurs comptes.
Vérifiez les écarts de population avant d’envoyer cent lignes à valider. Un rôle sans titulaire apparent peut être attribué par un groupe imbriqué. Un utilisateur absent du système RH peut être un prestataire, un ancien salarié ou un compte de test. La bonne question n’est pas seulement « ce droit est-il nécessaire ? », mais aussi « savons-nous qui peut réellement l’utiliser ? ». Si la réponse reste incertaine, la ligne doit être placée dans une file d’investigation avec un responsable et une mesure provisoire adaptée.
Documentez la couverture des accès activables. La documentation Microsoft sur les rôles éligibles et actifs explique cette distinction dans Entra PIM. Un rôle éligible ne figure pas nécessairement parmi les sessions actives au moment de l’extraction ; il peut pourtant devenir utilisable après activation. Dans un autre environnement, vérifiez le mécanisme équivalent au lieu de supposer que les mêmes catégories existent.
Traiter les décisions ambiguës et les désaccords
Une campagne produit souvent des réponses telles que « probablement utile » ou « à confirmer avec l’équipe projet ». Ne les traduisez pas en validation. Demandez quelle opération requiert le privilège, sur quelle ressource et jusqu’à quel événement. Si le besoin est ponctuel, examinez une attribution temporaire ou activable plutôt qu’un droit permanent. Si le propriétaire métier et le propriétaire technique divergent, consignez les deux raisons et confiez l’arbitrage à la personne habilitée.
Séparez le délai de décision du délai de correction. Une décision de supprimer peut être prise aujourd’hui alors qu’une dépendance impose une opération planifiée. La ligne indique alors le risque restant, la mesure temporaire, le responsable de la modification et la date de vérification prévue. « Suppression approuvée » ne signifie pas « accès supprimé ». Cette distinction permet de suivre les expositions réelles après la clôture administrative de la campagne.
Prévoyez le cas d’un évaluateur silencieux. Les réglages de revue d’accès Microsoft prévoient plusieurs traitements possibles en l’absence de réponse, selon la configuration choisie. Une organisation doit décider elle-même de la règle appropriée pour ses ressources et vérifier ce qui est effectivement configuré. Pour un accès de secours, une suppression automatique non préparée peut nuire à la continuité ; pour un ancien prestataire, un maintien tacite peut prolonger l’exposition. Le dossier conserve la décision et son motif.
Vérifier les chemins d’accès résiduels
Après une suppression, partez de la ressource et demandez si l’identité peut encore accomplir l’opération sensible. Un groupe différent, une attribution directe, une clé applicative ou un compte local peut laisser le même résultat possible. Vérifiez les chemins pertinents et notez ceux qui n’ont pas pu être testés. La preuve d’une commande de suppression ne couvre que l’objet modifié.
La documentation Microsoft sur l’application des résultats signale notamment les limites liées aux groupes synchronisés, imbriqués ou dynamiques. L’outil peut enregistrer une décision sans retirer certains accès hérités. Ce point justifie une lecture après changement et, pour les droits les plus sensibles, un essai contrôlé. Il ne signifie pas qu’un même test technique convient à tous les systèmes.
Conservez enfin un inventaire des voies alternatives confiées à d’autres équipes : privilèges de base de données, accès fournisseur, compte de secours et autorisations applicatives. Le dossier principal n’a pas besoin de contenir tous les secrets ni toutes les pièces. Il doit posséder une référence, un propriétaire et un état de vérification pour chaque voie pertinente. Une exception ouverte reste visible lors de la prochaine campagne jusqu’à sa résolution ou à sa réacceptation motivée.
Piloter la prochaine revue
Mesurez les droits sans propriétaire, les décisions en retard, les réductions non vérifiées et les exceptions arrivant à échéance. Un pourcentage de questionnaires remplis est moins instructif que le nombre de privilèges inutiles encore actifs. Distinguez les retards de décision des blocages techniques pour affecter les bons moyens.
Après la campagne, mettez à jour l’inventaire et corrigez le processus d’arrivée, de changement de poste et de départ. Si les mêmes comptes orphelins reviennent, une nouvelle revue ne résout pas la cause. Documentez le raccordement manquant entre le système RH, l’annuaire et le propriétaire applicatif.
Le dossier final comprend le périmètre, les extractions datées, les décisions motivées, les exceptions et les preuves de résultat. Il permet à un autre opérateur de reprendre le suivi sans connaître les échanges informels de la campagne. Cette continuité constitue le principal critère d’utilité du registre.