Imaginons le scénario suivant : vous êtes le responsable de la gestion des accès dans une grande entreprise et on vient vous trouver en urgence : un employé menace de supprimer des données et/ou de porter atteinte à l’intégrité du SI, il faut révoquer son compte immédiatement dans AAD. Est-ce qu’il est possible de suspendre tous ses accès instantanément ? On serait tenté de répondre à l’affirmative, mais ce n’est pas le cas pour toutes les applications. Même en révoquant les sessions d’un utilisateur, ce dernier peut encore causer des dommages dans l’entreprise pendant un court laps de temps. Pour comprendre comment, il convient d’abord de comprendre comment fonctionnent les jetons d’authentification dans AAD.
Comment fonctionnent les jetons d’authentification
Il existe plusieurs types de jetons, dont des jetons d’accès et des jetons d’actualisation. Le jeton d’accès vous est octroyé lorsque l’authentification au service auprès d’AAD s’est déroulé correctement, il a une validité d’environ une heure. Pendant cette heure, vous pouvez utiliser le service en ligne jusqu’à ce que le jeton expire ou que vous interrompiez votre session.
Le jeton d’actualisation est également émis lors d’une authentification AAD réussie. Lorsque le jeton d’accès expire, le jeton d’actualisation prend le relai et permet de réauthentifier l’utilisateur de manière totalement transparente pour lui. Azure AD réévalue alors l’autorisation puis, si l’utilisateur est toujours autorisé, un nouveau jeton d’accès est émis. L’utilisateur n’a donc pas besoin de se réauthentifier manuellement.
Ces deux types de jetons, d’accès et d’actualisation, fonctionne principalement avec des applications clientes lourdes.
Pour la plupart des des applications web, des jetons de session sont utilisés à la place.
Quand un utilisateur ouvre un navigateur et s’authentifie auprès d’une application par le biais d’AAD il reçoit deux jetons de sessions : un jeton de session AAD et un jeton de session de l’application. L’accès à l’application est régie par la session de l’application.
Révoquer un accès
Pour révoquer un accès c’est très simple, vous pouvez vous rendre dans le centre d’administration Azure AD (maintenant Microsoft Entra), rechercher un utilisateur, puis révoquer ses sessions.
Evidemment ici on ne parle que de la révocation des sessions, pour faire les choses proprement il faut également désactiver le compte dans PowerShell avec Connect-AzureAD :
Set-AzureADUser -ObjectId AdeleV@NomDuDomaine.com -AccountEnabled $false(Révoquer les sessions se fait de la manière suivante 🙂
Revoke-AzureADUserAllRefreshToken -ObjectId AdeleV@NomDuDomaine.comEnfin, on désactive les appareils de l’utilisateur :
Get-AzureADUserRegisteredDevice -ObjectId AdeleV@NomDuDomaine.com | Set-AzureADDevice -AccountEnabled $falseRemarquez que la commande PowerShell permettant de révoquer les sessions contient l’argument « AzureADUserAllRefreshToken« . Ce qui signifie que les jetons d’actualisation seront révoqués, mais pas les jetons d’accès.
Le problème
Il est impossible de révoquer un jeton d’accès.
Concrètement, cela signifie qu’un utilisateur venant de s’authentifier, et à qui on révoque l’accès, pourra continuer à accéder à certaines applications pendant une heure. L’utilisateur ne perdra l’accès que lorsque son jeton d’accès arrivera à expiration.
La situation est moins dramatique avec les applications web utilisant des jetons de session, dans ce cas l’application peut révoquer automatiquement les sessions actives de l’utilisateur si elle est configurée pour cela. Le délai de révocation dépend de la fréquence de synchronisation entre l’application et Azure AD.
Auparavant et pour mitiger le risque, une approche consistait à réduire la durée de vie du jeton d’accès, mais il s’est avéré que cette méthode pouvait nuire à l’expérience utilisateur sans toutefois éliminer les risques. Heureusement depuis quelques temps, une nouvelle solution bien plus efficace a vu le jour.
La solution (presque) parfaite : l’évaluation de l’accès continu
L’implémentation initiale de l’évaluation continue de l’accès se concentre sur Exchange, Teams et SharePoint Online.
Le principe phare de l’évaluation de l’accès continu (CAE) est d’avoir une conversation entre l’émetteur du jeton (AAD) et la ressource lui faisant confiance (l’application). Le fait d’avoir une conversation bidirectionnelle permet à l’application de voir quand les propriétés changent et d’en avertir AAD. De la même manière, AAD peut demander à l’application d’arrêter de prendre les jetons d’un utilisateur.
Le gros avantage est que la réponse se fait quasiment en temps réel (il faut tout de même compter jusqu’à 15mn le temps que l’information se soit propagée).
Ainsi, si un des évènements critiques ci-dessous survient, l’utilisateur perd en quelques minutes l’accès aux fichiers, aux mails, etc.
- Le compte d’un utilisateur est supprimé ou désactivé
- Le mot de passe d’un utilisateur a été modifié ou réinitialisé
- Le service Multifactor Authentication est activé pour l’utilisateur
- Un administrateur révoque explicitement tous les jetons d’actualisation d’un utilisateur
- Risque utilisateur élevé détecté par Azure AD Identity Protection
Un autre gros avantage est qu’en cas de changement d’emplacement réseau, les stratégies d’emplacement d’accès conditionnel seront appliquées en quasi-temps réel.
À noter que, comme le risque est évalué en temps réel, il n’y a plus besoin d’avoir une durée d’une heure sur les jetons d’accès. La durée de vie du jeton (que l’on peut alors appeler jeton CAE) est donc allongée jusqu’à 28 heures dans les sessions d’évaluation continue de l’accès.
En titre est indiqué que la solution est presque parfaite, pourquoi ? Parce que l’évaluation de l’accès continu ne répond pas à tous les scénarios, également parce que toutes les applications ne sont pas prises en charge. Les comptes invités, par exemple, ne sont pas concernés. Si un utilisateur est en session de co-création dans un document Office, son accès au document n’est pas immédiatement révoqué. Les clients OneDrive sur Mac et Windows ne sont pas pris en charge. Etc.
Il faudra prendre en compte toutes ces limitations pour ne pas développer un faux sentiment de sécurité.
Activer l’évaluation de l’accès continu
L’évaluation de l’accès continu nécessite une licence Azure AD Premium Plan 1 et est activé par défaut pour tous les locataires. On peut voir ci dessous que, lors de la création d’une stratégie d’accès conditionnel, je n’ai que la possibilité de désactiver l’évaluation de l’accès continu. Je ne vois pas dans quelle circonstance il serait utile de désactiver ça mais, au moins, Microsoft nous laisse le contrôle, alors on ne va pas se plaindre.
On peut se servir des journaux de connexion AAD pour identifier quelle connexion relève ou non du CAE. Dans l’exemple ci-dessous la connexion au portail Azure n’est pas prise en charge car il s’agit sur une application web avec des jetons de sessions. Il est également possible de se rendre dans les évènements de connexion et de filtrer tous les accès par jeton CAE.
Conclusion
Au final on pourrait se dire que ça ne sert à rien de savoir comment fonctionne l’évaluation de l’accès continu puisque c’est activé d’office, qu’il n’y a rien à configurer dessus et que tout le travail se fait tout seul. Mais la compréhension des rouages et surtout des limitations de la fonctionnalité permet de savoir à quoi s’en tenir et d’éviter les mauvaises surprises.
