Les conséquences d’un accès non révoqué après un départ

Points clés Colonial Pipeline (2021) : l'accès VPN utilisé pour l'attaque ransomware appartenait à un ancien employé dont le compte n'avait pas été désactivé ap

M
Mehdi SARIAK
24 mai 2026 7 min de lecture 14 lectures
Points clés
  • Colonial Pipeline (2021) : l'accès VPN utilisé pour l'attaque ransomware appartenait à un ancien employé dont le compte n'avait pas été désactivé après son départ — la rançon versée s'est élevée à 4,4 millions de dollars.
  • Marriott/Starwood (2018) : l'attaquant opérait depuis 2014 via un compte lié à l'infrastructure de Starwood, rachetée par Marriott en 2016 sans nettoyage exhaustif des accès hérités.
  • Le délai moyen entre le départ d'un employé et la désactivation de ses accès est estimé à plusieurs jours dans les organisations sans déprovisioning automatisé — une fenêtre d'exposition significative.
  • Les comptes d'anciens employés conservent souvent la connaissance du contexte organisationnel : l'ex-titulaire sait quels systèmes accéder, quelles données trouver et comment naviguer sans déclencher d'alerte.
  • La revue des accès doit explicitement inclure une corrélation avec les données RH de départ — séparation, retraite, départ en période d'essai, fin de CDD — pour chaque type de contrat.

La révocation des accès après un départ est l'un des processus de gestion des accès les plus directement liés à des incidents réels documentés. Elle combine un risque technique — un compte actif répondant aux requêtes d'authentification — et un risque contextuel : l'ancien titulaire connaît l'organisation, ses systèmes, ses données et ses pratiques, ce qui rend l'exploitation potentiellement plus efficace qu'une compromission externe à l'aveugle.

Les scénarios d'accès non révoqué après départ sont multiples. Le départ volontaire avec délai de traitement IT trop long. La retraite ou le départ sans procédure de clôture formelle. Le licenciement où les accès ne sont pas révoqués immédiatement par peur du conflit ou par manque de processus. La fin de contrat prestataire sans notification formelle à l'équipe IT. Chacun de ces scénarios crée une fenêtre d'exposition dont la durée dépend directement de la qualité du processus de déprovisioning.

La fenêtre d'exposition post-départ

La durée de la fenêtre d'exposition est le facteur de risque principal. Un compte désactivé dans les deux heures suivant un départ a une surface d'attaque quasi-nulle. Un compte encore actif 30 jours après un départ est une cible exploitable. Dans les environnements sans automatisation du déprovisioning, la durée moyenne d'exposition se mesure en jours ou en semaines — parfois en mois ou en années pour les comptes de service ou les accès prestataires.

Cette durée est conditionnée par plusieurs facteurs : la rapidité de notification de l'équipe IT par les RH ou le manager, l'exhaustivité de l'inventaire des systèmes où révoquer l'accès (annuaire central, applications SaaS non fédérées, accès SSH, API keys, VPN), et l'existence d'un processus formalisé avec responsable désigné et délai maximum accepté.

Cas documenté — Marriott International, États-Unis, 2018

Marriott a révélé en novembre 2018 que la base de données de réservation Starwood Guest Reserve avait été compromise depuis 2014, soit deux ans avant le rachat de Starwood par Marriott. L'attaquant avait maintenu un accès persistant non détecté pendant quatre ans via des comptes liés à l'infrastructure Starwood, jamais identifiés ni désactivés lors de l'intégration post-fusion. Les données de 500 millions de clients ont été exposées, incluant noms, adresses, dates de naissance, passeports et données de cartes bancaires partielles. L'incident a illustré un scénario de déprovisioning négligé à grande échelle : l'intégration d'une entité rachetée sans audit exhaustif et nettoyage des accès hérités crée une surface d'attaque durable invisible dans les processus standard de gestion des accès.

Automatisation comme réponse structurelle

Le déprovisioning manuel est structurellement insuffisant dans les organisations de taille significative, non pas parce que les équipes sont incompétentes, mais parce que le volume d'événements à traiter — départs, fins de contrats, changements de poste, retraites — dépasse la capacité de traitement manuel dans les délais requis. L'automatisation via intégration SIRH-IAM est la réponse de référence : l'événement de départ dans le SIRH déclenche automatiquement la désactivation dans l'annuaire central, la révocation des tokens OAuth actifs, la désactivation des comptes dans les applications fédérées, et la génération d'une tâche de vérification pour les systèmes non fédérés.

Cette intégration doit traiter tous les types de départ, y compris les moins visibles : fin de période d'essai, départ en congé sabbatique prolongé, retraite progressive, fin de contrat prestataire. Elle doit également inclure la gestion des comptes de service associés à la personne — une catégorie souvent oubliée dans les implémentations initiales.

Gestion des accès lors des fusions-acquisitions

Les opérations de fusion-acquisition créent une catégorie spécifique de comptes orphelins : les comptes hérités de l'entité acquise, conçus pour ses systèmes et ses processus propres, qui se retrouvent intégrés dans le nouveau périmètre sans révision exhaustive. La due diligence technique en M&A doit inclure un audit des accès existants dans l'entité cible, avec une feuille de route de nettoyage et de migration vers le référentiel IAM de l'acquéreur dans les 90 jours suivant la clôture.

Cas documentés
Citibank — États-Unis US · 2011

Citibank a subi en 2011 une violation exposant les données de 360 000 comptes bancaires via une vulnérabilité d'API traversal. L'API du portail de banque en ligne permettait à un utilisateur authentifié de substituer son propre identifiant client dans l'URL par celui d'un autre client pour accéder à ses données — une absence de contrôle d'autorisation au niveau de l'accès aux ressources individuelles. La correction a nécessité une refonte du modèle d'autorisation de l'API. L'incident illustre que la gestion des accès couvre également les autorisations au niveau des ressources individuelles, pas seulement l'authentification initiale.

British Airways — Royaume-Uni EUROPE · 2018

British Airways a subi en 2018 une violation par skimming de formulaire web, exposant les données de 500 000 clients incluant données de cartes bancaires et identifiants de connexion. L'enquête de l'ICO a conclu à des insuffisances dans les mesures de sécurité, notamment dans la gestion des accès aux systèmes de paiement et dans la segmentation des composants tiers intégrés au site. British Airways a écopé d'une amende initiale de 183 millions de livres sterling — réduite à 20 millions après négociation, la plus importante prononcée sous le RGPD à l'époque.

SoftBank — Japon ASIE · 2023

SoftBank a annoncé en 2023 que des employés avaient partagé des données internes confidentielles avec ChatGPT lors d'usages non encadrés de l'outil. Les données concernées incluaient des informations sur des partenariats stratégiques, des données financières internes et des éléments de propriété intellectuelle. L'incident a mis en lumière une dimension nouvelle de la gestion des accès : les données partagées avec des services d'IA externes constituent un vecteur de fuite non couvert par les contrôles d'accès traditionnels. SoftBank a depuis mis en place des politiques d'usage des outils d'IA et des restrictions d'accès aux services externes depuis les postes professionnels.

WhatsApp