Surveiller, examiner et corriger les utilisateurs à risque

  • 16 minutes

Examiner les risques

Identity Protection fournit aux organisations trois rapports qu’elles peuvent utiliser pour examiner les risques liés à l’identité dans leur environnement : utilisateurs à risque, connexions à risque et détections de risques. L’examen des événements est essentiel pour mieux comprendre et identifier les points faibles de votre stratégie de sécurité.

Les trois rapports permettent de télécharger des événements au format .CSV en vue d’analyses plus poussées en dehors du Portail Azure. Les rapports des utilisateurs à risque et des connexions risquées permettent de télécharger les 2,500 entrées les plus récentes, tandis que le rapport sur les détections de risques permet de télécharger les 5,000 enregistrements les plus récents.

Les organisations peuvent tirer parti des intégrations Microsoft Graph API pour agréger des données avec d'autres sources auxquelles elles ont accès en tant qu'organisation.

Vous trouverez les trois rapports dans le Centre d'administration Microsoft Entra, puis Identity, et enfin Protection – Identity Protection.

Chaque rapport démarre avec une liste de toutes les détections pour la période indiquée en haut du rapport. Chaque rapport permet l’ajout ou la suppression de colonnes en fonction des préférences de l’administrateur. Les administrateurs peuvent choisir de télécharger les données au format .CSV ou JSON. Les rapports peuvent être filtrés à l’aide des filtres situés dans la partie supérieure du rapport.

La sélection d'entrées individuelles permet des entrées supplémentaires en haut du rapport, comme la possibilité de confirmer une connexion comme étant compromise ou sécurisée, de confirmer un utilisateur comme étant compromis ou d'ignorer le risque de l'utilisateur.

La sélection d’entrées individuelles développe une fenêtre de détails sous les détections. L’affichage des détails permet aux administrateurs d’investiguer et d’effectuer des actions lors de chaque détection.

Capture d’écran du rapport Protection des identités montrant les connexions à risque et les détails.

Utilisateurs à risque

Les informations indiquées dans le rapport Utilisateurs à risque permettent aux administrateurs de trouver :

  • Quels sont les utilisateurs à risques ? Pour qui les risques ont-ils été corrigés ou éliminés ?
  • Détails sur les détections.
  • Historique de toutes les connexions à risque.
  • Historique des risques.

Les administrateurs peuvent ensuite choisir d’agir sur ces événements. Les élèves peuvent choisir de procéder de différentes façons :

  • Réinitialiser le mot de passe de l’utilisateur.
  • Confirmer la compromission de l’utilisateur.
  • Ignorer le risque lié à l’utilisateur.
  • Empêcher l’utilisateur de se connecter.
  • Effectuer d’autres examens au moyen d’Azure ATP.

Connexions risquées

Le rapport des connexions à risque contient des données filtrables correspondant aux 30 derniers jours (1 mois).

Les informations indiquées dans le rapport des connexions à risque permettent aux administrateurs de trouver :

  • Les connexions classées comme étant à risque, celles confirmées comme étant compromises, celles confirmées comme étant sécurisées, celles rejetées ou corrigées.
  • Les niveaux de risque en temps réel et agrégés associés aux tentatives de connexion.
  • Types de détections déclenchées.
  • Stratégies d’accès conditionnel appliquées.
  • Détails MFA.
  • Informations sur l'appareil.
  • Informations sur l’application.
  • Informations sur l’emplacement.

Les administrateurs peuvent ensuite choisir d’agir sur ces événements. Les administrateurs peuvent choisir d’effectuer les opérations suivantes :

  • Confirmer que la connexion est compromise.
  • Confirmer que la connexion est sécurisée.

Détections de risques

Le rapport des détections de risques contient des données filtrables correspondant aux 90 derniers jours (3 mois).

Les informations indiquées dans le rapport des détections de risques permettent aux administrateurs de trouver :

  • Des informations sur chaque détection de risques, y compris le type
  • Les autres risques déclenchés en même temps.
  • L’emplacement de la tentative de connexion.

Les administrateurs peuvent ensuite choisir de revenir au rapport des risques ou des connexions de l’utilisateur pour effectuer des actions en fonction des informations recueillies.

Le rapport de détection des risques fournit également un lien hypertexte vers la détection dans le portail Microsoft Defender pour les applications cloud (MDCA), où vous pouvez afficher des journaux et des alertes supplémentaires.

Remarque

Notre système détecte que l'événement à risque qui a contribué à la note de risque de l'utilisateur est un faux positif ou que le risque de l'utilisateur a été corrigé par l'application d'une politique, par exemple en effectuant une demande d'authentification multifacteur (MFA) ou une modification sécurisée du mot de passe. Par conséquent, notre système ignorera l’état de risque et le détail de risque « L’intelligence artificielle a confirmé que la connexion est sécurisée » apparaîtra et ne contribuera plus au risque de l’utilisateur.

