Disabled Account, Active Session

La procédure de révocation d’accès s’arrête à la désactivation du compte dans le fournisseur d’identité. Or la désactivation empêche les nouvelles authentifications ; elle n’éteint pas ce qui existe déjà : sessions ouvertes, jetons de rafraîchissement, cookies persistants, sessions d’accès distant, clés d’API, identifiants mémorisés par des applications qui valident leurs jetons localement.

C’est structurel : le modèle mental « compte désactivé = accès coupé » date de l’authentification interactive, où chaque action revalidait le compte. Les architectures modernes reposent sur des jetons dont la durée de vie est indépendante de l’état du compte, et chaque application gère ses propres sessions selon ses propres règles. La révocation réelle est donc une opération multi-systèmes — et la procédure n’en décrit qu’une étape, celle qui se voit dans la console.

En incident, « le compte a été désactivé » est souvent la mesure de confinement annoncée. Si les sessions survivent, le confinement est déclaratif — et c’est pire qu’une absence de mesure, pour trois raisons :

• l’équipe cesse de surveiller un compte considéré comme neutralisé, pendant que l’attaquant continue de l’utiliser via ses jetons ;
• l’activité résiduelle du compte est mal interprétée : une trace « activité d’un compte désactivé » est classée comme incohérence de journalisation plutôt que comme le signal de haute qualité qu’elle est ;
• la chronologie de l’incident devient fausse : des actions post-confinement sont attribuées à d’autres vecteurs, et l’investigation cherche une seconde porte d’entrée qui n’existe pas.

La fenêtre entre la désactivation et l’expiration réelle des jetons se compte en heures, parfois en jours, selon les paramètres — largement assez pour exfiltrer ou poser une persistance propre.

Le test direct est le plus fiable, en environnement contrôlé :

• ouvrir des sessions avec un compte de test — portail web, messagerie, accès distant, application métier ;
• désactiver le compte ;
• mesurer combien de temps chaque session reste fonctionnelle. Les résultats surprennent presque toujours, et donnent la durée réelle de votre fenêtre d’exposition.

Questions de procédure :

• la procédure de révocation (départ, compromission) liste-t-elle explicitement : révocation des jetons de rafraîchissement, invalidation des sessions par application, clés d’API, secrets d’intégration, appareils enregistrés ?
• connaissez-vous la durée de vie configurée de vos jetons, en particulier pour les comptes à privilèges ?
• quelles applications valident leurs jetons localement sans revérifier l’état du compte ? Ce sont les plus longues à expirer.

Écrire la procédure de révocation complète, ordonnée, et l’outiller :

• séquence type : désactivation, réinitialisation du secret, révocation explicite des sessions et jetons dans le fournisseur d’identité, révocation par application pour celles qui gèrent leurs propres sessions, rotation des clés d’API et secrets liés, retrait des appareils enregistrés ;
• raccourcir la durée de vie des jetons pour les comptes à privilèges : la fenêtre d’exposition résiduelle est un paramètre de configuration, pas une fatalité ;
• automatiser la séquence en un geste unique — un « bouton rouge » testé périodiquement. En crise, une liste de douze étapes manuelles ne sera pas déroulée complètement, surtout de nuit ;
• alerter sur toute activité d’un compte désactivé : c’est l’un des signaux au meilleur rapport bruit/valeur qui existe.

Repasser derrière chaque compte « neutralisé » depuis le début de l’incident :

• réinitialiser le secret, révoquer explicitement sessions et jetons, chercher les clés d’API et secrets applicatifs associés au compte ;
• vérifier ensuite dans les journaux qu’aucune activité du compte n’apparaît après la révocation — la vérification fait partie du confinement, pas de l’audit d’après ;
• surveiller nominativement les comptes désactivés pendant toute la durée de l’incident : toute activité postérieure est un signal exploitable immédiatement, pas un artefact ;
• étendre aux persistances liées à l’identité que le compte a pu créer : appareils enregistrés, délégations, redirections de messagerie, consentements applicatifs — la révocation du compte ne les emporte pas.