Comment automatiser la recertification des accès sensibles

La recertification vérifie périodiquement qu’une identité conserve des droits justifiés sur un système donné. Le compromis central est brutal : on gagne une réduction mesurable des accès dormants, mais on paie en préparation des données, en indisponibilités contrôlées et en charge pour les validateurs. Il faut accepter ce coût, puis l’encadrer : une campagne sans révocation automatique est un questionnaire coûteux, pas un contrôle.

→ Lire l’explication complète de la marmotte

Périmètre de recertification et prérequis de données

Commencer par les systèmes où un accès erroné produit un effet direct : administration d’identités, production, sauvegardes, secrets, données personnelles, dépôt de code, chaîne de déploiement et consoles cloud. Une application interne sans donnée sensible ni capacité d’administration peut attendre. Un coffre de secrets ou un annuaire d’identités ne peut pas attendre, même si son inventaire est pénible. L’inventaire est justement le travail. La version plaquette de la gouvernance tient dans un tableur ; la version qui tient en exploitation commence par savoir quelles identités existent.

Classer chaque système selon quatre critères : capacité de modification, lecture de données sensibles, privilège technique et exposition réseau. Donner une priorité maximale à un système cumulant au moins deux critères. Documenter également le propriétaire métier, le propriétaire technique, la source d’identité et le mécanisme de retrait des droits. Sans propriétaire joignable, il n’existe pas de décision de maintien possible. Il existe seulement un accès qui vieillira mal.

Avant le premier cycle, disposer de ces éléments :

une source faisant autorité pour les identités humaines, avec statut d’emploi ou de contrat ;
une source distincte pour les comptes de service, les comptes d’urgence et les comptes techniques ;
un identifiant stable, non réutilisé, pour joindre identité, droits et journaux ;
un journal d’authentification horodaté, conservé au moins sur une période de recertification ;
une interface de retrait automatisable, par annuaire, interface de programmation ou outil de gestion des identités ;
une liste des rôles et groupes donnant effectivement accès au système.

L’IAM (Identity and Access Management), ou gestion des identités et des accès, doit être capable de distinguer l’identité d’un utilisateur de son appartenance à un groupe. Recertifier « le groupe administrateurs » sans montrer les permissions réelles de ce groupe masque souvent le problème. Les droits indirects sont les droits préférés des attaquants : ils sont moins visibles et survivent mieux aux campagnes décoratives.

Pour les comptes fédérés, récupérer la dernière authentification auprès du fournisseur d’identité, pas seulement auprès de l’application. Pour les comptes locaux, lire le journal applicatif ou l’annuaire. Une absence de connexion ne prouve pas l’absence d’usage : une clé d’accès machine, un jeton long terme ou une session automatisée peuvent agir sans connexion interactive. Ces identités doivent être revues par finalité, propriétaire et date de rotation, pas par « dernière connexion ».

La gestion des identités fournit le socle d’attribution. La recertification ne remplace ni l’authentification forte, ni la séparation des privilèges, ni la suppression des protocoles faibles. À ce sujet, désactiver les binds LDAP anonymes et en clair reste une mesure indépendante : vérifier un droit tous les trimestres ne rend pas un annuaire exposé moins lisible.

Rapport d’accès avec activité observable

Produire un rapport figé au début de chaque campagne. Ne jamais faire valider une vue dynamique : un changement de groupe pendant la période ferait juger au validateur une réalité qui a déjà disparu. Conserver l’horodatage d’extraction, le périmètre et une empreinte du fichier.

Chaque ligne doit représenter un couple identité-droit, et non seulement une identité. Inclure :

l’identifiant stable et le nom affiché ;
le statut de l’identité, humaine, technique, urgence ou externe ;
le système, le rôle effectif et le chemin d’attribution ;
le propriétaire du droit ;
la dernière authentification interactive connue ;
la dernière action métier ou technique connue, si elle existe ;
la date de dernière revue et la décision précédente ;
le validateur désigné et l’échéance.

La dernière connexion apporte du contexte, pas un verdict. Un administrateur de reprise peut légitimement ne jamais se connecter hors incident. À l’inverse, une connexion récente ne justifie pas un rôle de super-administrateur. Une campagne qui confond activité et besoin métier finit par maintenir tout ce qui clignote, méthode très compatible avec les tableaux de bord, beaucoup moins avec la réduction du risque.

Exemple reproductible : exporter les droits et la dernière connexion

