Offboarding Removes the Account but Not the Access

Le départ d’une personne déclenche la désactivation de son compte principal, mais pas l’inventaire ni la révocation de tous les moyens d’accès acquis pendant son passage : sessions, jetons, clés API ou SSH, comptes locaux, comptes chez des tiers, appareils inscrits, secrets partagés, accès VPN, RMM, applications non fédérées et mécanismes de récupération.

Le processus confond identité et compte. Le compte disparaît du répertoire; l’accès, lui, demeure dispersé dans l’environnement.

Les accès résiduels sont difficiles à attribuer et encore plus difficiles à chercher après coup. Certains peuvent fonctionner pendant des mois sans produire d’anomalie, surtout s’ils utilisent des outils légitimes ou des comptes partagés.

Un ancien employé, un sous-traitant ou toute personne ayant récupéré ses secrets peut revenir sans réactiver le compte désactivé. En incident, l’organisation croit avoir fermé la porte principale alors que plusieurs fenêtres sont encore ouvertes.

Le risque augmente pour les rôles techniques, les prestataires et les personnes ayant administré plusieurs clients ou plateformes.

• Comparer les départs récents aux comptes et identités présents dans les applications, VPN, pare-feu, plateformes infonuagiques, dépôts de code, RMM et outils de sécurité.
• Rechercher les clés, jetons et intégrations créés par l’utilisateur ou utilisés depuis ses appareils.
• Vérifier les comptes locaux, génériques et partagés auxquels la personne connaissait le secret.
• Examiner les appareils inscrits, facteurs d’authentification, mots de passe d’application et méthodes de récupération.
• Demander au gestionnaire et au responsable technique quels accès existaient réellement; le registre central est rarement complet à lui seul.

• Maintenir un registre des accès attribués, y compris les secrets non fédérés, clés, jetons, comptes locaux et plateformes tierces.
• Lier autant que possible chaque accès à une identité individuelle et imposer une expiration aux accès temporaires.
• Déclencher une liste de révocation adaptée au rôle, pas une procédure identique pour tous.
• Faire la rotation des secrets partagés connus de la personne et transférer la propriété des automatisations, clés et intégrations.
• Révoquer les sessions, appareils et facteurs; récupérer ou effacer les équipements gérés.
• Vérifier la fermeture avec des preuves techniques et non avec une case « terminé » dans le billet RH.

• Construire la liste complète des accès historiques de la personne ou de l’identité compromise.
• Révoquer sessions, jetons, clés, certificats, appareils et comptes secondaires; faire la rotation des secrets partagés.
• Examiner l’activité des plateformes non fédérées et des comptes locaux pendant toute la période pertinente.
• Rechercher les nouveaux comptes, règles, clés ou intégrations créés avant le départ ou la détection.
• Éviter de supprimer immédiatement les comptes ou artefacts nécessaires à l’enquête; désactiver, préserver, puis retirer selon une séquence documentée.

Cette fiche complète MFL-006 : MFL-006 porte sur les sessions qui survivent à la désactivation d’un compte; MFL-026 porte sur tous les accès qui ne dépendent plus de ce compte ou n’y ont jamais été rattachés.