Atténuer les risques et débloquer les utilisateurs

Une fois que vous avez fini votre investigation, vous pouvez prendre des mesures pour atténuer le risque ou débloquer les utilisateurs. Les organisations ont également la possibilité d’activer une correction automatisée en implémentant des stratégies de gestion des risques. Les organisations doivent tenter de traiter toutes les détections de risque auxquelles elles sont confrontées dans un laps de temps qui leur convient. Microsoft recommande de clore les événements dès que possible, car le temps compte en matière de risques.

Correction

Toutes les détections de risque actifs sont prises en compte dans le calcul d’une valeur appelée niveau de risque utilisateur. Le niveau de risque utilisateur est un indicateur (faible, moyen, élevé) de la probabilité qu’un compte ait été compromis. En tant qu’administrateur, vous souhaitez fermer toutes les détections de risques afin que les utilisateurs affectés ne soient plus exposés.

Certaines détections de risque peuvent être signalées par Identity Protection comme « Fermé (système) », car les événements n'étaient plus considérés comme risqués.

Pour corriger, les administrateurs disposent des options suivantes :

  • Correction automatique avec une stratégie de gestion des risques.
  • Réinitialisation manuelle du mot de passe.
  • Ignorer le risque lié à l’utilisateur.
  • Fermeture manuelle de détections de risques spécifiques.

Correction automatique avec une stratégie de gestion des risques

Si vous autorisez les utilisateurs à prendre des mesures correctives, avec l'authentification multifacteur (MFA) et la réinitialisation du mot de passe en libre-service (SSPR) dans vos politiques de gestion des risques, ils peuvent se débloquer eux-mêmes lorsqu'un risque est détecté. Ces détections sont alors considérées comme fermées. Les utilisateurs doivent avoir déjà été préalablement inscrits pour MFA et SSPR afin de pouvoir les utiliser quand un risque est détecté.

Certaines détections n'augmentent pas le risque au point de nécessiter une correction automatique de l'utilisateur. Toutefois, les administrateurs doivent tout de même évaluer ces détections. Les administrateurs jugent que des mesures supplémentaires sont nécessaires, comme bloquer l'accès à partir de certains emplacements ou abaisser le niveau de risque acceptable dans leurs stratégies.

Réinitialisation manuelle du mot de passe

Si exiger une réinitialisation du mot de passe à l’aide d’une stratégie de risque utilisateur n’est pas envisageable, les administrateurs peuvent fermer toutes les détections de risques pour un utilisateur en opérant une réinitialisation manuelle du mot de passe.

Pour réinitialiser un mot de passe pour leurs utilisateurs, les administrateurs disposent de deux options :

Générer un mot de passe temporaire : la génération d’un mot de passe temporaire vous permet de rétablir immédiatement la sécurité d’une identité. Cette méthode nécessite de contacter les utilisateurs affectés, car ceux-ci ont besoin de connaître le mot de passe temporaire. Étant donné que le mot de passe est temporaire, l’utilisateur est invité à le modifier lors de sa prochaine connexion.

Obliger l’utilisateur à réinitialiser le mot de passe : le fait de contraindre les utilisateurs à réinitialiser les mots de passe entraîne une récupération automatique qui ne nécessite aucun contact avec le support technique ou un administrateur. Cette méthode s'applique uniquement aux utilisateurs inscrits à MFA et SSPR. Pour les utilisateurs non inscrits, cette option n’est pas disponible.

Ignorer le risque lié à l’utilisateur

Si une réinitialisation de mot de passe n’est pas envisageable pour vous, par exemple parce que l’utilisateur a été supprimé, vous pouvez choisir d’ignorer les détections d’utilisateurs à risque.

Lorsque vous sélectionnez Ignorer le risque lié à l’utilisateur, tous les événements sont fermés et l’utilisateur concerné n’est plus à risque. Toutefois, étant donné que cette méthode n’affecte pas le mot de passe existant, elle ne rétablit pas la sécurité de l’identité associée.

Fermeture manuelle de détections de risques spécifiques

La fermeture manuelle de détections de risques spécifiques vous permet de réduire le niveau de risque utilisateur. En règle générale, les détections de risques sont fermées manuellement en réponse à une investigation associée, par exemple lorsqu’une conversation avec un utilisateur révèle qu’une détection de risques active n’est plus nécessaire.

Lorsque vous fermez des détections de risques manuellement, vous pouvez choisir d’exécuter l’une des actions ci-après pour modifier l’état d’une détection de risque :

  • Confirmer que l’utilisateur est compromis.
  • Ignorer le risque lié à l’utilisateur.
  • Confirmer que la connexion est sécurisée.
  • Confirmer que la connexion est compromise.