L’exemple suivant suppose PostgreSQL 15 ou plus récent, avec trois tables : accounts, role_memberships et auth_events. L’événement d’authentification est corrélé par account_id. Ajuster les noms de rôles à la nomenclature du système, pas l’inverse.

# Exporte un instantané CSV (Comma-Separated Values) horodaté des accès à revoir.
# Les dates sont forcées en UTC pour éviter une échéance qui change de jour selon le serveur.
export REVIEW_DATE="$(date -u +%F)"
export PGPDATABASE="sensitive_app"

psql --set ON_ERROR_STOP=1 --csv <<'SQL' > "access-review-${REVIEW_DATE}.csv"
WITH last_login AS (
  SELECT account_id, max(event_at) AS last_login_at
  FROM auth_events
  WHERE event_type = 'interactive_login'
  GROUP BY account_id
)
SELECT
  a.account_id,
  a.display_name,
  a.account_type,
  a.status,
  rm.role_name,
  rm.assignment_source,
  coalesce(to_char(ll.last_login_at AT TIME ZONE 'UTC',
                   'YYYY-MM-DD"T"HH24:MI:SS"Z"'), 'never') AS last_login_utc,
  rm.granted_at AT TIME ZONE 'UTC' AS granted_at_utc
FROM accounts a
JOIN role_memberships rm ON rm.account_id = a.account_id
LEFT JOIN last_login ll ON ll.account_id = a.account_id
WHERE a.status = 'active'
  AND rm.role_name IN ('production-admin', 'secrets-reader', 'backup-operator')
ORDER BY rm.role_name, a.display_name;
SQL

sha256sum "access-review-${REVIEW_DATE}.csv" \
  > "access-review-${REVIEW_DATE}.csv.sha256"

Restreindre l’accès au fichier exporté : il contient une cartographie de privilèges, donc une liste de cibles. Chiffrer le stockage, limiter la rétention au besoin d’audit et journaliser les téléchargements. Ne pas déposer ce fichier dans un ticket public ou dans un dépôt Git. Git n’oublie rien, surtout ce qui aurait dû disparaître.

Workflow de validation et décisions traçables

Attribuer chaque ligne à un validateur qui connaît le besoin métier, puis associer un approbateur technique pour les privilèges élevés. Une seule personne ne doit pas à la fois demander, détenir et recertifier son propre accès. Les comptes d’urgence font exception uniquement si leur contrôle est effectué par une fonction indépendante et enregistré.

Découper les sessions par système et par nature de privilège. Fixer une limite de 25 à 50 décisions par session, selon l’homogénéité des droits. Au-delà, la fatigue transforme la revue en clic industriel. Les outils promettant une validation en un clic ont résolu le problème de l’outil, pas celui de l’accès.

Imposer trois décisions exclusives : maintenir, réduire ou révoquer. Pour tout maintien sans activité visible depuis 90 jours, exiger une justification structurée : finalité, fréquence attendue, propriétaire responsable et date de fin si l’accès est temporaire. Un texte libre du type « besoin opérationnel » ne contient aucune information contrôlable. Le rejeter automatiquement.

Définir une échéance courte, par exemple 14 jours pour les accès à privilège élevé et 30 jours pour les autres. Envoyer un rappel à mi-parcours, puis une escalade au propriétaire du système. Ne pas prolonger toute la campagne parce que quelques validateurs sont silencieux : prolonger seulement les lignes explicitement justifiées. Le silence est une absence de recertification, pas une forme moderne d’approbation.

Conserver une piste d’audit immuable : identité du décideur, instant de décision, état présenté, justification, ancienne et nouvelle affectation. Un outil de gestion de tickets peut porter le workflow initial, mais la décision doit finir dans une source exploitable par l’automatisation. Un commentaire perdu dans une boîte de réception ne déclenche rien, sauf une future discussion pénible.

Désactivation automatique et exceptions contrôlées

À l’échéance, désactiver les droits non recertifiés. La recommandation est ferme : retirer l’appartenance au rôle ou désactiver le compte, selon le niveau de risque, plutôt que créer une liste de relances manuelles. Pour un compte à privilège élevé, retirer à l’échéance. Pour un compte métier standard, une grâce limitée peut être admise si le système ne tolère pas une coupure immédiate, mais cette grâce doit être codée, datée et visible.

Tester le retrait dans un environnement représentatif. Vérifier notamment les groupes imbriqués, les caches d’autorisation, les jetons déjà émis et les comptes liés à des traitements planifiés. Retirer un rôle ne révoque pas forcément une session existante ni un jeton à longue durée de vie. Le reste doit venir d’une durée de session bornée, d’une révocation de jeton lorsque le protocole le permet, et d’une rotation des secrets de compte technique.

