Sécurité des départs : quels accès sont réellement retirés

La faille des départs

Quand une personne part, l’IT reçoit un ticket. Elle désactive le compte Okta, révoque peut-être un certificat VPN, et marque la tâche comme faite. Trente minutes un bon jour.

Le problème, c’est que le compte Okta n’est qu’une couche d’accès parmi d’autres. Un profil de travailleur du savoir accumule des dizaines d’identifiants indépendants au fil de son passage dans l’entreprise : applications ouvertes avec Google, outils provisionnés directement par l’IT, clés d’API générées, intégrations configurées. Rien de tout cela ne disparaît quand Okta s’éteint.

41% des partants conservent un accès

3–5 jours en moyenne pour un retrait complet

30% des SaaS non gérés en SSO

Ce qui survit à la désactivation du SSO

Le SSO et SCIM résolvent le problème pour lequel ils ont été conçus : l’identité fédérée pour les applications qui la prennent en charge. Cela couvre bien votre socle. Cela ne couvre pas tout, et l’écart est plus large que ne le pensent la plupart des équipes IT.

État des accès après déprovisionnement SSO

Type d’accès Exemples État

Applications fédérées en SSO Jira, Confluence, Salesforce (SSO) Révoqué

Applications OAuth Google Notion, Loom, Figma (connexion Google) Toujours actif

SaaS en connexion directe Outils historiques, portails fournisseurs Toujours actif

Clés d’API qu’elle a générées Jetons HubSpot, Stripe, AWS Toujours actif

Agents IA qu’elle a provisionnés Agents utilisant ses identifiants Toujours actif

Identifiants partagés Comptes d’équipe, accès fournisseurs Inconnu

Les applications OAuth sont le plus grand angle mort. Une personne qui s’est connectée à Notion avec son compte Google pendant qu’elle était en poste conservera indéfiniment l’accès à cet espace Notion après la désactivation de son compte Google, si ce compte a été désactivé sans que la session ou le jeton Notion n’aient été explicitement révoqués.

Plus important encore : l’IT ignore souvent quelles applications relèvent de quelle catégorie. L’étape de découverte manque à la plupart des checklists de départ.

La fenêtre d’exposition

Même avec les bons processus, le calendrier compte. Il y a toujours un écart entre le dernier jour d’une personne et le moment où le retrait complet des accès est confirmé. En pratique, cet écart se mesure souvent en jours ou en semaines, pas en heures.

Les risques qui vivent dans cette fenêtre ne sont pas théoriques. Une personne partie qui garde un accès résiduel au CRM, au code source ou aux systèmes financiers représente une exposition réelle. La plupart des incidents de sécurité attribués à d’anciens collaborateurs ne relèvent pas d’attaques sophistiquées. Ils relèvent de quelqu’un qui se sert d’identifiants jamais révoqués.

Cette fenêtre a trois causes :

Des chaînes de tickets manuelles. Un départ déclenche une série de tâches réparties entre plusieurs équipes. Chaque passage de relais est une occasion de retard ou d’oubli.
Un inventaire incomplet. Vous ne pouvez révoquer l’accès qu’aux outils dont vous savez qu’ils étaient utilisés. Le shadow IT rend l’inventaire toujours incomplet.
Aucune étape de vérification. La plupart des processus de départ n’ont aucun mécanisme confirmant que tous les accès ont été retirés, seulement que le ticket a été clos.

Ce que couvre un départ traité complètement

Un départ traité complètement couvre plus de terrain que la plupart des checklists IT. Par ordre de priorité approximatif :

Déprovisionnement dans l’IdP. Désactivez le compte SSO et déclenchez le déprovisionnement SCIM pour toutes les applications fédérées. Cela devrait se faire automatiquement, idéalement à partir d’un événement du SIRH.

Révocation des jetons OAuth. Révoquez toutes les autorisations OAuth accordées par la personne, sur l’ensemble des applications connectées. Cela suppose une découverte préalable : il faut savoir quelles connexions OAuth existent avant de pouvoir les révoquer.

Rotation des clés d’API. Identifiez puis renouvelez ou révoquez toutes les clés d’API que la personne a générées dans les outils où elle avait un accès administrateur ou développeur.

Suppression des SaaS en connexion directe. Supprimez les comptes dans les outils qui ne sont pas gérés en SSO. Cela suppose de savoir à quels outils la personne avait accès indépendamment de l’IdP.

Déprovisionnement des agents IA. Suspendez ou réattribuez tous les agents IA que la personne a provisionnés, ou qui fonctionnaient avec ses identifiants.

Rotation des identifiants partagés. Tout mot de passe partagé ou compte de service auquel la personne avait accès doit être renouvelé. Cette étape saute souvent, faute d’un inventaire propre des identifiants partagés.

Audit de vérification. Un contrôle final confirmant que la personne n’apparaît plus comme utilisateur actif dans aucun système. C’est cette étape qui fait passer le départ du statut de processus à celui de contrôle.

La complication des agents IA

La plupart des checklists de départ ont été écrites avant que les agents IA ne deviennent une composante ordinaire du travail. Elles n’ont pas été mises à jour.

Quand une personne met en place un agent IA, elle le provisionne en général avec ses propres identifiants : sa clé d’API, son jeton OAuth, son compte de service. L’agent agit en son nom. Quand elle part, l’agent ne s’arrête pas de lui-même. Tant que personne ne sait qu’il existe et ne le déprovisionne explicitement, il continue de tourner avec un accès censé avoir expiré.

Ce n’est pas une hypothèse d’école. Les équipes commerciales font tourner des agents sur les données du CRM. Les ingénieurs en montent avec accès aux dépôts. Les équipes financières en branchent sur les systèmes de facturation. Chacun de ces agents est un chemin d’accès persistant que le ticket de départ standard ne rattrapera pas.

Le correctif suppose de faire des agents des entités de plein droit dans votre modèle d’accès : des identités enregistrées, avec un propriétaire, plutôt que des clés d’API anonymes. Au départ du propriétaire, l’agent doit être suspendu automatiquement, ou réattribué avec une étape de revue explicite.

Du manuel au systématique

Si la sécurité des départs échoue, c’est parce qu’elle repose sur des humains qui doivent exécuter correctement une checklist, sous contrainte de temps, avec des informations incomplètes, à chaque départ. Ce modèle ne passe pas à l’échelle et ne produit pas de résultats constants.

Un traitement systématique relie le retrait des accès directement à l’événement RH. Dès qu’un départ est enregistré dans le SIRH, le flux de retrait démarre automatiquement. Il n’attend pas de ticket. Il n’exige de personne qu’il se souvienne de la checklist. Il se déclenche à chaque départ, y compris ceux du vendredi à 17 heures.

Le problème d’inventaire, cette étape de découverte que la plupart des checklists sautent, est la partie la plus difficile à automatiser. On ne retire pas l’accès à des outils dont on ignore l’existence. Cela demande une découverte SaaS continue, qui court en amont de l’événement de départ, et non un audit manuel déclenché par lui.