Opérations de sécurité Microsoft Entra pour les comptes d’utilisateur
L’identité de l’utilisateur est l’un des aspects les plus importants de la protection de votre organisation et de vos données. Cet article fournit des conseils pour la surveillance de la création, de la suppression et de l’utilisation de comptes. La première partie explique comment surveiller la création et la suppression de comptes inhabituels. La deuxième partie explique comment surveiller l’utilisation inhabituelle des comptes.
Si vous n’avez pas encore pris connaissance de la vue d’ensemble des opérations de sécurité Microsoft Entra, nous vous recommandons de le faire avant de continuer.
Cet article couvre les comptes d’utilisateur généraux. Pour les comptes privilégiés, consultez Opérations de sécurité – comptes privilégiés.
Définir une ligne de base
Pour découvrir un comportement anormal, vous devez d’abord définir le comportement normal et attendu. Le fait de définir le comportement attendu pour votre organisation vous aide à déterminer quand un comportement inattendu se produit. La définition permet également de réduire le niveau de bruit de faux positifs lors de la surveillance et de la génération d’alertes.
Une fois que vous avez défini ce que vous attendez, vous effectuez une analyse de ligne de base pour valider vos attentes. Grâce à ces informations, vous pouvez surveiller les journaux pour détecter tout ce qui sort des tolérances que vous avez définies.
Utilisez les journaux d’audit Microsoft Entra, les journaux de connexion Microsoft Entra et les attributs d’annuaire comme sources de données pour les comptes créés en dehors des processus normaux. Voici quelques suggestions pour vous aider à réfléchir et à définir ce qui est normal pour votre organisation.
Création de compte d’utilisateur : évaluez les éléments suivants :
Stratégie et principes pour les outils et les processus utilisés pour créer et gérer des comptes d’utilisateur. Par exemple, il s’agit d’attributs standard, de formats appliqués aux attributs de compte d’utilisateur.
Sources approuvées pour la création de comptes. Par exemple, les données peuvent provenir d’Active Directory (AD), de Microsoft Entra ID ou de systèmes RH comme Workday.
Stratégie d’alerte pour les comptes créés en dehors des sources approuvées. Existe-t-il une liste contrôlée d’organisations avec lesquelles votre organisation collabore ?
Approvisionnement des comptes invités et des paramètres d’alerte pour les comptes créés en dehors de la gestion des droits d’utilisation ou d’autres processus normaux.
Paramètres de stratégie et d’alerte pour les comptes créés, modifiés ou désactivés par un compte qui n’est pas celui d’un administrateur d’utilisateurs approuvé.
Stratégie de surveillance et d’alerte pour les comptes qui n’ont pas d’attributs standard, tels que l’ID d’employé ou qui ne suivent pas les conventions de nommage organisationnelles.
Stratégie, principes et processus pour la suppression et la rétention des comptes.
Comptes d’utilisateur locaux : évaluez les éléments suivants pour les comptes synchronisés avec Microsoft Entra Connect :
Les forêts, les domaines et les unités d’organisation (UO) dans l’étendue de la synchronisation. Qui sont les administrateurs autorisés qui peuvent modifier ces paramètres et à quelle fréquence l’étendue est-elle vérifiée ?
Les types de comptes synchronisés. Par exemple, comptes d’utilisateur et/ou comptes de service.
Le processus de création de comptes privilégiés locaux et la manière dont la synchronisation de ce type de compte est contrôlée.
Le processus de création de comptes d’utilisateur locaux et la manière dont la synchronisation de ce type de compte est managée.
Pour plus d’informations sur la sécurisation et la surveillance des comptes locaux, consultez Protection de Microsoft 365 contre les attaques locales.
Comptes d’utilisateur cloud : évaluez les éléments suivants :
Le processus de provisionnement et de gestion des comptes cloud directement dans Microsoft Entra ID.
Le processus permettant de déterminer les types d’utilisateurs provisionnés en tant que comptes cloud Microsoft Entra. Par exemple, n’autorisez-vous que les comptes privilégiés ou autorisez-vous également les comptes d’utilisateurs ?
Le processus de création et de maintien d’une liste de personnes et/ou de processus de confiance censés créer et gérer les comptes d’utilisateurs du cloud.
Le processus pour créer et maintenir une stratégie d’alerte pour les comptes basés sur le cloud non approuvés.
Emplacement des fichiers
Les fichiers journaux que vous pouvez utiliser pour l’investigation et la supervision sont les suivants :
À partir du portail Azure, vous pouvez afficher les journaux d’audit Microsoft Entra et les télécharger sous forme de fichiers CSV (valeurs séparées par des virgules) ou JSON (JavaScript Object Notation). Le portail Azure propose plusieurs façons d’intégrer les journaux Microsoft Entra à d’autres outils qui permettent une plus grande automatisation de la surveillance et des alertes :
Microsoft Sentinel : permet une analytique de sécurité intelligente au niveau de l’entreprise en fournissant des fonctionnalités d’informations de sécurité et gestion d’événements (SIEM, Security Information and Event Management).
Règles Sigma - Sigma est un standard ouvert évolutif d’écriture de règles et de modèles que les outils de gestion automatisés peuvent utiliser pour analyser les fichiers journaux. S’il existe des modèles Sigma pour nos critères de recherche recommandés, nous avons ajouté un lien vers le dépôt Sigma. Les modèles Sigma ne sont pas écrits, testés et gérés par Microsoft. À la place, le dépôt et les modèles sont créés et collectés par la communauté mondiale de la sécurité informatique.
Azure Monitor – Permet de créer des alertes et supervisions automatisées de diverses conditions. Peut créer ou utiliser des classeurs pour combiner des données provenant de différentes sources.
Azure Event Hubs intégré à un SIEM : les journaux Microsoft Entra peuvent être intégrés à d’autres SIEM comme Splunk, ArcSight, QRadar et Sumo Logic via l’intégration d’Azure Event Hubs.
Microsoft Defender for Cloud Apps : permet de découvrir et de gérer les applications, de gouverner toutes les applications et ressources, et de vérifier la conformité des applications cloud.
Sécurisation des identités de charge de travail avec Protection des ID Microsoft Entra : permet de détecter les risques sur les identités de charge de travail sur le comportement de connexion et les indicateurs hors connexion de compromission.
La plupart des éléments qui font l’objet d’une surveillance et d’alertes sont déterminés par vos stratégies d’accès conditionnel. Vous pouvez utiliser le workbook Insights et rapports sur l’accès conditionnel pour examiner les effets d’une ou de plusieurs stratégies d’accès conditionnel sur vos connexions ainsi que leurs résultats, notamment l’état de l’appareil. Ce workbook vous permet de voir un récapitulatif et d’identifier les effets sur une période spécifique. Vous pouvez également vous en servir pour examiner les connexions d’un utilisateur spécifique.
Le reste de cet article comprend des recommandations concernant la supervision et les alertes, qui sont organisées par type de menace. Lorsqu’il existe des solutions prédéfinies spécifiques, nous en indiquons le lien ou donnons des exemples après le tableau. Sinon, vous pouvez créer des alertes à l’aide des outils précédents.
Création d’un compte
La création d’un compte anormal peut indiquer un problème de sécurité. Les comptes à courte durée de vie, les comptes qui ne suivent pas les normes d’affectation de noms et les comptes créés en dehors des processus normaux doivent être examinés.
Comptes à courte durée de vie
La création et la suppression de comptes en dehors des processus de gestion des identités normaux doivent être surveillées dans Microsoft Entra ID. Les comptes à courte durée de vie sont des comptes créés et supprimés dans une courte période. Ce type de création et de suppression rapide de compte peut signifier qu’un intervenant malveillant tente d’éviter la détection en créant des comptes, en les utilisant, puis en supprimant le compte.
Les modèles de compte à courte durée de vie peuvent indiquer que des personnes ou des processus non approuvés peuvent avoir le droit de créer et de supprimer des comptes qui se trouvent en dehors des processus et stratégies établis. Ce type de comportement supprime les marqueurs visibles du répertoire.
Si la trace de données pour la création et la suppression de comptes n’est pas découverte rapidement, les informations requises pour examiner un incident peuvent ne plus exister. Par exemple, les comptes peuvent être effacés, puis supprimés définitivement de la corbeille. Les journaux d’audit sont conservés pendant 30 jours. Toutefois, vous pouvez exporter vos journaux vers Azure Monitor ou une solution SIEM (Security information and Event Management) pour la rétention à plus long terme.
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Événements de création et de suppression de comptes dans un délai d’exécution rapproché. | Élevée | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite -et- Activité : supprimer un utilisateur État = réussite |
Recherchez les événements UPN (User Principal Name). Recherchez les comptes créés puis supprimés en moins de 24 heures. Modèle Microsoft Sentinel |
| Comptes créés et supprimés par des utilisateurs ou des processus non approuvés. | Moyenne | Journaux d'audit Microsoft Entra | Initié par (intervenant) : USER PRINCIPAL NAME -et- Activité : ajouter un utilisateur État = réussite and-or Activité : supprimer un utilisateur État = réussite |
Si les acteurs sont des utilisateurs non approuvés, effectuez la configuration nécessaire pour envoyer une alerte. Modèle Microsoft Sentinel |
| Comptes provenant de sources non approuvées. | Moyenne | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite Cible(s) = USER PRINCIPAL NAME |
Si l’entrée ne provient pas d’un domaine approuvé ou s’il s’agit d’un domaine bloqué connu, effectuez la configuration nécessaire pour envoyer une alerte. Modèle Microsoft Sentinel |
| Comptes affectés à un rôle privilégié. | Élevée | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite -et- Activité : supprimer un utilisateur État = réussite -et- Activité : ajout d’un membre au rôle État = réussite |
Si le compte est affecté à un rôle Microsoft Entra, à un rôle Azure ou à une appartenance à un groupe privilégié, générez une alerte et donnez la priorité à l’investigation. Modèle Microsoft Sentinel Règles Sigma |
Les comptes privilégiés et non privilégiés doivent être surveillés et alertés. Toutefois, étant donné que les comptes privilégiés disposent d’autorisations d’administration, ils doivent avoir une priorité plus élevée dans vos processus de surveillance, d’alerte et de réponse.
Comptes qui ne suivent pas les stratégies d’attribution de noms
Les comptes d’utilisateurs qui ne suivent pas les stratégies d’attribution de noms ont peut-être été créés en dehors des stratégies organisationnelles.
Une meilleure pratique consiste à avoir une stratégie d’attribution de noms pour les objets utilisateur. Le fait de disposer d’une stratégie d’attribution de noms facilite la gestion et aide à assurer la cohérence. La stratégie peut également vous aider à découvrir le moment où les utilisateurs ont été créés en dehors des processus approuvés. Un intervenant malveillant peut ne pas être conscient de vos normes d’affectation de noms et peut faciliter la détection d’un compte approvisionné en dehors de vos processus organisationnels.
Les organisations ont tendance à avoir des formats et des attributs spécifiques qui sont utilisés pour créer des comptes d’utilisateurs et/ou des comptes privilégiés. Par exemple :
UPN compte d’administrateur = ADM_firstname.lastname@tenant.onmicrosoft.com
UPN compte d’utilisateur = Firstname.Lastname@contoso.com
Bien souvent, les comptes d’utilisateurs ont un attribut qui identifie un utilisateur réel. Par exemple, EMPID = XXXNNN. Utilisez les suggestions suivantes pour définir la normalité au sein de votre organisation ainsi que pour établir une base de référence des entrées de journal quand les comptes ne respectent pas votre convention de nommage :
Comptes qui ne respectent pas la convention d’affectation de noms. Par exemple,
nnnnnnn@contoso.comcomparé àfirstname.lastname@contoso.com.Comptes dont les attributs standard ne sont pas renseignés ou qui ne sont pas au format approprié. Par exemple, vous ne disposez pas d’un ID d’employé valide.
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Comptes d’utilisateurs dont les attributs attendus n’ont pas été définis. | Faible | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite |
Recherchez les comptes avec vos attributs standard Null ou dans un format incorrect. Par exemple, EmployeeID Modèle Microsoft Sentinel |
| Comptes d’utilisateur créés à l’aide d’un format d’affectation de noms incorrect. | Faible | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite |
Recherchez les comptes avec un UPN qui ne suit pas votre stratégie d’affectation de noms. Modèle Microsoft Sentinel |
| Comptes privilégiés qui ne suivent pas la stratégie d’affectation de noms. | Élevé | Abonnement Azure | Répertorier les attribution de rôle Azure à l’aide du portail Azure – Azure RBAC | Listez les attributions de rôles pour les abonnements, et déclenchez une alerte quand le nom de connexion ne correspond pas au format de votre organisation. Par exemple, ADM_ en tant que préfixe. |
| Comptes privilégiés qui ne suivent pas la stratégie d’affectation de noms. | Élevée | Annuaire Microsoft Entra | Répertorier les attributions de rôles Microsoft Entra | Listez les attributions de rôles Microsoft Entra et signalez les rôles dont l’UPN ne correspond pas au format de votre organisation. Par exemple, ADM_ en tant que préfixe. |
Pour plus d’informations sur les analyses, consultez :
Pour les journaux d’audit Microsoft Entra - Analyser des données de texte dans les journaux Azure Monitor
Abonnements Azure - Lister les attributions de rôles Azure avec Azure PowerShell
Microsoft Entra ID - Répertorier les attributions de rôles Microsoft Entra
Comptes créés en dehors des processus normaux
Il est important de disposer de processus standard pour créer des utilisateurs et des comptes privilégiés afin de pouvoir contrôler en toute sécurité le cycle de vie des identités. Si les utilisateurs sont approvisionnés et déprovisionnés en dehors des processus établis, cela peut introduire des risques de sécurité. Le fonctionnement en dehors des processus établis peut également introduire des problèmes de gestion des identités. Les risques potentiels sont les suivants :
Les comptes d’utilisateurs et privilégiés peuvent ne pas être régis par des stratégies organisationnelles. Cela peut donner lieu à une extension de la surface d’attaque sur les comptes qui ne sont pas gérés correctement.
Cela devient plus difficile à détecter lorsque des intervenants malveillants créent des comptes à des fins malveillantes. En ayant des comptes valides créés en dehors des procédures établies, il devient plus difficile de détecter à quel moment les comptes sont créés ou les autorisations modifiées à des fins malveillantes.
Nous vous recommandons de créer des comptes d’utilisateur et privilégiés uniquement en suivant les stratégies de votre organisation. Par exemple, un compte doit être créé avec les normes d’affectation de noms correctes, les informations organisationnelles et dans le cadre de la gouvernance d’identité appropriée. Les organisations doivent avoir des contrôles rigoureux pour qui dispose des droits nécessaires pour créer, gérer et supprimer des identités. Les rôles permettant de créer ces comptes doivent être gérés de manière stricte et les droits ne doivent être disponibles qu’après avoir suivi un workflow établi pour approuver et obtenir ces autorisations.
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Comptes d’utilisateur créés et supprimés par des utilisateurs ou des processus non approuvés. | Moyenne | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite and-or- Activité : supprimer un utilisateur État = réussite -et- Initié par (intervenant) = USER PRINCIPAL NAME |
Alerte sur les comptes créés par des utilisateurs ou des processus non approuvés. Classer par ordre de priorité les comptes créés avec des privilèges renforcés. Modèle Microsoft Sentinel |
| Comptes d’utilisateur créés ou supprimés de sources non approuvées. | Moyenne | Journaux d'audit Microsoft Entra | Activité : ajouter un utilisateur État = réussite -ou- Activité : supprimer un utilisateur État = réussite -et- Cible(s) = USER PRINCIPAL NAME |
Alerte lorsque le domaine est un domaine non approuvé ou un domaine bloqué connu. |
Connexions inhabituelles
L’affichage des échecs pour l’authentification de l’utilisateur est normal. Toutefois, le fait de voir des modèles ou des blocs de défaillances peut indiquer qu’un événement se produit avec l’identité d’un utilisateur. Par exemple durant les attaques par pulvérisation de mots de passe ou par force brute, ou quand un compte d’utilisateur est compromis. Il est essentiel d’effectuer un monitoring et de déclencher des alertes quand des modèles émergent. Cela permet de garantir que vous pouvez protéger l’utilisateur et les données de votre organisation.
La réussite semble dire que tout va bien. Toutefois, cela peut signifier qu’un intervenant malveillant a réussi à accéder à un service. Le monitoring des connexions réussies vous permet de détecter les comptes d’utilisateurs qui obtiennent un accès mais qui ne sont pas des comptes d’utilisateurs autorisés. Les réussites de l’authentification utilisateur sont des entrées normales dans les journaux de connexion Microsoft Entra. Nous vous recommandons de surveiller et d’alerter pour détecter l’émergence de modèles. Cela permet de garantir que vous pouvez protéger les comptes d’utilisateur et les données de votre organisation.
Lors de la conception et de la mise en œuvre d’une stratégie de surveillance et d’alerte des journaux, tenez compte des outils disponibles dans le Portail Azure. La protection des ID Microsoft Entra vous permet d’automatiser la détection, la protection et la correction des risques basés sur l’identité. La protection des ID Microsoft Entra utilise des systèmes heuristiques et des systèmes d’apprentissage automatique intelligents pour détecter les risques, et affecter un score de risque aux utilisateurs et aux connexions. Les clients peuvent configurer des stratégies basées sur un niveau de risque pour autoriser ou refuser l’accès, ou permettre à l’utilisateur d’effectuer une correction automatique des risques de manière sécurisée. Les fonctionnalités de détection des risques de protection d’ID suivantes vous informent des niveaux de risque aujourd’hui :
| Ce qu’il faut surveiller | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Détection des risques de l’utilisateur des informations d’identification fuitées | Élevée | Journaux de détection de risque Microsoft Entra | UX : Informations d’identification fuitées API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection de risque utilisateur (veille des menaces Microsoft Entra) | Élevée | Journaux de détection de risque Microsoft Entra | UX : veille des menaces Microsoft Entra API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion à une adresse IP anonyme | Variable | Journaux de détection de risque Microsoft Entra | UX : adresse IP anonyme API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion de voyage atypique | Variable | Journaux de détection de risque Microsoft Entra | UX : voyage atypique API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Jeton anormal | Variable | Journaux de détection de risque Microsoft Entra | UX : jeton anormal API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection du risque de connexion par adresse IP liée à un programme malveillant | Variable | Journaux de détection de risque Microsoft Entra | UX : adresse IP liée à un programme malveillant API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection de risque de connexion à un navigateur suspect | Variable | Journaux de détection de risque Microsoft Entra | UX : navigateur suspect API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion avec des propriétés de connexion inhabituelles | Variable | Journaux de détection de risque Microsoft Entra | UX : propriétés de connexion inhabituelles API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion à une adresse IP malveillante | Variable | Journaux de détection de risque Microsoft Entra | UX : adresse IP malveillante API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion liés aux règles suspectes de manipulation de boîte de réception | Variable | Journaux de détection de risque Microsoft Entra | UX : règles suspectes de manipulation de boîte de réception API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion par pulvérisation de mots de passe | Élevée | Journaux de détection de risque Microsoft Entra | UX : pulvérisation de mots de passe API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion de voyage impossible | Variable | Journaux de détection de risque Microsoft Entra | UX : voyage impossible API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion du nouveau pays ou de la nouvelle région | Variable | Journaux de détection de risque Microsoft Entra | Expérience utilisateur : nouveau pays ou nouvelle région API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion liés à une activité depuis une adresse IP anonyme | Variable | Journaux de détection de risque Microsoft Entra | UX : activité depuis une adresse IP anonyme API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection des risques de connexion de transfert de boîte de réception suspect | Variable | Journaux de détection de risque Microsoft Entra | UX : transfert de boîte de réception suspect API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
| Détection de risque de connexion (veille des menaces Microsoft Entra) | Élevée | Journaux de détection de risque Microsoft Entra | UX : veille des menaces Microsoft Entra API : Consultez Type de ressource riskDetection - Microsoft Graph |
Voir Qu’est-ce que le risque ? Protection des ID Microsoft Entra Règles Sigma |
Pour plus d’informations, visitez Qu’est-ce que la Protection d’ID ?.
Ce que vous devez surveiller
Configurez l’analyse des données dans les journaux de connexion Microsoft Entra pour vérifier que les alertes sont émises et respectent les stratégies de sécurité de votre organisation. Quelques exemples :
Échecs d’authentification : comme tout être humain, nos mots de passe sont incorrects de temps en temps. Cependant, de nombreux échecs d’authentification peuvent indiquer qu’un intervenant malveillant tente d’obtenir un accès. Les attaques diffèrent en férocité mais peuvent aller de quelques tentatives par heure à un taux beaucoup plus élevé. Par exemple, la pulvérisation de mots de passe s’attaque normalement aux mots de passe les plus faciles sur de nombreux comptes, tandis que la force brute tente d’obtenir de nombreux mots de passe sur des comptes ciblés.
Authentifications interrompues : une interruption dans Microsoft Entra ID représente l’injection d’un processus pour répondre à l’authentification, par exemple durant l’application d’un contrôle dans une stratégie d’accès conditionnel. Il s’agit d’un événement normal qui peut se produire quand les applications ne sont pas configurées correctement. Toutefois, lorsque vous voyez de nombreuses interruptions pour un compte d’utilisateur, cela peut indiquer un problème avec ce compte.
- Par exemple, si vous avez filtré un utilisateur dans les journaux de connexion et que vous voyez un volume important d’états de connexion = interruption et accès conditionnel = échec. En allant plus loin, les détails de l’authentification peuvent indiquer que le mot de passe est correct, mais qu’une authentification forte est nécessaire. Cela peut signifier que l’utilisateur n’effectue pas l’authentification MFA (authentification multifacteur), ce qui peut indiquer que le mot de passe de l’utilisateur est compromis et que l’acteur malveillant ne parvient pas à effectuer l’authentification MFA.
Verrouillage intelligent : Microsoft Entra ID fournit un service de verrouillage intelligent qui introduit le concept d’emplacements familiers et non familiers dans le processus d’authentification. Un compte d’utilisateur visitant un emplacement familier peut s’authentifier avec succès, alors qu’un intervenant malveillant qui ne connaît pas le même emplacement est bloqué après plusieurs tentatives. Recherchez les comptes qui ont été verrouillés et effectuez des recherches plus poussées.
Changements d’adresses IP : il est normal de voir des utilisateurs provenant de différentes adresses IP. Toutefois, les états de Confiance Zéro n’approuvent jamais et vérifient toujours. L’observation d’un volume important d’adresses IP et d’échecs de connexion peut être un indicateur d’intrusion. Recherchez un modèle de nombreuses authentifications ayant échoué à partir de plusieurs adresses IP. Notez que les connexions de réseau privé virtuel (VPN) peuvent provoquer des faux positifs. Quels que soient les défis, nous vous recommandons de surveiller les modifications d’adresses IP et, si possible, d’utiliser Protection des ID Microsoft Entra pour détecter et atténuer automatiquement ces risques.
Emplacements : en général, vous vous attendez à ce qu’un compte d’utilisateur se trouve dans le même emplacement géographique. Vous vous attendez également à ce que les connexions proviennent de lieux où vous avez des employés ou des relations commerciales. Lorsque le compte d’utilisateur provient d’un autre emplacement international en moins de temps que celui qu’il faudrait pour se déplacer, cela peut indiquer que le compte d’utilisateur fait l’objet d’un abus. Notez que les VPN pouvant entraîner des faux positifs, nous vous recommandons de surveiller les comptes d’utilisateur qui se connectent à partir d’emplacements éloignés géographiquement et, si possible, d’utiliser Protection des ID Microsoft Entra pour détecter et atténuer automatiquement ces risques.
Pour cette zone à risque, nous vous recommandons d’effectuer un monitoring des comptes d’utilisateurs standard et des comptes privilégiés, tout en classant par ordre de priorité les investigations sur les comptes privilégiés. Les comptes privilégiés sont les comptes les plus importants d’un locataire Microsoft Entra. Pour des conseils spécifiques sur les comptes privilégiés, consultez Opérations de sécurité – comptes privilégiés.
Mode de détection
Utilisez Protection des ID Microsoft Entra, ainsi que les journaux de connexion Microsoft Entra pour vous aider à détecter les menaces indiquées par des caractéristiques de connexion inhabituelles. Pour plus d’informations, consulter l’article Qu’est-ce que la protection d’ID. Vous pouvez également répliquer les données vers Azure Monitor ou SIEM à des fins de surveillance et d’alerte. Pour définir la normalité dans votre environnement et établir une base de référence, déterminez :
Les paramètres que vous considérez comme normaux pour votre base d’utilisateurs.
Le nombre moyen d’essais d’un mot de passe sur une période donnée avant que l’utilisateur n’appelle le service d’assistance ou n’effectue une réinitialisation de mot de passe en libre-service.
Le nombre de tentatives infructueuses que vous souhaitez autoriser avant d’émettre une alerte, et si ce nombre sera différent pour les comptes d’utilisateurs et les comptes privilégiés.
Le nombre de tentatives MFA que vous souhaitez autoriser avant d’émettre une alerte, et si ce nombre sera différent pour les comptes d’utilisateurs et les comptes privilégiés.
Si l’authentification héritée est activée et votre feuille de route pour l’arrêt de l’utilisation.
Les adresses IP de sortie connues sont destinées à votre organisation.
Les régions/pays à partir desquels vos utilisateurs opèrent.
Si des groupes d’utilisateurs restent stationnaires au sein d’un emplacement réseau, d’un pays ou d’une région.
Identifiez tous les autres indicateurs pour les connexions inhabituelles spécifiques à votre organisation. Par exemple, les jours ou heures de la semaine ou de l’année, où votre organisation n’est pas en activité.
Une fois que vous avez défini l’étendue de la normalité propre aux comptes de votre environnement, examinez la liste suivante pour identifier les scénarios de monitoring et d’alertes ainsi que pour affiner les alertes.
Avez-vous besoin de surveiller et d’alerter lorsque Protection des ID Microsoft Entra est configurée ?
Existe-t-il des conditions plus strictes appliquées aux comptes privilégiés que vous pouvez utiliser pour surveiller et émettre des alertes ? Par exemple, la nécessité d’utiliser des comptes privilégiés uniquement à partir d’adresses IP approuvées.
Les lignes de base que vous définissez sont-elles trop agressives ? Si vous avez trop d’alertes, vous risquez de les ignorer ou de les manquer.
Configurez Protection d’ID pour vous assurer que la protection est en place et prend en charge vos stratégies de base de référence de sécurité. Par exemple, bloquer les utilisateurs si risque = élevé. Ce niveau de risque indique avec un degré élevé de confiance qu’un compte d’utilisateur est compromis. Pour plus d’informations sur la configuration des stratégies de risque de connexion et des stratégies de risque d’utilisateur, consultez Stratégies de protection d’ID.
Les éléments suivants sont listés par ordre d’importance en fonction de leur effet et de la gravité des entrées.
Monitoring des connexions d’utilisateur externe
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Utilisateurs s’authentifiant auprès d’autres locataires Microsoft Entra. | Faible | Journal de connexion Microsoft Entra | État = réussite ID de locataire de ressource != ID de locataire d’accueil |
Détecte le moment où un utilisateur a réussi à s’authentifier auprès d’un autre locataire Microsoft Entra avec une identité dans le locataire de votre organisation. Alerter si l’ID de locataire de ressource n’est pas égal à l’ID de locataire d’accueil Modèle Microsoft Sentinel Règles Sigma |
| L’état de l’utilisateur est passé d’invité à membre | Moyenne | Journaux d'audit Microsoft Entra | Activité : Mettre à jour l’utilisateur Catégorie : UserManagement UserType modifié d’invité à membre |
Monitorer et alerter en cas de changement de type d’utilisateur (d’invité à membre). Est-ce attendu ? Modèle Microsoft Sentinel Règles Sigma |
| Utilisateurs invités à un locataire par des inviteurs non approuvés | Moyenne | Journaux d'audit Microsoft Entra | Activité : Inviter un utilisateur externe Catégorie : UserManagement Lancé par (intervenant) : Nom d’utilisateur principal |
Monitorer et alerter si des intervenants non approuvés invitent des utilisateurs externes. Modèle Microsoft Sentinel Règles Sigma |
Surveillance des connexions inhabituelles ayant échoué
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Échecs de tentatives de connexion. | Moyen - si incident isolé Élevé - Si de nombreux comptes sont confrontés au même modèle ou à une adresse IP virtuelle. |
Journal de connexion Microsoft Entra | État = échec -et- Code d’erreur de connexion 50126 - Erreur de validation des informations d’identification en raison d’un nom d’utilisateur ou d’un mot de passe non valide. |
Définissez un seuil de base de référence, puis effectuez une supervision et ajustez-le pour l’adapter aux comportements de votre organisation et limiter la génération de fausses alertes. Modèle Microsoft Sentinel Règles Sigma |
| Événements de verrouillage intelligent. | Moyen - si incident isolé Élevé - Si de nombreux comptes sont confrontés au même modèle ou à une adresse IP virtuelle. |
Journal de connexion Microsoft Entra | État = échec -et- Code d’erreur de connexion = 50053 – IdsLocked |
Définissez un seuil de base de référence, puis effectuez une supervision et ajustez-le pour l’adapter aux comportements de votre organisation et limiter la génération de fausses alertes. Modèle Microsoft Sentinel Règles Sigma |
| Interruptions | Moyen - si incident isolé Élevé - Si de nombreux comptes sont confrontés au même modèle ou à une adresse IP virtuelle. |
Journal de connexion Microsoft Entra | 500121, échec de l’authentification lors d’une requête d’authentification forte. -ou- 50097, l’authentification de l’appareil est requise ou 50074, une authentification forte est requise. -ou- 50155, DeviceAuthenticationFailed -ou- 50158, ExternalSecurityChallenge - La vérification de la sécurité externe n’a pas abouti -ou- 53003 et Motif de l’échec = Bloqué par l’accès conditionnel |
Surveiller et alerter sur les interruptions. Définissez un seuil de base de référence, puis effectuez une supervision et ajustez-le pour l’adapter aux comportements de votre organisation et limiter la génération de fausses alertes. Modèle Microsoft Sentinel Règles Sigma |
Les éléments suivants sont listés par ordre d’importance en fonction de leur effet et de la gravité des entrées.
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Alertes de fraude MFA. | Élevée | Journal de connexion Microsoft Entra | État = échec -et- Détails = MFA refusé |
Surveiller et alerter sur n’importe quelle entrée. Modèle Microsoft Sentinel Règles Sigma |
| Échecs d’authentification depuis des pays/régions où vous n’opérez pas. | Moyenne | Journal de connexion Microsoft Entra | Emplacement = <emplacement non approuvé> | Surveiller et alerter sur n’importe quelle entrée. Modèle Microsoft Sentinel Règles Sigma |
| Échecs d’authentification pour des protocoles hérités ou des protocoles qui ne sont pas utilisés. | Moyenne | Journal de connexion Microsoft Entra | État = échec -et- Application cliente = autres clients, POP, IMAP, MAPI, SMTP, ActiveSync |
Surveiller et alerter sur n’importe quelle entrée. Modèle Microsoft Sentinel Règles Sigma |
| Échecs bloqués par l’accès conditionnel. | Moyenne | Journal de connexion Microsoft Entra | Code d’erreur = 53003 -et- Motif de l’échec = Bloqué par l’accès conditionnel |
Surveiller et alerter sur n’importe quelle entrée. Modèle Microsoft Sentinel Règles Sigma |
| Amélioration des authentifications ayant échoué de tout type. | Moyenne | Journal de connexion Microsoft Entra | La capture augmente les échecs dans tous les domaines. En d’autres termes, le nombre total d’échecs d’authentification du jour est > 10 % par rapport au même jour de la semaine précédente. | Si vous n’avez pas de seuil défini, surveillez et signalez si les échecs augmentent de 10 % ou plus. Modèle Microsoft Sentinel |
| L’authentification a lieu aux dates et heures de la semaine lors desquelles les pays/régions n’effectuent aucune opération commerciale normale. | Faible | Journal de connexion Microsoft Entra | Capturez l’authentification interactive se produisant en dehors des jours/heures de fonctionnement normaux. État = réussite -et- Emplacement = <emplacement> -et- Jour\heure = <heures de travail anormales> |
Surveiller et alerter sur n’importe quelle entrée. Modèle Microsoft Sentinel |
| Compte désactivé/bloqué pour les connexions | Faible | Journal de connexion Microsoft Entra | État = échec -et- Code d’erreur = 50057, le compte d’utilisateur est désactivé. |
Cela peut indiquer qu’un utilisateur tente d’accéder à un compte une fois qu’il a quitté une organisation. Même si le compte est bloqué, il est important de journaliser et de signaler cette activité par une alerte. Modèle Microsoft Sentinel Règles Sigma |
Surveillance des connexions inhabituelles réussies
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Authentifications de comptes privilégiés en dehors des contrôles attendus. | Élevée | Journal de connexion Microsoft Entra | État = réussite -et- UserPricipalName = <Compte d’administrateur> -et- Emplacement = <emplacement non approuvé> -et- Adresse IP = <adresse IP non approuvée> Informations sur l’appareil = <navigateur non approuvé, système d’exploitation> |
Surveiller et alerter en cas de réussite de l’authentification pour les comptes privilégiés en dehors des contrôles attendus. Trois contrôles communs sont répertoriés. Modèle Microsoft Sentinel Règles Sigma |
| Lorsque seule l’authentification à facteur unique est requise. | Faible | Journal de connexion Microsoft Entra | État = réussite Exigence d’authentification = authentification à facteur unique |
Effectuez un monitoring périodique, et vérifiez le comportement attendu. Règles Sigma |
| Détectez les comptes privilégiés non inscrits à MFA. | Élevé | API Azure Graph | Exécutez la requête IsMFARegistered = false pour les comptes administrateur. Lister credentialUserRegistrationDetails - Microsoft Graph version bêta |
Auditez et vérifiez si c’est intentionnel ou si c’est un oubli. |
| Authentifications réussies depuis des pays/régions où votre organisation n’a aucune activité. | Moyenne | Journal de connexion Microsoft Entra | État = réussite Emplacement = <région/pays non approuvé> |
Surveillez et signalez toute entrée ne correspondant pas aux noms de ville que vous fournissez. Règles Sigma |
| Authentification réussie, session bloquée par l’accès conditionnel. | Moyenne | Journal de connexion Microsoft Entra | État = réussite -et- code d'erreur = 53003 – Motif de l’échec, bloqué par l’accès conditionnel |
Supervisez et examinez lorsque l’authentification réussit, mais que la session est bloquée par l’accès conditionnel. Modèle Microsoft Sentinel Règles Sigma |
| Authentification réussie après la désactivation de l’authentification héritée. | Moyenne | Journal de connexion Microsoft Entra | état = réussite -et- Application cliente = autres clients, POP, IMAP, MAPI, SMTP, ActiveSync |
Si votre organisation a désactivé l’authentification héritée, surveillez et alertez lorsque l’authentification héritée a réussi. Modèle Microsoft Sentinel Règles Sigma |
Nous vous recommandons de passer en revue périodiquement les authentifications pour les applications à impact métier moyen et à impact métier élevé, où seule une authentification monofacteur est nécessaire. Pour chacune, vous souhaitez déterminer si l’authentification à un seul facteur était attendue ou non. De plus, passez en revue les augmentations d’authentifications réussies ou les authentifications ayant lieu à des moments inattendus, en fonction du lieu.
| Éléments à analyser | Niveau de risque | Where | Filtre/Sous-filtre | Notes |
|---|---|---|---|---|
| Authentifications de l’application MBI et HBI à l’aide de l’authentification à facteur unique. | Faible | Journal de connexion Microsoft Entra | état = réussite -et- ID de l’application = <application à impact commercial élevé (HBI)> -et- Exigence d’authentification = authentification à facteur unique |
Examinez et vérifiez si cette configuration est intentionnelle. Règles Sigma |
| Authentifications aux dates et heures de la semaine (ou de l’année) lors desquelles les pays/régions n’effectuent aucune opération commerciale normale. | Faible | Journal de connexion Microsoft Entra | Capturez l’authentification interactive se produisant en dehors des jours/heures de fonctionnement normaux. État = réussite Emplacement = <emplacement> Date\heure = <heures de travail anormales> |
Surveillez et signalez les authentifications aux dates et heures de la semaine (ou de l’année) lors desquelles les pays/régions n’effectuent aucune opération commerciale normale. Règles Sigma |
| Augmentation mesurable des connexions réussies. | Faible | Journal de connexion Microsoft Entra | La capture augmente le nombre d’authentifications réussies dans tous les domaines. En d’autres termes, le nombre total d’authentifications réussies du jour est > 10 % par rapport au même jour de la semaine précédente. | Si vous ne disposez pas d’un seuil défini, surveillez et signalez si les authentifications réussies augmentent de 10 % ou plus. Modèle Microsoft Sentinel Règles Sigma |
Étapes suivantes
Consultez les articles suivants sur les opérations de sécurité :
Vue d’ensemble des opérations de sécurité Microsoft Entra
Opérations de sécurité pour les comptes consommateur
Opérations de sécurité pour les comptes privilégiés
Opérations de sécurité pour Privileged Identity Management
Opérations de sécurité pour les applications