Protection des jetons dans l'accès conditionnel : ce qu'elle couvre vraiment
Le vol de jetons est devenu l'un des moyens privilégiés pour contourner la MFA. La protection des jetons, proposée comme contrôle de session dans l'accès conditionnel, promet de rendre un jeton volé inutilisable sur un autre appareil. La promesse est réelle, mais son périmètre est plus étroit que ce que beaucoup imaginent.
Le principe de la liaison des jetons
Lorsqu'un appareil Windows est joint ou inscrit à Entra ID, il dispose d'une clé cryptographique propre, protégée si possible par la puce TPM. La protection des jetons s'appuie sur cette clé : les jetons de session émis pour les applications concernées sont liés à l'appareil, et leur utilisation exige une preuve de possession de la clé. Un attaquant qui exfiltre le jeton depuis le poste ne peut donc pas le rejouer depuis sa propre machine.
Dans l'accès conditionnel, cela prend la forme d'un contrôle de session, « Exiger la protection des jetons pour les sessions de connexion ». Lorsque la stratégie s'applique, Entra ID n'accepte que des sessions liées à l'appareil ; les clients incapables de fournir cette liaison sont bloqués.
Ce que la fonctionnalité couvre, et ce qu'elle ne couvre pas
C'est le point que nous voyons le plus souvent mal compris. La protection des jetons ne protège pas « toutes les sessions ». Son périmètre dépend de trois dimensions :
- Les plateformes : la prise en charge a d'abord porté sur Windows (appareils joints, joints hybrides ou inscrits), d'autres plateformes étant ajoutées progressivement.
- Les clients : ce sont principalement les applications de bureau natives (Outlook, Teams, OneDrive, clients Office) qui savent présenter des jetons liés. Les sessions de navigateur ne sont, à ce jour, pas couvertes de la même manière.
- Les ressources : seules certaines ressources sont prises en charge, typiquement Exchange Online, SharePoint Online et Teams.
Les listes de plateformes, de clients et de ressources compatibles évoluent régulièrement, de même que les conditions de licence. Vérifiez l'état actuel dans la documentation et dans votre locataire avant de concevoir la stratégie.
À ne pas confondre. La protection des jetons ne neutralise pas le vol de cookies de navigateur par un kit d'hameçonnage AiTM. Pour ce scénario, la parade reste la MFA résistante au hameçonnage et l'exigence d'un appareil conforme.
Concevoir une stratégie qui ne bloque pas tout
Comme tout client non compatible est bloqué, la stratégie doit être ciblée précisément. Une construction prudente ressemble à ceci :
- Utilisateurs : un groupe pilote, puis les populations à risque (administrateurs, direction), en excluant les comptes d'urgence.
- Ressources : uniquement les applications prises en charge, sélectionnées explicitement.
- Conditions : la plateforme Windows uniquement, et les clients « applications mobiles et clients de bureau », afin de ne pas toucher aux navigateurs.
- Contrôle de session : exiger la protection des jetons.
Commencer en mode rapport uniquement
Le mode rapport uniquement est ici indispensable. Pendant plusieurs semaines, il permet d'observer dans les journaux de connexion le résultat qu'aurait produit la stratégie, ainsi que le statut de protection des jetons pour chaque session. On repère ainsi :
- les postes dont l'état d'inscription ne permet pas la liaison ;
- les versions de clients trop anciennes ;
- les usages inattendus : outils tiers, scripts, applications métier qui accèdent aux mêmes ressources ;
- les environnements partagés ou virtualisés, où la liaison peut se comporter différemment.
Ce n'est qu'une fois ces cas traités ou exclus de manière documentée que la stratégie peut passer en mode actif, d'abord pour le pilote, puis par vagues.
Une brique parmi d'autres
La protection des jetons s'inscrit dans un ensemble : MFA résistante au hameçonnage pour réduire le vol initial, appareil conforme exigé pour les ressources sensibles, évaluation continue de l'accès pour accélérer la révocation, et détections d'Entra ID Protection pour repérer les jetons anormaux. Isolée, elle couvre un scénario précis, celui du jeton exfiltré d'un poste Windows et rejoué ailleurs. C'est un scénario réel, notamment après l'exécution d'un logiciel malveillant voleur d'informations, mais ce n'est pas le seul.
Ce qu'un audit vérifie
- L'existence d'une stratégie de protection des jetons et son mode (rapport uniquement ou actif).
- Le ciblage : utilisateurs, ressources, plateformes et types de clients.
- L'exclusion des comptes d'urgence et la justification des autres exclusions.
- L'analyse des journaux de connexion en mode rapport avant activation.
- La cohérence avec les autres contrôles : appareil conforme, force d'authentification, évaluation continue de l'accès.