Partager via


Identifier et corriger les risques à l’aide des API de protection des identités

Protection Microsoft Entra ID offre aux organisations des informations sur les risques et les méthodes basés sur l’identité pour examiner et corriger automatiquement ces risques. Ce tutoriel vous guide tout au long de l’utilisation des API ID Protection pour identifier les risques et configurer des flux de travail pour confirmer les compromissions ou activer la correction.

Dans ce tutoriel, vous allez apprendre à utiliser les API DE protection des ID pour :

  • Générez une connexion risquée.
  • Autoriser les utilisateurs disposant de connexions à risque à corriger le risque status avec une stratégie d’accès conditionnel qui nécessite l’authentification multifacteur (MFA).
  • Empêcher un utilisateur de se connecter à l’aide d’une stratégie d’accès conditionnel.
  • Ignorer un risque utilisateur.

Configuration requise

Pour suivre ce didacticiel, vérifiez que vous disposez des points suivants :

  • Un locataire Microsoft Entra avec une licence Microsoft Entra ID P1 ou P2.
  • L’accès à un client d’API comme Graph Explorer, connecté avec un compte qui a le rôle Administrateur de l’accès conditionnel.
  • Les autorisations déléguées suivantes : IdentityRiskEvent.Read.All, IdentityRiskyUser.ReadWrite.All, Policy.Read.All, Policy.ReadWrite.ConditionalAccess et User.ReadWrite.All.
  • Un compte d’utilisateur de test pour se connecter à une session anonyme afin de déclencher une détection de risque. Utilisez une session de navigation privée ou le navigateur Tor. Dans ce tutoriel, le surnom de messagerie de l’utilisateur de test est MyTestUser1.

Étape 1 : Déclencher une détection de risque

Dans la session de navigateur anonyme, connectez-vous au centre d’administration Microsoft Entra en tant que MyTestUser1.

Étape 2 : Répertorier les détections de risques

Lorsque MyTestUser1 s’est connecté au centre d’administration Microsoft Entra à l’aide du navigateur anonyme, un anonymizedIPAddress événement à risque a été détecté. Vous pouvez utiliser le $filter paramètre de requête pour obtenir uniquement les détections de risque associées au compte d’utilisateur MyTestUser1 . Le retour de l’événement peut prendre quelques minutes.

Demande

GET https://graph.microsoft.com/v1.0/identityProtection/riskDetections?$filter=userDisplayName eq 'MyTestUser1'

Réponse

HTTP/1.1 20O OK
Content-type: application/json

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#riskDetections",
  "value": [
    {
      "id": "d52a631815aaa527bf642b196715da5cf0f35b6879204ea5b5c99b21bd4c16f4",
      "requestId": "06f7fd18-b8f1-407d-86a3-f6cbe3a4be00",
      "correlationId": "2a38abff-5701-4073-a81e-fd3aac09cba3",
      "riskType": "anonymizedIPAddress",
      "riskEventType": "anonymizedIPAddress",
      "riskState": "atRisk",
      "riskLevel": "medium",
      "riskDetail": "none",
      "source": "IdentityProtection",
      "detectionTimingType": "realtime",
      "activity": "signin",
      "tokenIssuerType": "AzureAD",
      "ipAddress": "178.17.170.23",
      "activityDateTime": "2020-11-03T20:51:34.6245276Z",
      "detectedDateTime": "2020-11-03T20:51:34.6245276Z",
      "lastUpdatedDateTime": "2020-11-03T20:53:12.1984203Z",
      "userId": "4628e7df-dff3-407c-a08f-75f08c0806dc",
      "userDisplayName": "MyTestUser1",
      "userPrincipalName": "MyTestUser1@contoso.com",
      "additionalInfo": "[{\"Key\":\"userAgent\",\"Value\":\"Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0\"}]",
      "location": {
        "city": "Chisinau",
        "state": "Chisinau",
        "countryOrRegion": "MD",
        "geoCoordinates": {
          "latitude": 47.0269,
          "longitude": 28.8416
        }
      }
    }
  ]
}

Étape 3 : Créer une stratégie d’accès conditionnel

Les stratégies d’accès conditionnel permettent aux utilisateurs de corriger eux-mêmes lorsqu’un risque est détecté, ce qui leur permet d’accéder en toute sécurité aux ressources une fois l’invite de stratégie terminée. Dans cette étape, vous allez créer une stratégie d’accès conditionnel qui oblige les utilisateurs à se connecter à l’aide de l’authentification multifacteur si une détection à risque moyen ou élevé se produit.

Configurez l’authentification multi-facteurs.

Lorsque vous configurez un compte pour l’authentification multifacteur, choisissez la meilleure méthode d’authentification pour votre situation.

  1. Connectez-vous au site Maintenir votre compte sécurisé à l’aide du compte MyTestUser1 .
  2. Effectuez la procédure de configuration de l’authentification multifacteur à l’aide de la méthode appropriée pour votre situation, comme l’utilisation de l’application Microsoft Authenticator.

Créer la stratégie d'accès conditionnel

La stratégie d’accès conditionnel vous permet de définir des conditions pour identifier les niveaux de risque de connexion. Les niveaux de risque peuvent être low, medium, highou none. L’exemple suivant montre comment exiger l’authentification multifacteur pour les connexions avec des niveaux de risque moyen et élevé.

Demande

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies 
Content-type: application/json
 
