Comment auditer les comptes orphelins après un départ

Un compte orphelin est une identité technique encore active alors que son titulaire n’a plus de raison légitime d’accéder au système. Le problème n’est pas théorique : un départ clôturé côté ressources humaines peut laisser des sessions, clés, délégations et comptes locaux actifs pendant des semaines.

→ Lire l’explication complète de la marmotte

Comptes orphelins : le compromis entre rapidité et exhaustivité

La révocation immédiate coûte de la coordination, des automatisations et quelques faux positifs. L’inventaire exhaustif coûte du temps, surtout pour les accès hérités et les exceptions. Le compromis est réel, mais la décision ne l’est pas : pour un départ confirmé, la désactivation doit primer sur la disponibilité individuelle. Réactiver un accès légitime prend quelques minutes ; expliquer un accès utilisé après le départ prend nettement plus longtemps, souvent avec des gens qui apprécient peu les minutes.

Le système de gestion des identités et des accès, IAM (Identity and Access Management), ne doit pas être considéré comme la source unique de vérité par défaut. Il l’est seulement si tous les systèmes cibles sont raccordés, si les comptes locaux sont interdits ou recensés, et si les identités techniques ont un propriétaire désigné. Un annuaire central correctement fédéré réduit la surface de révocation, il ne la fait pas disparaître.

Le registre des ressources humaines doit être la référence pour l’état contractuel : actif, départ planifié, suspendu, départ effectif. L’IAM traduit cet état vers les habilitations. Cette traduction doit être événementielle pour les départs, pas seulement exécutée par un traitement nocturne. Une synchronisation quotidienne est acceptable pour une mise à jour d’intitulé de poste ; elle est insuffisante pour un licenciement notifié à 10 h 12 et un jeton encore accepté à 18 h 00.

Les causes récurrentes sont connues :

création directe d’un compte dans une base de données, un pare-feu, une appliance ou une plateforme d’administration ;
compte personnel de fournisseur cloud employé pour des tâches professionnelles, hors fédération ;
accès par réseau privé virtuel, VPN (Virtual Private Network), avec compte partagé ou certificat client non rattaché à une personne ;
procuration de boîte aux lettres, délégation d’administration, groupe imbriqué ou rôle temporaire jamais expiré ;
compte de service créé au nom d’une personne puis réutilisé par une équipe ;
clé d’accès, certificat ou jeton applicatif émis avant le départ et non inventorié.

La règle est brutale mais vérifiable : aucun compte partagé ne permet d’attribuer correctement une action à une personne. S’il est indispensable pour une contrainte technique temporaire, il doit être traité comme une exception à durée limitée, avec un coffre de secrets, une rotation à chaque changement d’équipe et une journalisation de consultation. Le compte partagé permanent est une dette d’audit déguisée en raccourci.

La gouvernance des identités définit les rôles et les séparations de tâches. Le contrôle des comptes orphelins vérifie autre chose : que l’identité qui détenait ces rôles existe encore, et que les chemins d’accès périphériques ont disparu avec elle.

Croisement RH, authentification et inventaire des accès

Un audit crédible ne se contente pas de demander une exportation des comptes actifs. Il construit un rapprochement entre trois jeux de données : le registre des personnes, l’inventaire des identités techniques et les journaux d’authentification. Chaque source compense les angles morts des deux autres.

Le registre RH fournit un identifiant immuable de personne, une date de fin effective et le statut du contrat. L’adresse électronique n’est pas un identifiant fiable : elle peut être réattribuée, renommée ou absente chez un prestataire. L’identifiant RH doit être propagé comme attribut dans l’annuaire et dans les systèmes raccordés. Sans clé de rapprochement stable, l’audit devient un concours de reconnaissance de noms, discipline qui ne mérite pas d’exister.

