Le problème apparaît lorsqu’un responsable quitte une filiale, un prestataire termine sa mission et une équipe change d’outil. Leurs comptes ne se connectent plus, mais des groupes, jetons et accès d’urgence subsistent. Six mois plus tard, un export sensible est encore autorisé par un rôle sans propriétaire ; le support perd des heures à distinguer dépendance légitime et privilège oublié.
Le vrai enjeu est de relier chaque accès à une identité actuelle, une justification, un périmètre, une échéance et une personne capable de le retirer. Désactiver les comptes « anciens » en bloc peut casser un batch critique ; ne rien faire transforme les mobilités ordinaires en accumulation silencieuse de privilèges.
Contre-intuitivement, la dernière connexion n’est pas une preuve suffisante. Un compte de secours légitime peut rester inutilisé pendant des mois. Un jeton technique peut agir chaque nuit sans session interactive. Un utilisateur actif peut conserver un droit hérité qu’il n’emploie plus. L’inactivité est un signal à interpréter, pas un verdict universel.
Dans une application web métier sur mesure, la gestion des accès appartient au workflow produit. Elle doit survivre aux arrivées, changements de poste, absences, départs et incidents, avec un repli qui protège les opérations sans réintroduire un compte partagé.
Distinguer inactivité, orphelin et dérive
Nommer trois problèmes différents
Un compte inactif ne présente plus l’activité attendue sur une fenêtre définie. Un droit orphelin n’a plus de propriétaire, de justification ou de rattachement fiable. Une dérive d’accès apparaît quand les privilèges s’accumulent ou cessent de correspondre au rôle réel. Les trois peuvent coexister, mais leurs corrections diffèrent.
Le diagnostic sépare identité, compte, authentifiant, rôle, permission et ressource. Une personne peut posséder plusieurs comptes ; un compte peut recevoir des droits directs et hérités ; un groupe peut ouvrir plusieurs applications. Tant que le modèle confond ces niveaux, une revue produit une liste sans expliquer l’accès effectif.
Calculer l’accès réellement obtenu
L’inventaire combine annuaire, groupes, politiques, délégations locales, jetons d’API et règles applicatives. Il montre la permission finale avec sa provenance. Un rôle retiré dans l’IAM ne ferme rien si une ACL locale ou une clé persistante maintient le même chemin.
Choisir une source de vérité pour les identités
Le système RH ou le registre prestataire peut signaler arrivée, affectation, manager, fin prévue et départ. Il ne connaît pas toujours le besoin métier détaillé. L’IAM traduit ces événements en identités et groupes. L’application conserve les exceptions qui exigent une décision locale. Chaque frontière possède une donnée autoritative et une fréquence de synchronisation.
Le contrat traite les retards et contradictions. Si la date de fin change dans le registre mais pas dans l’annuaire, quel système bloque l’accès ? Si une identité disparaît avant la transmission des dossiers, comment préserver la continuité ? Un état « à confirmer » vaut mieux qu’une fusion silencieuse de deux vérités.
Les identifiants restent stables et non réattribués. Réutiliser une adresse ou un matricule technique peut faire hériter un nouvel arrivant d’un historique et de permissions qui appartenaient à une autre personne. La désactivation conserve la traçabilité sans recycler l’identité.
Séparer comptes humains, techniques et secours
Un compte humain porte une personne, une authentification et une responsabilité. Un compte de service représente un workload. Un compte de secours couvre une panne d’identité selon une procédure spéciale. Un compte partagé masque ces distinctions et rend attribution, départ et révocation difficiles.
Chaque type reçoit ses propres signaux. Pour l’humain : dernière authentification, activité métier, statut et rôle. Pour le service : propriétaire, workload, dernier usage d’un secret et dépendances. Pour le secours : test périodique, scellé, approbation et trace d’ouverture. Une même règle de « quatre-vingt-dix jours » n’aurait pas le même sens partout.
Traiter les comptes locaux résiduels
La fédération ne fait pas disparaître les comptes locaux créés avant la migration. L’équipe les inventorie, désactive ceux qui ne servent plus et garde un chemin de secours explicitement contrôlé. Une authentification locale cachée derrière une URL d’administration peut survivre à tous les départs gérés dans l’annuaire.
Fermer le cycle arrivée, mobilité et départ
À l’arrivée, le rôle de base est dérivé d’une affectation vérifiée et non copié depuis « une personne similaire ». Les droits supplémentaires citent ressource, motif, approbateur et date de revue. Une recette confirme les refus aussi bien que les succès. Le manager n’approuve que ce qu’il comprend.
La mobilité est souvent plus risquée que le départ. Le nouveau rôle est ajouté immédiatement, tandis que l’ancien reste « au cas où ». Le workflow calcule l’écart avant/après, propose les retraits et garde une courte transition uniquement si un dossier l’exige. L’exception a une date de fin et une preuve de transmission.
Au départ, sessions, jetons, délégations, clés, appareils et accès tiers sont révoqués selon la criticité. La propriété des objets est transférée sans transférer les droits personnels. Un export de dossiers n’exige pas de réactiver l’identité quittée ; il passe par une fonction d’administration tracée et limitée.
Qualifier l’inactivité sans seuil universel
La fenêtre d’inactivité dépend de l’usage. Un opérateur quotidien et un contrôleur trimestriel ne produisent pas le même silence. Le projet combine calendrier, fréquence attendue, dernier événement utile et statut de la personne. Il exclut les absences connues sans laisser leurs droits hors gouvernance.
Un seuil pilote peut placer en revue un compte quotidien après une période supérieure à plusieurs cycles de travail, puis le suspendre après validation. Ce chiffre vient des volumes et contraintes locales. Une réglementation, une politique groupe ou un contrat peut imposer une règle différente ; elle est documentée comme telle.
Préférer une transition observable
Le statut évolue de signalé à confirmé, suspendu, puis supprimé ou archivé selon la politique. La suspension bloque l’usage mais conserve le rattachement et permet une restauration maîtrisée. La suppression immédiate peut détruire l’historique ou attribuer des dossiers à une identité fantôme.
Retrouver les droits sans propriétaire
Un droit devient suspect quand son bénéficiaire, son approbateur, sa ressource ou sa justification n’est plus résolu. L’inventaire recherche aussi les groupes sans owner, politiques jamais utilisées, délégations arrivées à échéance et permissions directes qui contournent le modèle de rôles.
La priorité combine sensibilité, capacité d’action et exposition. Un droit d’export global sans owner passe avant un accès de lecture à une archive interne. L’absence d’usage renforce l’hypothèse, mais un privilège destructif rarement utilisé reste critique. Le retrait est testé sur les workflows qu’il pourrait casser.
La fiche OWASP sur l’autorisation recommande notamment le moindre privilège, le refus par défaut, la validation sur chaque requête et des tests d’autorisation. Ces règles empêchent qu’un nettoyage d’annuaire masque une permission encore accordée par le code.
Appliquer le moindre privilège dans le temps
Le moindre privilège ne consiste pas à créer cent rôles incompréhensibles. Le modèle part des tâches, ressources et contraintes : filiale, portefeuille, état du dossier ou séparation d’approbation. Il refuse une action côté serveur même si l’interface cache déjà le bouton.
Les privilèges temporaires utilisent une élévation avec durée, motif et approbation proportionnés. À l’échéance, le retrait est automatique et l’action reste attribuée à la personne. Un rôle « admin temporaire » permanent parce qu’aucun processus ne le retire est un privilège durable mal nommé.
Tester les relations, pas seulement les rôles
Une autorisation métier dépend souvent d’une relation : gérer son site, valider hors de son propre dossier ou consulter seulement une région. Les tests couvrent changement d’objet, autre tenant, état interdit et combinaison de rôles. Ils évitent le faux positif « l’utilisateur a le rôle, donc tout est permis ».
Gouverner les comptes de service
Chaque identité technique possède un workload, un environnement, un owner humain et une méthode de rotation. Son nom indique la fonction plutôt qu’une personne partie depuis longtemps. Les clés statiques sont remplacées par des identités courtes ou gérées quand la plateforme le permet.
Un compte technique sans connexion interactive n’est pas évalué par la dernière session humaine. L’équipe observe appels, jobs, files et secrets utilisés. Avant retrait, elle coupe ou limite sur une fenêtre représentative, surveille les erreurs et garde un repli. Un compte silencieux peut être le secours d’une clôture annuelle.
Les permissions sont réduites au protocole et aux ressources nécessaires. Un worker de lecture ne reçoit pas l’administration de la base. Un pipeline de déploiement ne détient pas une clé de déchiffrement métier. La séparation limite l’effet d’une compromission sans prétendre la rendre impossible.
Transformer la revue d’accès en décision
Une campagne utile présente au relecteur le bénéficiaire, l’accès effectif, sa provenance, la dernière activité pertinente, la ressource, la sensibilité et les changements depuis la revue précédente. Une liste de codes de groupes sans contexte pousse à tout valider pour finir.
Les décisions sont conserver, réduire, suspendre, transférer ou investiguer. « Conserver » exige un motif pour les droits sensibles. Les réponses en masse sont bornées et une séparation de tâches s’applique aux privilèges élevés. L’absence de réponse n’est jamais interprétée comme une approbation implicite.
Le NIST SP 800-53 Rev. 5, contrôle AC-2 décrit une gestion du cycle de vie des comptes, incluant création, activation, modification, désactivation et revue. Il ne fournit pas un seuil magique adapté à chaque produit ; l’organisation traduit le contrôle en responsabilités et délais justifiés.
Détecter la dérive sans surveiller les personnes
Les métriques portent sur le système : comptes sans owner, droits directs, exceptions expirées, délai entre départ et révocation, échecs de synchronisation et campagnes en retard. Elles ne deviennent pas un classement individuel d’activité. Un faible usage peut être légitime ; une permission excessive reste un risque même sans action.
Les événements sensibles relient identité, ressource, décision d’autorisation, version de politique et résultat. Les logs évitent les documents et données non nécessaires. Une alerte sur un export inhabituel ouvre une qualification ; elle ne prouve ni malveillance ni violation.
Surveiller la chaîne de retrait
Le tableau suit l’événement source, son arrivée dans l’IAM, la révocation dans l’application et l’invalidation des sessions. Une tuile verte sur l’annuaire ne suffit pas si le jeton local reste valable. Les retards et erreurs sont visibles par système et cohorte.
Préparer suspension et restauration sûres
Une suspension de masse reçoit un seuil d’arrêt, un dry-run et un lot pilote. Les dossiers en cours sont recensés avant l’action. Si un flux critique échoue, le repli restaure seulement les comptes légitimes depuis une décision tracée ; il ne réactive pas toute la cohorte.
Le mode secours couvre panne de fédération et erreur de politique. Il utilise une identité dédiée, une durée courte, une approbation et une alerte. Après usage, les actions sont rapprochées et les secrets tournés si nécessaire. Le secours ne devient pas le chemin quotidien des utilisateurs bloqués.
La récupération d’un compte humain vérifie l’identité et la situation actuelle. Elle ne restitue pas automatiquement les anciens privilèges. Le manager et l’owner de ressource revalident ce qui manque, tandis que le support explique le statut sans pouvoir s’auto-accorder un accès.
Cas concret : un prestataire après sa mission
Cas hypothétique. Une consultante termine une mission d’intégration. Son compte fédéré est fermé, mais un compte local de recette et une clé d’API de production portent encore son ancien nom. Sur la cohorte pilote de 37 identités, 4 droits directs et 2 secrets sans owner sont signalés. Ces chiffres illustrent le test local, pas un taux de référence. La clé appartient en réalité à un batch de synchronisation et sa révocation immédiate arrêterait les commandes.
L’équipe rattache le workload à une identité technique, limite ses permissions, installe une nouvelle clé et fait accepter les deux versions pendant une courte migration. Elle désactive ensuite l’ancienne et surveille erreurs et files. Le compte local, sans usage ni dépendance, est suspendu puis supprimé selon la politique.
La revue trouve aussi un rôle d’export accordé directement à la consultante. Aucun job ne l’utilise. La suspension est testée sur une copie, puis l’accès disparaît. Le rapport distingue donc trois décisions : fermer l’identité humaine, migrer le compte technique et retirer le privilège orphelin.
Une personne non auteure rejoue la procédure avec un faux départ. Elle constate que l’alerte se déclenche lorsque la fin prévue est dépassée et que le batch survit à la rotation. Le succès n’est pas « zéro compte ancien », mais chaque capacité conservée reliée à un owner et un usage.
Pour qui et dans quels cas appliquer cette méthode
Les RH ou achats attestent la relation et ses dates ; le manager décrit le rôle ; l’owner de ressource approuve les privilèges ; l’IAM applique le cycle ; l’application impose l’autorisation ; la sécurité contrôle les politiques et les signaux. Ces responsabilités restent explicites même si une petite organisation les concentre.
Le support suspend ou aide selon un runbook, mais n’accorde pas un droit sensible sur simple demande. L’équipe produit explique les tâches et exceptions. L’audit reçoit les preuves sans exiger des captures manuelles de chaque écran. Les utilisateurs disposent d’un canal pour signaler un droit inutile ou manquant.
Pour un accès réglementé ou une séparation de tâches, la décision implique les responsables compétents. Une matrice technique ne remplace pas le droit applicable ni une analyse de risque. Le système conserve le niveau de confiance et les inconnues.
Éviter les erreurs fréquentes d’IAM
- Supprimer sur la seule dernière connexion : un job rare ou un compte de secours casse sans que le privilège réel soit compris.
- Copier les droits d’un collègue : les exceptions et dettes de l’ancien profil deviennent la base du nouveau.
- Masquer le bouton sans contrôler l’API : une requête directe contourne la protection visuelle.
- Valider une campagne en masse : le relecteur ne voit ni ressource ni provenance et reconduit tout.
- Oublier sessions et jetons : le compte est marqué fermé mais un accès déjà émis continue.
- Réutiliser les identifiants : un nouvel arrivant hérite de l’historique ou d’une ACL attachée à l’ancienne personne.
Un autre piège consiste à mesurer le nombre de retraits comme un objectif. Une vague de désactivations peut être spectaculaire et dangereuse. La qualité se voit dans le délai de fermeture, la baisse des orphelins, l’absence de rupture non prévue et l’autonomie du run.
Arbitrer retrait, réduction et exception
Si le bénéficiaire ou l’owner n’existe plus et qu’aucune dépendance n’apparaît, la suspension est prioritaire. Si un workload légitime utilise le compte, l’identité est migrée avant retrait. Si la mission continue mais le périmètre a changé, le droit est réduit. Une exception temporaire garde date, justification et signal de sortie.
La criticité fixe l’ordre et la prudence, pas une durée universelle. Un droit d’administration orphelin peut être suspendu immédiatement avec un repli contrôlé. Un compte de lecture utilisé pour une clôture demande une fenêtre métier et un test. La décision documente risque d’attendre et risque de casser.
Si une identité humaine a quitté l’organisation et qu’aucun owner ne justifie l’accès, alors la suspension bornée prime. En revanche, si les traces montrent un traitement technique encore actif, il faut migrer la capacité avant de révoquer le secret. Dans ce cas, maintenir le compte personnel n’est pas le repli : l’équipe crée une identité de service propriétaire et datée.
Si l’usage est rare mais prévu par un calendrier, le silence ne suffit pas à retirer. Plutôt que reconduire le privilège pour un an, l’équipe peut accorder une élévation à la demande et mesurer le besoin. Le pilote retient comme seuils locaux zéro administrateur sans owner, 100 % des départs critiques rapprochés et aucune rupture sur trois cycles du batch choisi.
Ordonner retrait et vérification
D’abord, calculer l’accès effectif et son propriétaire. Ensuite, simuler le retrait sur un lot. Puis, suspendre ou migrer avec monitoring. Enfin, confirmer côté métier, fermer sessions et dette, puis réviser le signal qui aurait dû prévenir l’orphelin.
- D’abord, nommer l’owner et refuser le privilège sensible qui reste sans justification.
- Ensuite, tester la suspension et documenter les dépendances encore actives.
- Puis, migrer le workload légitime ou réduire le droit humain au périmètre utile.
- Enfin, valider sessions fermées, reprise métier et date de revue avant d’élargir.
Fermer le contrat de gestion des accès
Les entrées sont identités, affectations, ressources, rôles et événements de cycle de vie. Les sorties sont accès effectifs, décisions datées, révocations et exceptions. Les dépendances incluent RH, annuaire, fédération, application, secrets et fournisseurs. Chaque synchronisation expose délai, erreur et dernière exécution.
Les tests couvrent autorisation positive et négative, changement de tenant, mobilité, départ, jeton ancien, compte technique et secours. La recette coupe l’IdP, retarde un événement et révoque une clé. Elle vérifie que l’accès est refusé au bon endroit et que les opérations autorisées restent possibles.
Le rollback restaure une configuration versionnée, pas un export complet de droits devenu obsolète. Les opérations de masse produisent un aperçu, un seuil d’arrêt et une cohorte. Une personne non auteure doit expliquer pourquoi chaque compte test reste ouvert ou fermé.
L’implémentation commence par un rapport en lecture seule qui calcule provenance et owner. Le workflow ajoute ensuite les décisions, puis la suspension sur un petit lot. Chaque commande porte un identifiant, une version de politique et un résultat idempotent. Le déploiement sépare calcul, notification et révocation afin de pouvoir couper une étape sans annuler les précédentes.
Plan d’action sur six semaines
Semaines 1 et 2 : cartographier l’accès effectif
L’équipe choisit deux applications sensibles, exporte identités, comptes, groupes, droits directs, jetons et owners. Elle rapproche dix départs et dix mobilités récents. Les divergences sont classées : retard de source, compte local, permission héritée, compte technique ou exception sans date.
Semaines 3 et 4 : fermer un parcours
Le pilote relie événements d’arrivée, mobilité et départ à l’IAM puis à l’application. Les comptes humains et techniques sont séparés. Un dry-run propose les retraits ; owners et managers répondent avec contexte. Les politiques négatives et l’invalidation des sessions sont testées.
Semaines 5 et 6 : exercer et gouverner
Une cohorte limitée est suspendue. L’équipe surveille erreurs, appels support et workflows. Elle migre les dépendances légitimes, traite les orphelins et joue une panne de fédération. Une autre équipe utilise le secours, puis ferme son accès et rapproche les actions.
La revue finale mesure délai de révocation, droits sans owner, exceptions expirées et ruptures imprévues. Les seuils sont calibrés sur les cycles locaux. L’extension attend que le flux pilote fournisse une décision explicable sans tableur parallèle.
Chaque semaine ferme une preuve : source de vérité, modèle de compte, matrice de tâches, scénario négatif, résultat du dry-run et journal de reprise. Les responsables relisent dix décisions tirées au sort et vérifient que le contexte suffit. Une approbation qui dépend du nom historique du groupe est renvoyée en clarification.
À la sixième semaine, une équipe non auteure traite un départ simulé, un transfert de filiale et un compte technique mal nommé. Elle doit maintenir le batch, fermer les sessions humaines et expliquer les accès restants. Si elle réactive toute la cohorte ou appelle l’auteur, le plan corrige modèle et runbook avant extension.
- À valider : owner, justification, échéance et provenance de chaque accès sensible conservé.
- À bloquer : administrateur orphelin, session encore active après départ ou secours non exercé.
- À revoir : exceptions expirées, comptes locaux et workloads toujours attachés à une personne.
Relier droits, support et workflow
Le diagnostic technique applicatif aide à retrouver les comptes locaux, jetons et permissions hors annuaire. Le guide d’observabilité des workflows métier relie une révocation au résultat réellement refusé ou maintenu.
Le test des exceptions métier sert à rejouer mobilité, secours et dépendance technique avant une campagne. Le maillage reste au service d’une question : qui peut faire quoi maintenant, et comment le prouver sans exposer les données ?
Conclusion : rendre chaque accès explicable
Les comptes inactifs ne se traitent pas avec une purge aveugle. L’équipe doit distinguer humains, services et secours, calculer les droits effectifs, puis relier chaque capacité à une relation, un owner et une échéance. L’activité confirme un usage ; elle ne remplace pas la justification.
Le contrôle gagne en qualité lorsque mobilité, départ et secours produisent des décisions différentes mais comparables. Un droit direct sans justification devient visible, une exception expire réellement et le relecteur comprend l’objet protégé. Les métriques décrivent le système ; elles ne transforment pas le silence d’une personne en faute.
Le progrès décisif est une chaîne exercée : un départ ferme identité, sessions et délégations, tandis qu’un batch légitime migre sans interruption. Dawap peut concevoir ce cycle dans une mission de développement web métier sur mesure, avec un accompagnement expert jusqu’à la revue, au repli et à la preuve de révocation.