Déblocage des utilisateurs

Un administrateur choisit de bloquer une connexion en fonction de sa politique de gestion de risque ou d'investigations. Un bloc se produit en fonction de la connexion ou du risque utilisateur.

Déblocage basé sur le risque utilisateur

Pour débloquer un compte bloqué en raison d’un risque utilisateur, les administrateurs disposent des options suivantes :

  • Réinitialiser le mot de passe réinitialisé : vous pouvez réinitialiser le mot de passe de l’utilisateur.
  • Ignorer le risque lié à l’utilisateur : la stratégie de gestion du risque utilisateur bloque un utilisateur si le niveau de risque utilisateur configuré pour bloquer l’accès a été atteint. Vous pouvez réduire le niveau de risque d’un utilisateur en ignorant le risque utilisateur ou en fermant manuellement des détections de risques signalées.
  • Exclure l’utilisateur de la stratégie : si vous pensez que la configuration actuelle de votre stratégie d’authentification occasionne des problèmes pour certains utilisateurs, vous pouvez les en exclure.
  • Désactiver la stratégie : si vous pensez que votre configuration de la stratégie est à l’origine des problèmes pour tous vos utilisateurs, vous pouvez désactiver la stratégie.

Déblocage basé sur le risque de connexion

Pour débloquer un compte en fonction du risque de connexion, les administrateurs disposent des options suivantes :

  • Connexion à partir d’un emplacement ou d’un appareil connu : les connexions suspectes bloquées sont généralement des tentatives de connexion effectuées à partir d’un emplacement ou d’un appareil inconnu. Vos utilisateurs peuvent déterminer rapidement s’il s’agit bien de la raison du blocage en essayant de se connecter depuis un appareil ou un emplacement connu.
  • Exclure l’utilisateur de la stratégie : si vous pensez que la configuration actuelle de votre stratégie d’authentification occasionne des problèmes pour certains utilisateurs, vous pouvez les en exclure.
  • Désactiver la stratégie : si vous pensez que votre configuration de la stratégie est à l’origine des problèmes pour tous vos utilisateurs, vous pouvez désactiver la stratégie.

PowerShell en préversion

Le module Microsoft Graph PowerShell SDK Preview permet aux organisations de gérer les risques à l'aide de PowerShell. Les modules en préversion et l'exemple de code se trouvent dans le référentiel GitHub Azure.

Utiliser l’API Microsoft Graph

Microsoft Graph est le point de terminaison d'API unifiée de Microsoft et accueille les API de Microsoft Entra Identity Protection. Il existe trois API qui exposent des informations sur les connexions et les utilisateurs à risque : riskDetection, riskyUsers, and signIn.

riskDetection vous permet d’interroger Microsoft Graph pour obtenir la liste des détections de risque liées à l’utilisateur et à la connexion, ainsi que des informations associées sur la détection.

riskyUsersvous permet d’interroger Microsoft Graph pour obtenir des informations sur les utilisateurs que le service Identity Protection a identifiés en tant qu’utilisateurs à risque.

signIn vous permet d'interroger Microsoft Graph pour obtenir des informations sur des connexions Microsoft Entra ID avec des propriétés spécifiques relatives à l'état, au détail et au niveau de risque.