L’inventaire des identités doit inclure les comptes humains, comptes locaux privilégiés, clés d’interface de programmation applicative, certificats d’authentification, délégations et appartenances à des groupes. Pour chaque objet, conserver au minimum : identifiant unique, système émetteur, propriétaire humain ou équipe, type d’accès, privilège maximal, date de création, dernière utilisation, date d’expiration et mécanisme de révocation.

Les journaux d’authentification révèlent les comptes ignorés par les exports. Une connexion réussie après la date de départ est un incident potentiel, pas une anomalie statistique à classer après la réunion mensuelle. Il faut corréler les succès, échecs, renouvellements de jetons et élévations de privilèges. Un compte sans activité n’est pas sain pour autant : il peut conserver un accès dormant, précisément apprécié par un attaquant patient.

La détection d’inactivité complète donc le rapprochement RH, sans s’y substituer. Un seuil de 45 à 90 jours convient aux comptes humains standards si la fréquence d’usage est connue. Les comptes d’administration, comptes de secours et identités de service exigent une politique distincte : leur rareté d’usage peut être normale, leur absence de propriétaire ne l’est jamais. Marquer automatiquement ces identités comme inactives puis les supprimer est une façon énergique de découvrir les dépendances cachées. Ce n’est pas une stratégie d’architecture.

Les campagnes de recertification doivent être ciblées. Demander trimestriellement à chaque responsable de confirmer une liste de 2 000 droits produit une signature, pas une vérification. Cibler les personnes en préavis, les départs récents, les privilèges élevés, les comptes sans connexion et les accès hors IAM permet de demander une décision précise : conserver, transférer, désactiver, supprimer. Une absence de réponse doit entraîner la désactivation pour les droits privilégiés et les accès non justifiés.

Exemple de rapprochement entre registre RH et logs

Le contrôle détecte les identifiants ayant réussi une authentification après la date de départ. Il croise deux exports, celui du registre RH et celui des journaux d’authentification, conservés dans un répertoire protégé. La comparaison porte sur un identifiant immuable, jamais sur le nom affiché.

Ce contrôle ne prouve pas qu’un ancien titulaire s’est connecté. Un compte peut avoir été repris illégitimement, utilisé par un automatisme ou compromis avant le départ. Il prouve en revanche que la désactivation attendue n’a pas empêché une authentification. La suite obligatoire est d’identifier le système émetteur, de couper le chemin d’accès, de préserver les journaux et de rechercher les actions réalisées avec cette identité.

Pour les environnements cloud, compléter ce rapprochement par l’inventaire des rôles, clés et relations de confiance. La détection de persistance IAM dans AWS couvre les traces et objets qui survivent souvent à la suppression d’un utilisateur fédéré.

Départ hostile : révocation simultanée et sessions survivantes

Un départ hostile, une suspension disciplinaire ou un licenciement impose un traitement distinct du départ planifié. La date de désactivation est alors un événement de sécurité, déclenché par une notification restreinte et horodatée. Le responsable RH, l’exploitation des identités, la sécurité et les équipes propriétaires des systèmes non fédérés doivent connaître leur action avant l’événement. Improviser une matrice d’escalade au moment du départ revient à tester un parachute pendant la chute.

La désactivation doit couvrir simultanément :

le compte annuaire et l’authentification fédérée ;
les comptes locaux et administratifs ;
les accès VPN, certificats clients et appareils gérés ;
les clés d’accès cloud, jetons personnels et secrets déposés dans les outils d’intégration ;
les délégations de messagerie, mandats, groupes et rôles ;
les accès physiques et consoles hors bande ;
les canaux de récupération de compte, notamment adresses personnelles et facteurs d’authentification enregistrés.

Désactiver le compte central ne révoque pas nécessairement une session déjà établie. Un jeton signé reste accepté jusqu’à son expiration si l’application ne consulte pas un état de révocation. Un certificat révoqué peut rester utilisable si le service ne vérifie pas son statut. Une clé d’accès déjà copiée n’est pas rappelée par télépathie. Pour les accès sensibles, imposer des durées de session courtes, une validation de session côté serveur et une révocation de jetons par identifiant de session.

