- Marriott International (2018) : l'attaquant avait accès au système de réservation de Starwood depuis 2014 — quatre ans avant la découverte — via un compte de la chaîne rachetée jamais désactivé.
- Twitter/X (2020) : des comptes internes dormants avec accès aux outils d'administration ont facilité une attaque d'ingénierie sociale ciblant des employés peu actifs sur ces systèmes.
- Les comptes orphelins persistent en moyenne plusieurs mois dans les annuaires d'entreprise faute de processus de déprovisioning automatisé lié aux événements RH.
- Un compte inactif depuis 90 jours représente une surface d'attaque comparable à un compte actif mais sans surveillance : il répond aux requêtes d'authentification sans déclencher d'alerte.
- Le NIST SP 800-53 (AC-2) exige la désactivation ou suppression des comptes dans des délais définis — exigence rarement implémentée via des processus entièrement automatisés.
Les comptes oubliés constituent l'une des catégories de risques les plus documentées et les plus persistantes en gestion des accès. Leur existence ne résulte pas d'une erreur technique mais d'une défaillance de processus : l'organisation ne dispose pas de mécanisme fiable pour corréler les événements RH avec les actions d'administration dans les systèmes d'information. La conséquence est une accumulation silencieuse de comptes actifs dont les titulaires réels n'existent plus dans l'organisation.
Le terme "orphelin" est fonctionnel : ces comptes répondent aux requêtes d'authentification, consomment des licences, apparaissent dans les logs, mais ne sont associés à aucun titulaire identifiable pouvant valider leur usage légitime. Leur dangerosité est amplifiée par leur invisibilité : un compte inactif ne génère pas d'alerte par défaut dans la majorité des SIEM, et n'attire pas l'attention lors des revues de sécurité courantes.
La mécanique de création des comptes orphelins
Les comptes orphelins se créent selon plusieurs mécanismes distincts. Le départ non traité : un employé quitte l'organisation et son manager, occupé par la transition, omet de notifier l'équipe IT dans les délais définis — ou aucun processus formel de notification n'existe. La fin de mission prestataire : les accès accordés temporairement pour un projet ne sont jamais retirés car la responsabilité n'est clairement assignée à personne. La prolifération de comptes de service : des comptes techniques créés pour une intégration ou un déploiement restent actifs longtemps après que le système concerné a été remplacé ou désactivé.
Dans les environnements multi-domaines ou multi-cloud, la problématique se complexifie : un compte peut être désactivé dans l'annuaire Active Directory mais rester actif dans un service SaaS fédéré via SAML, dans un bucket S3 avec une clé d'accès programmatique, ou dans un serveur Linux géré séparément. La revue des accès doit donc être exhaustive par système, pas uniquement globale par identifiant nominal.
En juillet 2019, une ancienne ingénieure d'Amazon Web Services a exploité une mauvaise configuration de pare-feu applicatif pour accéder aux données de 100 millions de clients de Capital One hébergées sur AWS. L'accès initial a été facilité par un rôle IAM AWS trop permissif, attaché à une instance EC2, qui permettait de lister et lire l'ensemble des buckets S3 de l'organisation. Ce rôle n'avait pas fait l'objet de revue depuis sa création. L'incident a coûté 80 millions de dollars d'amendes et a mis en lumière l'insuffisance des revues périodiques des permissions IAM cloud — distinctes des comptes utilisateurs nominatifs mais tout aussi exposées à la dérive progressive des droits.
Détection et remédiation
La détection des comptes orphelins repose sur deux approches complémentaires. La revue systématique des comptes inactifs : identifier tous les comptes dont la dernière authentification date de plus de 60 ou 90 jours selon le niveau de criticité du système. Cette revue doit distinguer les comptes utilisateurs interactifs des comptes de service, dont l'inactivité peut être normale par nature. La corrélation avec les données RH : automatiser la comparaison entre les comptes actifs dans les annuaires et le référentiel des collaborateurs actifs, en incluant les prestataires via les données de gestion des contrats.
La remédiation ne doit pas être systématiquement la suppression immédiate. Un protocole en deux temps — désactivation avec conservation 30 jours, puis suppression après confirmation de l'absence d'impact — permet de gérer les cas limites sans précipitation. Ce protocole doit être documenté, sa durée adaptée à la criticité de l'environnement concerné, et son exécution tracée pour audit.
Automatisation du déprovisioning
Le déprovisioning manuel est structurellement défaillant dans les organisations de taille significative. Le volume d'événements à traiter dépasse rapidement la capacité d'une équipe IT à traiter chaque cas dans les délais requis. L'automatisation via une intégration entre le SIRH et l'IAM est la solution de référence : un événement de départ dans le SIRH déclenche automatiquement la désactivation du compte dans l'annuaire central et, par propagation, dans les systèmes fédérés. Cette intégration doit inclure les comptes de service associés et les accès aux outils SaaS non fédérés.
La violation de Home Depot a exposé 56 millions de cartes bancaires via des identifiants de prestataire compromis. L'accès initial a été obtenu avec les credentials d'un fournisseur tiers ayant accès aux systèmes de point de vente. Ces identifiants n'avaient pas fait l'objet de révision ni de rotation depuis leur attribution. L'attaquant a pu installer un malware de capture sur les terminaux de 2 000 magasins, actif pendant cinq mois avant détection — une durée directement liée à l'absence de monitoring des accès prestataires.
EasyJet a divulgué en mai 2020 avoir subi une violation affectant neuf millions de clients, dont les données de 2 208 cartes bancaires. L'attaque, détectée en janvier mais remontant à plusieurs mois, a impliqué des accès persistants non détectés à des systèmes de réservation. L'ICO a mis en évidence des lacunes dans la gestion des accès aux systèmes de traitement des données clients. EasyJet a écopé d'une amende de 20 millions de livres sterling au titre du RGPD pour insuffisance des mesures de protection.
Cathay Pacific a annoncé en octobre 2018 une violation affectant 9,4 millions de passagers, dont l'accès non autorisé avait débuté en octobre 2014 — soit une présence de quatre ans dans les systèmes avant détection. L'attaquant a accédé aux bases de données de passagers contenant passeports, dates de naissance et historiques de voyage. L'enquête a révélé une absence de détection des accès anormaux sur les bases de données, et des comptes de service aux droits trop larges utilisés comme vecteur de mouvement latéral.