Cette section vous permet de vous familiariser avec la connexion à Microsoft Graph et l’interrogation de ces API. Pour obtenir une introduction détaillée, la documentation complète et un accès à l’Afficheur Graph, consultez le site Microsoft Graph (https://graph.microsoft.io/) ou la documentation de référence propre aux API riskDetection, riskyUsers, and signIn.

Se connecter à Microsoft Graph

Il existe quatre étapes pour accéder aux données Identity Protection par le biais de Microsoft Graph : récupérer votre nom de domaine, créer une inscription d’application, configurer des autorisations d’API et configurer des informations d’identification valides.

Récupérer votre nom de domaine

  1. Connectez-vous au centre d’administration Microsoft Entra.
  2. Accédez à Identité, puis ouvrez Paramètres, et sélectionnez Noms de domaine.
  3. Prenez note du domaine .onmicrosoft.com. Vous aurez besoin de ces informations dans une étape ultérieure.

Créer une nouvelle inscription d’application

  1. Dans le Centre d'administration de Microsoft Entra, accédez à Identité et applications, puis Inscriptions d'applications.

  2. Sélectionnez Nouvelle inscription.

  3. Dans la page Créer, effectuez les étapes suivantes :

    1. Dans la zone de texte Nom, entrez le nom de votre application (par exemple : API Microsoft Entra Risk Detection).
    2. Sous Types de comptes pris en charge, sélectionnez le type de compte qui utilisera les API.
    3. Sélectionnez Inscription.

  4. Copiez l’ID de l’application.

Configurez les autorisations d’API

  1. Depuis l’application que vous avez créée, puis sélectionnez Autorisations de l’API.

  2. Dans la page Autorisations configurées, dans la barre d’outils en haut, sélectionnez Ajouter une autorisation.

  3. Dans la page Ajouter un accès d’API, choisissez Sélectionner une API.

  4. Dans la page Sélectionner une API, sélectionnez Microsoft Graph, puis Sélectionner.

  5. Page Demander des autorisations d’API

    1. Sélectionnez Autorisations de l’application.
    2. Cochez les cases IdentityRiskEvent.Read.All et IdentityRiskyUser.Read.All.
    3. Sélectionnez Ajouter des autorisations.

  6. Sélectionner Accorder le consentement de l’administrateur pour le domaine.

Configurez un nom d'informations d'identification valide

  1. Depuis l’Application que vous avez créée, sélectionnez Certificats et secrets.

  2. Sous Secrets client, sélectionnez Nouveau secret client.

    1. Attribuez au secret client une Description et définissez le délai d’expiration en fonction des stratégies de votre organisation.

    2. Sélectionnez Ajouter.

      Notes

      Si vous perdez cette clé, vous devrez revenir à cette section et en créer une nouvelle. Gardez cette clé secrète : Toute personne la possédant peut accéder à vos données.

Authentifiez-vous auprès de Microsoft Graph et interrogez l’API de détections de risques Identity Protection

À ce stade, vous devez avoir :

  • le nom de domaine de votre client ;
  • L’ID de l’application (client)
  • Le secret ou le certificat du client

Pour l’authentification, envoyez une demande POST à https://login.microsoft.com , avec les paramètres suivants dans le corps :

  • grant_type : client_credentials
  • resource : https://graph.microsoft.com
  • client_id:
  • client_secret:

Si l’opération réussit, la requête retourne un jeton d’authentification. Pour appeler l’API, créez un en-tête avec le paramètre suivant :

Authorization`="<token_type> <access_token>"

Lors de l’authentification, le jeton retourné contient le type de jeton ainsi que le jeton d’accès.

Envoyez cet en-tête en tant que requête à l’URL d’API suivante : https://graph.microsoft.com/v1.0/identityProtection/riskDetections.

La réponse, en cas de réussite, consiste en une collection de détections de risques concernant l’identité ainsi que les données associées au format JSON OData, qui peuvent être analysées et gérées selon vos besoins.

Exemple

Cet exemple montre l’utilisation d’un secret partagé pour l’authentification. Dans un environnement de production, le stockage des secrets dans du code est généralement mal vu. Les organisations peuvent utiliser des identités gérées pour les ressources Azure pour sécuriser ces informations d’identification.

Voici un exemple de code pour l’authentification et l’appel de l’API par le biais de PowerShell. Il suffit d’ajouter l’ID client, la clé secrète, ainsi que le domaine du locataire.

    $ClientID      = "<your client ID here>"        # Should be a ~36 hex character string; insert your info here

    $ClientSecret  = "<your client secret here>"    # Should be a ~44 character string; insert your info here

    $tenantdomain  = "<your tenant domain here>"    # For example, contoso.onmicrosoft.com

    $loginURL      = "https://login.microsoft.com"

    $resource      = "https://graph.microsoft.com"

    $body          = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}

    $oauth        = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body

    Write-Output $oauth

    if ($oauth.access_token -ne $null) {

        $headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}

        $url = "https://graph.microsoft.com/v1.0/identityProtection/riskDetections"

        Write-Output $url

        $myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)

        foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {

            Write-Output $event

        }

    } else {

        Write-Host "ERROR: No Access Token"

    }

Récupérez toutes les détections de risque hors connexion (API riskDetection)

Avec les stratégies de risque de connexion d’Identity Protection, vous pouvez appliquer des conditions lorsque le risque est détecté en temps réel. Mais qu’en est-il des détections qui sont découvertes hors connexion ? Pour comprendre quelles détections ont eu lieu hors connexion et qui donc n’auraient pas déclenché la stratégie de connexion à risque, vous pouvez interroger l’API riskDetection.

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

Obtenir tous les utilisateurs qui ont réussi l’authentification MFA déclenchée par la stratégie de connexion risquée (API riskyUsers)

Pour comprendre la valeur que les stratégies Identity Protection basées sur les risques ont sur votre organisation, vous pouvez interroger tous les utilisateurs qui ont réussi une authentification MFA déclenchée par une stratégie de connexion à risque. Ces informations peuvent vous aider à comprendre quels utilisateurs Identity Protection a détectés par erreur comme présentant un risque et lesquels de vos utilisateurs légitimes effectuent des actions que l'IA considère comme risquées.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskDetail eq 'userPassedMFADrivenByRiskBasedPolicy'