Implémenter la gestion des sessions et l’évaluation continue de l’accès

  • 3 minutes

Dans les déploiements complexes, les organisations peuvent avoir besoin de limiter les sessions d’authentification. Certains scénarios peuvent inclure les éléments suivants :

  • L’accès aux ressources à partir d’un appareil non géré ou partagé.
  • L’accès à des informations sensibles depuis un réseau externe.
  • Priorité élevée ou utilisateurs exécutifs.
  • Des applications métier critiques.

Les contrôles d’accès conditionnel permettent de créer des stratégies qui ciblent des cas d’usage particuliers au sein de votre organisation, sans affecter tous les utilisateurs.

Avant de plonger dans les détails sur la façon de configurer la stratégie, examinons la configuration par défaut.

Fréquence de connexion de l’utilisateur

La fréquence de connexion définit la durée à l’issue de laquelle un utilisateur est invité à se reconnecter lorsqu’il tente d’accéder à une ressource.

La configuration par défaut de Microsoft Entra ID pour la fréquence de connexion utilisateur est une fenêtre dynamique de 90 jours. Demander des informations d’identification aux utilisateurs semble souvent une chose sensée à faire, mais celle-ci peut avoir l’effet inverse que celui prévu : les utilisateurs qui sont habitués à entrer leurs informations d’identification machinalement peuvent involontairement les fournir à une invite de demande d’informations d’identification malveillante.

Il peut paraître alarmant de ne pas demander à un utilisateur de se reconnecter, en réalité toute violation des stratégies informatiques révoquera la session. Certains exemples incluent une modification de mot de passe, un appareil non conforme ou une désactivation de compte. Vous pouvez aussi explicitement révoquer les sessions des utilisateurs avec PowerShell. La configuration par défaut de l’ID Microsoft Entra descend à « ne pas demander aux utilisateurs de fournir leurs informations d’identification si la posture de sécurité de leurs sessions n’a pas changé ».

Le paramètre de fréquence de connexion fonctionne avec les applications qui ont implémenté les protocoles OAUTH2 ou OIDC conformément aux standards. La plupart des applications pour Windows, Mac et mobile, y compris les applications web suivantes, sont conformes au paramètre.

  • Word, Excel, PowerPoint en ligne
  • OneNote en ligne
  • Office.com
  • Portail d’administration Microsoft 365
  • Échange en ligne
  • SharePoint et OneDrive
  • Client web Teams
  • Dynamics CRM en ligne
  • Portail Azure

Le paramètre de fréquence de connexion fonctionne également avec les applications SAML, à condition que celles-ci ne suppriment pas leurs propres cookies et qu’elles soient régulièrement redirigées vers Microsoft Entra ID pour l’authentification.

Fréquence de connexion des utilisateurs et authentification multifacteur

La fréquence de connexion ne s’appliquait qu’à l’authentification au premier facteur de l’authentification sur les appareils qui étaient joints à Microsoft Entra, avec jointure hybride Microsoft Entra et inscrits auprès de Microsoft Entra. Il n'y avait pas de moyen facile pour nos clients de renforcer l'authentification multifacteur (MFA) sur ces appareils. Conformément aux commentaires des clients, la fréquence de connexion s'appliquera également à l'authentification multifacteur.

Diagramme du processus d’authentification multifacteur avec fréquence de connexion.

Fréquence de connexion des utilisateurs et identités des appareils

Si vous avez des appareils joints à Microsoft Entra, à jointure hybride Microsoft Entra ou inscrits auprès de Microsoft Entra, quand un utilisateur déverrouille son appareil ou se connecte de façon interactive, cet événement satisfait également à la stratégie de fréquence de connexion. Dans les deux exemples suivants, la fréquence de connexion des utilisateurs est définie sur une heure :

Exemple 1 :

  • À 00:00, un utilisateur se connecte à son appareil Windows 10 joint à Microsoft Entra et commence à travailler sur un document stocké sur SharePoint Online.
  • L’utilisateur continue à travailler au même document sur son appareil pendant une heure.
  • À 01:00, l’utilisateur est invité à se reconnecter en fonction de la fréquence de connexion spécifiée dans la stratégie d’accès conditionnel configurée par son administrateur.

Exemple 2 :

  • À 00:00, un utilisateur se connecte à son appareil Windows 10 joint à Microsoft Entra et commence à travailler sur un document stocké sur SharePoint Online.
  • À 00:30, l’utilisateur se lève et fait une pause en bloquant son appareil.
  • À 00:45, l’utilisateur revient de sa pause et déverrouille l’appareil.
  • À 01:45, l’utilisateur est invité à se reconnecter en fonction de la fréquence de connexion spécifiée dans la stratégie d’accès conditionnel configurée par son administrateur, car la dernière connexion s’est faite à 00:45.