{ 
  "displayName": "Policy for risky sign-in", 
  "state": "enabled", 
  "conditions": { 
    "signInRiskLevels": [ 
      "high", 
      "medium" 
    ], 
    "applications": { 
      "includeApplications": ["All"]
    }, 
    "users": { 
      "includeUsers": [ 
        "4628e7df-dff3-407c-a08f-75f08c0806dc" 
      ] 
    } 
  }, 
  "grantControls": { 
    "operator": "OR", 
    "builtInControls": [ 
      "mfa" 
    ] 
  } 
} 

Réponse

HTTP/1.1 201 Created
Content-type: application/json

{ 
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#identity/conditionalAccess/policies/$entity", 
  "id": "9ad78153-b1f8-4714-adc1-1445727678a8", 
  "displayName": "Policy for risky sign-in", 
  "createdDateTime": "2020-11-03T20:56:38.6210843Z", 
  "modifiedDateTime": null, 
  "state": "enabled", 
  "sessionControls": null, 
  "conditions": { 
    "signInRiskLevels": [ 
      "high", 
      "medium" 
    ], 
    "clientAppTypes": [  
      "all"  
    ], 
    "platforms": null, 
    "locations": null, 
    "applications": { 
      "includeApplications": [ 
        "All" 
      ], 
      "excludeApplications": [], 
      "includeUserActions": [] 
    }, 
    "users": { 
      "includeUsers": [ 
        "4628e7df-dff3-407c-a08f-75f08c0806dc" 
      ], 
      "excludeUsers": [], 
      "includeGroups": [], 
      "excludeGroups": [], 
      "includeRoles": [], 
      "excludeRoles": [] 
    } 
  }, 
  "grantControls": { 
    "operator": "OR", 
    "builtInControls": [ 
      "mfa" 
    ], 
    "customAuthenticationFactors": [], 
    "termsOfUse": [] 
  } 
} 

Étape 4 : Déclencher une autre connexion risquée, mais terminer l’authentification multifacteur

En vous connectant au navigateur anonyme, un risque est détecté, mais vous le corrigez en effectuant l’authentification multifacteur.

Connectez-vous à entra.microsoft.com à l’aide du compte MyTestUser1 et terminez le processus d’authentification multifacteur.

Étape 5 : Répertorier les détections de risques

Réexécutez la demande à l’étape 2 pour obtenir la dernière détection des risques pour le compte d’utilisateur MyTestUser1 . Étant donné que l’authentification multifacteur a été effectuée à l’étape 4, le riskState pour cet événement de connexion le plus récent est maintenant remediated.

[Facultatif] Empêcher l’utilisateur de se connecter

Si vous préférez bloquer les utilisateurs associés aux connexions à risque au lieu d’autoriser la correction automatique, créez une stratégie d’accès conditionnel. Cette stratégie empêche les utilisateurs de se connecter si une détection à risque moyen ou élevé se produit. La principale différence par rapport à la stratégie de l’étape 3 est que builtInControls est maintenant défini sur block.

Demande

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Content-type: application/json

{
  "displayName": "Policy for risky sign-in block access",
  "state": "enabled",
  "conditions": {
    "signInRiskLevels": [
      "high",
      "medium"
    ],
    "applications": {
      "includeApplications": ["All"]
    },
    "users": {
      "includeUsers": [
        "4628e7df-dff3-407c-a08f-75f08c0806dc"
      ]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "block"
    ]
  }
}

Réponse

HTTP/1.1 201 Created
Content-type: application/json

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#identity/conditionalAccess/policies/$entity",
  "id": "9ad78153-b1f8-4714-adc1-1445727678a8",
  "displayName": "Policy for risky sign-in block access",
  "createdDateTime": "2020-11-03T20:56:38.6210843Z",
  "modifiedDateTime": null,
  "state": "enabled",
  "sessionControls": null,
  "conditions": {
    "signInRiskLevels": [
      "high",
      "medium"
    ],
    "clientAppTypes": [ 
      "all" 
    ],
    "platforms": null,
    "locations": null,
    "applications": {
      "includeApplications": [
        "All"
      ],
      "excludeApplications": [],
      "includeUserActions": []
    },
    "users": {
      "includeUsers": [
        "4628e7df-dff3-407c-a08f-75f08c0806dc"
      ],
      "excludeUsers": [],
      "includeGroups": [],
      "excludeGroups": [],
      "includeRoles": [],
      "excludeRoles": []
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "block"
    ],
    "customAuthenticationFactors": [],
    "termsOfUse": []
  }
}

Une fois cette stratégie d’accès conditionnel en place, le compte MyTestUser1 ne peut plus se connecter en raison d’un niveau de risque de connexion moyen ou élevé.

Connexion bloquée

Étape 6 : Ignorer les utilisateurs à risque

Si vous pensez que l’utilisateur n’est pas exposé à un risque et que vous ne souhaitez pas appliquer de stratégie d’accès conditionnel, ignorez manuellement l’utilisateur à risque, comme indiqué dans la requête suivante. La requête retourne une 204 No Content réponse.

Demande

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/dismiss
Content-Type: application/json

{
  "userIds": [
    "4628e7df-dff3-407c-a08f-75f08c0806dc"
  ]
}

Après avoir ignoré l’utilisateur à risque, vous pouvez réexécuter la requête à l’étape 2 et remarquerez que le compte d’utilisateur MyTestUser1 a maintenant un niveau de risque et none un riskState de dismissed.

Étape 7 : nettoyer les ressources

Dans cette étape, supprimez les deux stratégies d’accès conditionnel que vous avez créées. La requête retourne une 204 No Content réponse.

DELETE https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/9ad78153-b1f8-4714-adc1-1445727678a8