Les accès d’urgence exigent une procédure séparée : accès désactivé par défaut, activation limitée dans le temps, justification obligatoire, alerte immédiate et revue après usage. Les laisser actifs « au cas où » transforme une porte de secours en entrée principale avec un panneau discret.

Protéger l’automate de révocation comme un composant à privilège élevé. Son identité doit avoir le droit minimal de retirer les affectations ciblées, jamais un rôle d’administration générale. Stocker son secret dans un gestionnaire de secrets, le faire tourner, journaliser chaque appel et alerter sur les échecs. Une sauvegarde des affectations avant retrait est nécessaire pour restaurer une erreur, mais cette sauvegarde ne doit jamais devenir un bouton de réattribution sans validation.

Indicateurs de recertification et surveillance du cycle

Mesurer le taux de décision dans les délais, le taux de maintien, le taux de réduction et le taux de révocation. Le taux de révocation réel se calcule ainsi :

droits effectivement retirés / droits présentés à la revue

Mesurer aussi l’écart entre décisions de révocation et retraits réellement exécutés. Un taux de 100 % de décisions, avec 80 % d’exécution, indique un problème de connecteur, de droits de l’automate ou de dépendance non modélisée. Ce n’est pas une campagne réussie avec une marge d’amélioration, c’est un contrôle qui ment.

Suivre les justifications de maintien sans usage récent, les exceptions expirées et les refus de désactivation. Une baisse durable du taux de révocation peut signifier que le modèle de droits est devenu plus propre. Elle peut aussi signifier que les validateurs ont appris à cocher « maintenir ». Comparer ce taux avec la part de décisions sans justification et avec le volume de droits ajoutés entre deux cycles.

Envoyer les journaux vers le système de supervision, puis alerter sur trois signaux : retrait échoué, droit recréé après révocation sans nouvelle demande, et compte désactivé encore authentifié. Cette dernière alerte révèle souvent un cache, un jeton non révoqué ou une source d’identité parallèle. Les données sensibles et les journaux d’accès doivent être traités ensemble : sans preuve d’activité fiable, la revue devient une consultation d’oracle, avec moins de magie et davantage de fichiers CSV.

🐝 Ce qui arrive si on s’en passe

Sans cycle de recertification, les droits ne font que s’empiler : chaque changement de poste ajoute un rôle et n’en retire aucun, si bien que le périmètre réel d’une identité finit par dépasser tout ce qu’un propriétaire accepterait d’approuver s’il en voyait la liste. La porte de la ruche reste ouverte pour des comptes de prestataires terminés, des comptes techniques dont plus personne ne connaît la finalité, des groupes hérités d’un projet clos. Conséquence directe lors d’un incident : le périmètre de compromission d’une seule identité devient impossible à borner rapidement, puisque rien ne date l’attribution ni ne justifie le maintien. Il manque aussi la preuve attendue en audit ou après sinistre : aucune trace horodatée ne permet de montrer qu’un droit a été examiné, par qui, ni sur quelle justification.

🦫 Explication de la marmotte 🍫

Une revue d’accès commence par choisir les systèmes où une erreur de permission peut permettre de lire, modifier ou supprimer des informations sensibles. Pour chaque système, il faut connaître les personnes et comptes techniques qui ont des droits, les droits exacts obtenus et la dernière activité observée.

Une liste est créée à une date précise. Chaque ligne indique une personne ou un compte, son droit, la façon dont ce droit a été obtenu et son activité récente. Cette liste est envoyée à une personne responsable capable de dire si le droit reste nécessaire. Les décisions sont limitées en nombre pour éviter les validations faites trop vite. Quand un droit est conservé malgré une absence d’activité, une raison précise est demandée.

Chaque décision est enregistrée avec sa date et son auteur. Si aucune décision n’est prise avant la date limite, le droit est retiré automatiquement. Cette automatisation doit être testée, car retirer un droit peut ne pas couper une connexion déjà ouverte ou un accès conservé par un autre mécanisme.

Après chaque cycle, il faut compter les droits retirés, les retraits qui ont échoué et les droits recréés ensuite. Si presque rien n’est retiré, il faut vérifier que les responsables examinent réellement les demandes. Si des retraits échouent, il faut corriger le système qui applique les décisions avant le cycle suivant.