La désactivation ne garantit pas l’effacement des données extraites avant le départ, la suppression de copies locales, ni l’absence de collusion interne. Ces risques relèvent de la protection des données, de la supervision et des contrôles d’accès continus. La sécurité des données complète ce sujet, mais aucun mécanisme d’identité ne remonte le temps.

Exploitation, preuves et reprise contrôlée

Une procédure exploitable doit produire une preuve horodatée de chaque révocation : événement RH reçu, identités résolues, systèmes ciblés, résultat par système, sessions invalidées et exceptions restantes. Un succès global sans détail par connecteur masque exactement le système oublié que l’audit cherche à révéler.

Les erreurs de désactivation doivent ouvrir un ticket prioritaire avec relance automatique. Une erreur transitoire n’est pas une désactivation différée acceptable lorsque l’événement est hostile. Prévoir un mécanisme de mise en quarantaine réseau ou de blocage au proxy pour les systèmes incapables de désactiver immédiatement un compte. Le contournement doit être documenté, temporaire et testé, sinon il devient le plan officiel par accident.

Les sauvegardes restaurent parfois des comptes supprimés. Après une restauration d’annuaire ou d’application, rejouer la liste des départs depuis le dernier point de sauvegarde et vérifier les identités réactivées. La reprise après incident est un chemin de création de comptes, même si la documentation préfère l’appeler restauration pour garder l’ambiance détendue.

Conserver les traces d’authentification et de révocation selon la politique de conservation définie avec les équipes conformité et sécurité. L’objectif n’est pas de donner un avis juridique : il s’agit de pouvoir établir factuellement qui possédait quel accès, quand la révocation a été demandée, et quel système a échoué à l’appliquer.

🐝 Ce qui arrive si on s’en passe

Sans ce rapprochement, l’identité survivante devient une entrée qui ne déclenche aucune alerte : l’activité d’un ancien titulaire se confond avec le trafic légitime, puisque le compte figure encore parmi les identités attendues. L’absence de clé de rapprochement stable interdit ensuite de borner l’incident : impossible de dire, lors d’une investigation, quels accès existaient à quelle date, ni d’attribuer une action à une personne plutôt qu’à une boîte partagée. Les mécanismes de récupération de compte restent exploitables par une adresse personnelle ou un facteur enregistré, ce qui permet de reprendre la main sur une identité pourtant réputée close. Enfin, faute d’inventaire des propriétaires, toute tentative de nettoyage ultérieure coupe des dépendances inconnues, et le nettoyage lui même devient un risque d’indisponibilité plutôt qu’une mesure de sécurité.

🦫 Explication de la marmotte 🍫

Quand une personne quitte une organisation, son dossier est marqué comme terminé par le service qui gère les contrats. Cette information doit ensuite être transmise aux systèmes qui donnent accès aux messageries, fichiers, applications, serveurs et outils à distance. Un compte orphelin apparaît quand cette transmission manque, arrive trop tard, ou ne couvre pas tous les accès.

Pour les repérer, on compare la liste des personnes parties avec la liste des comptes encore actifs. On examine aussi les traces de connexion : une connexion réussie après une date de départ montre qu’un accès fonctionne encore. Les comptes sans connexion récente sont vérifiés séparément, car ils peuvent rester disponibles sans laisser de trace récente.

Lors d’un départ conflictuel, les accès doivent être coupés au même moment. Désactiver seulement le compte principal ne suffit pas si une session déjà ouverte, une clé d’accès, un certificat ou un compte local reste accepté. Chaque système doit signaler que la coupure a réussi. Si l’un échoue, il faut le bloquer autrement puis corriger la cause.

Les responsables doivent aussi vérifier les délégations, les comptes partagés et les accès donnés directement à une application. Enfin, après une restauration de sauvegarde, il faut contrôler que des comptes supprimés ne sont pas revenus actifs.