Share via

Accès conditionnel : Protection des jetons (préversion)

  • Article

La protection des jetons (parfois appelée liaison de jeton dans le milieu) tente de réduire les attaques à l’aide du vol de jetons en s’assurant qu’un jeton est utilisable seulement à partir de l’appareil prévu. Lorsqu’un attaquant est en mesure de voler un jeton par piratage ou relecture, il peut emprunter l’identité de sa victime jusqu’à ce que le jeton expire ou soit révoqué. Le vol de jetons est considéré comme un événement relativement rare, mais les dommages peuvent être importants.

La protection par jeton crée une liaison sécurisée par chiffrement entre le jeton et l’appareil (clé secrète client) pour lequel il est émis. Sans la clé secrète client, le jeton lié est inutile. Lorsqu’un utilisateur inscrit un appareil Windows 10 ou plus récent dans Microsoft Entra ID, son identité principale est liée à l’appareil. Cela signifie : une stratégie peut s’assurer que seuls les jetons de session de connexion (ou d’actualisation) liés, également appelés jetons principaux d’actualisation (PRT) sont utilisés par les applications lors de la demande d’accès à une ressource.

Important

La protection du jeton est actuellement en préversion publique. Pour plus d’informations sur les préversions, consulter Termes du contrat de licence universel pour les services en ligne. Grâce à cette préversion, nous vous permettons de créer une stratégie d’accès conditionnel afin d’exiger une protection par jeton pour les jetons de connexion (jeton d’actualisation) pour des services spécifiques. Nous prenons en charge la protection des jetons de connexion dans l’accès conditionnel pour les applications de bureau accédant à Exchange Online et SharePoint Online sur les appareils Windows.

Important

Les modifications suivantes ont été apportées à la protection des jetons depuis la préversion publique initiale :

  • Sortie des journaux de connexion : la valeur de la chaîne utilisée dans « enforcedSessionControls » et « sessionControlsNotSatisfied » est passée de « Binding » à « SignInTokenProtection » fin juin 2023. Les requêtes sur les données du journal de connexion doivent être mises à jour pour refléter cette modification.

Remarque

Nous pouvons échanger les jetons de connexion et les jetons d’actualisation dans ce contenu. Les jetons d’accès ou les cookies Web ne sont actuellement pas pris en charge par cette préversion.

Screenshot showing a Conditional Access policy requiring token protection as the session control

Spécifications

Cette préversion prend en charge les configurations suivantes pour l’accès aux ressources avec des stratégies d’accès conditionnel de protection des jetons appliquées :

  • Les appareils Windows 10 ou version ultérieure qui sont joints à Microsoft Entra ou à Microsoft Entra hybride, ou bien enregistrés sur Microsoft Entra.
  • Synchronisation OneDrive client version 22.217 ou ultérieure
  • Client natif Teams version 1.6.00.1331 ou ultérieure
  • Power BI Desktop version 2.117.841.0 (mai 2023) ou version ultérieure
  • Visual Studio 2022 ou version ultérieure lors de l’utilisation de l’option de connexion « Authentification Windows broker »
  • Les clients Perpétuels Office ne sont pas pris en charge

Limitations connues

  • Les utilisateurs externes (Microsoft Entra B2B) ne sont pas pris en charge et ne doivent pas être inclus dans votre stratégie d’accès conditionnel.
  • Les applications suivantes ne prennent pas en charge la connexion à l’aide de flux de jetons protégés et les utilisateurs sont bloqués lors de l’accès à Exchange et SharePoint :
    • Modules PowerShell accédant aux étendues Exchange, SharePoint ou Microsoft Graph qui sont pris en charge par Exchange ou SharePoint
    • Extension PowerQuery pour Excel
    • Extensions à Visual Studio Code qui accèdent à Exchange ou SharePoint
    • La nouvelle préversion client de Teams 2.1 se bloque après la déconnexion en raison d’un bogue. Ce bogue doit être résolu dans une prochaine mise à jour du service.
  • Les appareils clients Windows suivants ne sont pas pris en charge :
    • Windows Server
    • Surface Hub
    • Systèmes basés sur Windows de salles de l'équipe Microsoft Teams (MTR)

Licences nécessaires

L’utilisation de cette fonctionnalité nécessite des licences Microsoft Entra ID P2. Pour trouver la licence adaptée à vos besoins, consultez Comparer les fonctionnalités en disponibilité générale de Microsoft Entra ID.

Remarque

L’application de la protection des jetons fait partie de Protection des ID Microsoft Entra et fera partie de la licence P2 à la disponibilité générale.

Déploiement

Pour les utilisateurs, le déploiement d’une stratégie d’accès conditionnel pour appliquer la protection par jeton est invisible lors de l’utilisation de plateformes clientes compatibles sur des appareils inscrits et des applications compatibles.

Voici quelques recommandations pour réduire le risque d’interruption utilisateur en raison d’une incompatibilité d’application ou d’appareil :

  • Commencez par un groupe pilote d’utilisateurs et développez-le au fil du temps.
  • Créez une stratégie d’accès conditionnel en mode rapport uniquement avant d’opter pour la protection par jeton.
  • Capturez à la fois les journaux de connexion interactifs et non interactifs.
  • Analysez ces journaux suffisamment longtemps pour couvrir l’utilisation normale de l’application.
  • Ajoutez des utilisateurs bien connus à une stratégie d’application.