Persistance des sessions de navigation

Une session de navigateur persistante permet aux utilisateurs de rester connectés après la fermeture et la réouverture de la fenêtre du navigateur. L’ID Microsoft Entra par défaut pour la persistance de session de navigateur permet aux utilisateurs sur les appareils personnels de choisir s’il faut conserver la session en affichant un « Rester connecté ? » après une authentification réussie.

Vérification

Utilisez l’outil What-If (Scénarios) pour simuler une connexion de l’utilisateur vers l’application cible et d’autres conditions en fonction de la configuration de votre stratégie. Les contrôles de gestion de session d’authentification s’affichent dans le résultat de l’outil.

Capture d’écran des résultats de l’outil Conditional Access What If.

Déploiement de stratégie

Pour vous assurer que votre stratégie fonctionne comme prévu, la meilleure pratique recommandée consiste à la tester avant de la déployer en production. Dans l’idéal, utilisez un locataire de test pour vérifier si votre nouvelle stratégie fonctionne comme prévu.

Évaluation continue de l’accès (CAE)

L’expiration et l’actualisation des jetons sont un mécanisme standard du secteur. Lorsqu’une application cliente telle qu’Outlook se connecte à un service comme Exchange Online, les demandes d’API sont autorisées à l’aide de jetons d’accès OAuth 2.0. Par défaut, ces jetons d’accès sont valides pendant une heure. Quand ils expirent, le client est redirigé vers Microsoft Entra ID pour les actualiser. Cette période d’actualisation offre la possibilité de réévaluer les stratégies d’accès utilisateur. Par exemple, il est possible de choisir de ne pas actualiser le jeton en raison d’une stratégie d’accès conditionnel ou parce que l’utilisateur a été désactivé dans l’annuaire.

Cependant, il existe un décalage entre le changement des conditions pour un utilisateur et le moment où les modifications de stratégie sont appliquées. Une réponse en temps utile aux violations de stratégie ou à d’autres problèmes de sécurité nécessite vraiment une « conversation » entre l’émetteur du jeton et la partie de confiance (application compatible). Cette conversation bidirectionnelle nous offre deux capacités importantes. La partie de confiance peut voir quand les propriétés changent, comme l’emplacement réseau, et comment indiquer à l’émetteur du jeton. Et l’émetteur du jeton peut demander à la partie de confiance d’arrêter de respecter les jetons pour un utilisateur donné en raison d’une compromission ou d’une désactivation de compte ou d’autres soucis. Le mécanisme de cette conversation est l’évaluation continue de l’accès.

Avantages

L’évaluation continue de l’accès offre plusieurs avantages clés.

  • Démission d’utilisateur ou modification/réinitialisation du mot de passe : La révocation de session utilisateur sera appliquée en quasi-temps réel.
  • Changement d’emplacement réseau : les stratégies d’emplacement d’accès conditionnel seront appliquées en quasi-temps réel.
  • L’exportation de jetons vers une machine en dehors d’un réseau approuvé peut être évitée avec des stratégies d’emplacement d’accès conditionnel.

Flux du processus d’évaluation et de révocation

Diagramme du flux de processus lorsqu’un jeton d’accès est révoqué et qu’un client doit réverifier l’accès.

  1. Un client compatible avec l’évaluation continue de l’accès (CAE) présente à Microsoft Entra ID des informations d’identification ou un jeton d’actualisation, demandant un jeton d’accès pour une certaine ressource.
  2. Un jeton d’accès est retourné au client avec d’autres artefacts.
  3. Un administrateur révoque explicitement tous les jetons d’actualisation d’un utilisateur. Un événement de révocation va être envoyé au fournisseur de ressources à partir de Microsoft Entra ID.
  4. Un jeton d’accès est présenté au fournisseur de ressources. Le fournisseur de ressources évalue la validité du jeton et vérifie s’il existe un événement de révocation pour l’utilisateur. Le fournisseur de ressources utilise ces informations pour décider d’accorder ou non l’accès à la ressource.
  5. Dans le cas de ce diagramme, le fournisseur de ressources refuse l’accès et renvoie une contestation de revendication 401+ au client.
  6. Le client compatible avec l’EAC comprend la contestation de revendication 401+. Il contourne les caches et revient à l’étape 1, en renvoyant à Microsoft Entra ID son jeton d’actualisation avec la contestation de revendication. Microsoft Entra ID réévalue ensuite toutes les conditions et invite l’utilisateur à se réauthentifier dans ce cas.