Revue des habilitations : faire décider les métiers

Un responsable de service reçoit un export de comptes et de groupes. Il reconnaît les noms de son équipe, coche la colonne de validation et renvoie le fichier. La campagne est terminée dans le tableau de suivi. Personne n’a pourtant expliqué ce que permet le groupe intitulé FIN_EXPORT_EXT.

Je pars de ce cas de figure pour préparer une revue des habilitations. Demander au métier de signer une liste technique produit une réponse administrative. Ce que je veux obtenir est différent : une décision sur les opérations qu’une personne doit encore pouvoir réaliser, puis la preuve que cette décision a été appliquée.

Choisir un périmètre dont les droits sont compréhensibles

Je commencerais par une application sensible avec un responsable métier disponible : gestion commerciale, paie ou espace documentaire de direction, selon l’entreprise. Le premier périmètre doit permettre d’aller jusqu’aux corrections. Une campagne générale lancée sans capacité de traitement risque de laisser les écarts ouverts derrière un indicateur rassurant.

La CNIL recommande une revue régulière, au minimum annuelle, des habilitations, ainsi que leur adaptation aux changements de mission et aux départs. Je distingue ce rendez-vous périodique du traitement quotidien : un départ confirmé n’attend pas la prochaine campagne. Le rythme de revue doit aussi tenir compte de la sensibilité des accès et des mouvements dans les équipes.

J’écris le périmètre retenu : application, population, types de droits et date de l’extraction. Je précise les exclusions. Si les accès des prestataires ou les comptes techniques ne sont pas encore examinés, ils apparaissent comme un travail restant avec un responsable désigné. Une revue partielle peut être utile ; elle ne permet pas de déclarer l’ensemble du système vérifié.

Transformer l’extraction technique en dossier de décision

Pour chaque accès, je rapproche le compte d’une personne ou d’un usage identifié. Le dossier indique son responsable, sa mission actuelle, les permissions détenues et leur origine. Un droit attribué directement et un droit reçu par un groupe doivent rester distinguables pour préparer la correction.

La traduction métier est indispensable. Consulter des factures, modifier des coordonnées bancaires et exporter un fichier complet sont des capacités différentes. Un intitulé de profil ne les rend pas toujours visibles. Je demande à l’administrateur fonctionnel de décrire les opérations permises, puis au propriétaire de l’application de confirmer cette lecture.

Je conserve aussi la source et la date des informations. Une dernière connexion peut aider à poser une question, mais elle ne dit pas seule si le droit reste nécessaire. Un usage saisonnier, une délégation ou une opération de clôture demandent une explication. Une activité récente ne justifie pas davantage toutes les permissions du compte.

Un tableur suffit pour démarrer si son accès est limité aux personnes concernées et si les versions restent maîtrisées. J’évite de diffuser l’inventaire complet à tous les managers : chacun reçoit les lignes sur lesquelles il doit décider, avec assez de contexte pour comprendre la demande.

Confier au métier une décision explicite sur chaque accès

Le manager connaît les missions de la personne. Le responsable de l’application connaît les fonctions sensibles et les règles d’accès à ses données. Je fais préciser lequel décide, et comment ils se consultent lorsque leurs périmètres se croisent. La DSI prépare et exécute ; elle ne peut pas deviner si un commercial travaille encore sur un portefeuille régional.

La documentation Microsoft sur la préparation des revues d’accès distingue les ressources examinées, les réviseurs et le traitement des résultats. J’en retiens une règle d’organisation : nommer le décideur avant d’envoyer les demandes. Un outil de campagne ne résout pas une responsabilité laissée vacante.

Voici une grille de travail proposée, à adapter à l’application.

Je refuse les validations globales lorsque les profils diffèrent. Pour un droit sensible, la justification doit permettre à un autre responsable de comprendre le besoin. La présence de la personne dans l’organigramme ne répond pas à cette question.

Traiter les silences et les exceptions sans les masquer

Avant le lancement, j’annonce la date de réponse, le suppléant et le destinataire de l’escalade. Si le responsable ne répond pas, la ligne reste à décider. Une relance automatique peut être utile, mais elle ne transforme pas son silence en approbation.

Le maintien provisoire doit être explicite : motif, responsable qui l’accepte, périmètre et date de réexamen. Selon le risque, une restriction peut être nécessaire avant cette échéance. Cette décision se prépare avec le responsable du service ; une suppression aveugle en fin de campagne peut interrompre une activité indispensable. À l’inverse, une exception sans échéance devient facilement un droit permanent.

Les comptes techniques demandent un traitement distinct. Je cherche le traitement automatisé concerné, son propriétaire et les dépendances avant de proposer une modification. Les bonnes pratiques IAM d’AWS prévoient également l’examen régulier des utilisateurs, rôles, permissions et identifiants inutilisés. La revue ne se limite donc pas aux comptes nominatifs des salariés.

Je sépare aussi les comptes de secours des comptes ordinaires : leur faible activité peut correspondre à leur fonction. Leur justification et leur contrôle relèvent d’un dispositif spécifique, décrit dans l’article sur les accès administrateurs d’urgence. Les classer automatiquement comme inutiles ferait perdre le sens de la revue.

Vérifier les retraits dans l’application concernée

Une revue des habilitations se termine quand les décisions sont appliquées et vérifiées, pas quand le dernier tableau est signé.

Je distingue dans le suivi la décision, l’action exécutée et son contrôle. Avant toute correction, l’administrateur compare l’état actuel avec l’extraction de départ. Une habilitation légitime peut avoir changé pendant la campagne. Appliquer un ancien fichier sans examiner ces écarts risque d’annuler une décision plus récente.

Le retrait doit viser la bonne origine du droit. Enlever une affectation directe ne suffit pas si un groupe continue à accorder la même capacité. Je demande donc une vérification dans l’application cible, en tenant compte des mécanismes de synchronisation et des sessions existantes. Le contrôle doit établir ce qui reste effectivement accessible.

Pour une réduction sensible, je prépare avec le métier une vérification autorisée : l’opération retirée doit être refusée, tandis que le travail conservé doit rester possible. Le dispositif dépend de l’application et doit éviter d’exposer des données ou d’utiliser le mot de passe d’un salarié. Si le changement provoque un blocage, le rétablissement éventuel passe par une décision tracée, limitée au besoin confirmé.

Le dossier conserve la preuve adaptée : relevé des permissions après correction, journal de modification ou résultat du contrôle. Je n’accumule pas des captures sans contexte. Il faut pouvoir relier chaque preuve à la décision et au compte concernés.

Clôturer les écarts et préparer la prochaine revue

Le bilan distingue les accès examinés, les décisions manquantes, les corrections vérifiées et les exceptions ouvertes. Un taux de réponse seul ne permet pas de juger le résultat. Je présente surtout les situations qui restent à arbitrer et les raisons pour lesquelles elles subsistent.

Les anomalies récurrentes doivent alimenter une correction du fonctionnement courant. Si les mutations internes laissent systématiquement les anciens droits, il faut revoir le circuit de changement de poste. Refaire le même nettoyage à chaque campagne n’est pas une solution durable. Si personne ne comprend un profil, sa définition doit être clarifiée avant la prochaine attribution.

Pour commencer la semaine prochaine, je choisirais une application et réunirais son responsable métier avec son administrateur. Nous préparerions l’extraction, traduirions les profils et fixerions les règles de décision. Je réserverais dès ce moment un créneau pour appliquer puis contrôler les corrections. Le livrable attendu serait un périmètre effectivement revu, avec ses limites visibles et ses exceptions suivies.