Ce processus permet d’évaluer la compatibilité des applications et des clients de vos utilisateurs pour appliquer la protection des jetons.

Créer une stratégie d’accès conditionnel

Les utilisateurs qui exécutent des rôles spécialisés comme ceux décrits dans Niveaux de sécurité d’accès privilégié sont des cibles possibles pour cette fonctionnalité. Nous vous recommandons de commencer avec un petit sous-ensemble.

Screenshot of a configured Conditional Access policy and its components.

Les étapes suivantes aident à créer une stratégie d’accès conditionnel pour exiger une protection par jeton pour Exchange Online et SharePoint Online sur les appareils Windows.

  1. Connectez-vous au Centre d’administration de Microsoft Entra en tant qu’administrateur d’accès conditionnel.
  2. Accédez à Protection>Accès conditionnel.
  3. Sélectionnez Nouvelle stratégie.
  4. Donnez un nom à votre stratégie. Nous recommandons aux organisations de créer une norme explicite pour les noms de leurs stratégies.
  5. Sous Affectations, sélectionnez Utilisateurs ou identités de charge de travail.
    1. Sous Inclure, sélectionnez les utilisateurs ou les groupes qui testent cette stratégie.
    2. Sous Exclure, sélectionnez Utilisateurs et groupes, puis choisissez les comptes d’accès d’urgence ou de secours de votre organisation.
  6. Sous Ressources cibles>Applications cloud>Inclure>Sélectionner des applications

    1. Sous Sélectionner, sélectionnez les applications suivantes prises en charge par la préversion :

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online

      Avertissement

      Votre stratégie d’accès conditionnel doit être configurée uniquement pour ces applications. La sélection du groupe d’applications Office 365 peut entraîner des échecs inattendus. Il s’agit d’une exception à la règle générale selon laquelle le groupe d’applications Office 365 doit être sélectionné dans une stratégie d’accès conditionnel.

    2. Choisissez Sélectionner.

  7. Sous Conditions :
    1. Sous Plateformes d’appareils :
      1. Définissez Configurer sur Oui.
      2. Ajoutez>Sélectionner les plateformes d’appareils>Windows.
      3. Cliquez sur Terminé.
    2. Sous Applications clientes :
      1. Définissez Configurer sur Oui.

        Avertissement

        Ne pas configurer la condition des Applications clientes ou laisser le navigateur sélectionné peut entraîner le blocage des applications utilisant des MSAL.js, telles que Teams Web.

      2. Sous Clients d’authentification moderne, ne sélectionnez que Clients de bureau et d’applications mobiles. Laissez les autres éléments décochés.
      3. Sélectionnez Terminé.
  8. Sous Contrôle d’accès>Session, sélectionnez Exiger la protection des jetons pour les sessions de connexion, puis sélectionnez Sélectionner.
  9. Confirmez vos paramètres et définissez Activer la stratégie sur Rapport seul.
  10. Sélectionnez Créer pour créer votre stratégie.

Une fois que les administrateurs ont confirmé les paramètres à l’aide du mode État uniquement, ils peuvent modifier la position du bouton bascule Activer la stratégie de État uniquement en Activé.

Capturer les journaux et analyser

Surveillance de l’application de l’accès conditionnel de la protection des jetons avant et après application.

Journaux d’activité de connexion

Utilisez le journal de connexion Microsoft Entra pour vérifier le résultat d’une stratégie d’application de protection des jetons en mode rapport uniquement ou en mode activé.

  1. Connectez-vous au Centre d’administration de Microsoft Entra en tant qu’administrateur d’accès conditionnel.
  2. Accédez à Identité>Surveillance et intégrité>Journaux d’activité de connexion.
  3. Sélectionnez une demande spécifique pour déterminer si la stratégie est appliquée ou non.
  4. Accédez au volet Accès conditionnel ou Rapport uniquement en fonction de son état, puis sélectionnez le nom de votre stratégie nécessitant une protection par jeton.
  5. Sous Contrôles de session, vérifiez si les exigences de la stratégie sont satisfaites ou non.

Screenshot showing an example of a policy not being satisfied.

Log Analytics

Vous pouvez également utiliser Log Analytics pour interroger les journaux de connexion (interactifs ou non) pour les demandes bloquées en raison de l’échec de l’application de la protection des jetons.

Voici un exemple de requête Log Analytics qui effectue une recherche dans les journaux de connexion non interactifs des sept derniers jours, mettant en évidence les demandes bloquées ou autorisées par l’application. Ces requêtes ne sont que des exemples et peuvent être modifiées.

Remarque

Sortie des journaux de connexion : la valeur de la chaîne utilisée dans « enforcedSessionControls » et « sessionControlsNotSatisfied » est passée de « Binding » à « SignInTokenProtection » fin juin 2023. Les requêtes sur les données du journal de connexion doivent être mises à jour pour refléter cette modification. Les exemples couvrent les deux valeurs pour inclure des données historiques.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrinicpalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc

Le résultat de la requête précédente doit être similaire à la capture d’écran suivante :

Screenshot showing example results of a Log Analytics query looking for token protection policies

L’exemple de requête suivant examine le journal de connexion non interactif des sept derniers jours, mettant en évidence les demandes bloquées et autorisées par l’utilisateur.

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc

Étapes suivantes