Configuration de la protection d'identité et de l'authentification multifacteur dans Azure AD

La protection des identités dans le cloud n'est plus une option ; c'est un élément essentiel de toute stratégie de sécurité moderne . Azure AD, désormais Microsoft Entra ID, est devenu la plateforme centrale d'authentification pour Microsoft 365, les applications SaaS et les environnements hybrides (voir Configurer Azure AD et SharePoint ). Par conséquent, toute défaillance à ce niveau peut compromettre l'ensemble de votre organisation. C'est pourquoi il est crucial de comprendre comment configurer correctement et de manière cohérente la protection des identités et l'authentification multifacteur (MFA) .

Avec une configuration adéquate, vous pouvez combiner l'authentification multifacteur (MFA), le contrôle d'accès conditionnel, la protection d'identité et les méthodes d'authentification modernes (notamment les jetons OATH et les clés FIDO2 ; voir l'introduction à la cryptographie ) afin d'obtenir un équilibre entre sécurité renforcée et expérience utilisateur optimale . Cet article détaillera les principales options : notifications d'activités suspectes, utilisation des jetons OATH, configuration des appels téléphoniques, adresses IP de confiance, méthodes de vérification, politiques de contrôle d'accès conditionnel, scénarios hybrides avec Active Directory et capacités d'authentification adaptative basée sur les risques.

L’authentification multifacteurs est le processus par lequel, lors de la connexion, l’utilisateur doit fournir un ou plusieurs éléments de vérification supplémentaires en plus de son mot de passe. Il peut s’agir d’un code envoyé sur un appareil mobile, d’une notification push dans Microsoft Authenticator, d’un jeton matériel OATH, d’une clé FIDO2 ou même de données biométriques telles qu’une empreinte digitale (via Windows Hello Entreprise).

L'objectif est que, même si un attaquant parvient à voler ou à deviner le mot de passe, il soit bloqué faute de second facteur d'authentification . Compte tenu du volume d'identifiants divulgués et achetés en ligne, et de l'efficacité du phishing, l'authentification multifacteur (MFA) est devenue l'une des défenses les plus efficaces contre les attaques basées sur l'identité , aussi bien dans Azure AD que dans Active Directory local.

Parallèlement, Microsoft Entra ID Protection ajoute une couche de détection et d'évaluation des risques aux connexions et aux identités. En se basant sur des signaux tels que des localisations inhabituelles, des appareils inconnus, des schémas d'attaque connus ou même des signalements d'utilisateurs, le système peut identifier les comptes à haut risque et autoriser l'application de mesures correctives (comme le blocage de l'accès ou la réinitialisation des mots de passe).

En pratique, l'association de l'authentification multifacteur (MFA), de la protection d'identité et du contrôle d'accès conditionnel permet de n'exiger des mesures de sécurité supplémentaires que lorsque le contexte le justifie (par exemple, en cas de risque élevé), fluidifiant ainsi l'accès sans compromettre la sécurité. Cette approche adaptative est de plus en plus prisée par les entreprises pour leurs environnements de travail hybrides et à distance.

Notification d'activité suspecte et d'utilisateurs à haut risque

L'un des aspects les plus intéressants de la protection d'identité dans Azure AD est la possibilité pour les utilisateurs de signaler directement les demandes d'authentification multifacteur (MFA) inconnues comme suspectes. Cela peut se faire via l'application Microsoft Authenticator (en rejetant et en signalant la demande) ou par téléphone.

Lorsqu'un utilisateur signale une demande d'authentification multifacteur comme frauduleuse, Entra ID Protection enregistre l'incident comme une activité suspecte signalée par l'utilisateur et attribue au compte le statut « Utilisateur à haut risque » . Dès lors, vos politiques de gestion des risques configurées ou vos procédures de réponse manuelles sont mises en œuvre.

Cet événement est consigné dans plusieurs journaux et tableaux de bord : dans le rapport de détection des risques (type de détection « activité suspecte signalée par l’utilisateur », niveau de risque élevé, origine : utilisateur final), dans les journaux de connexion (résultat de l’authentification : authentification multifacteur refusée par l’utilisateur ) et dans les journaux d’audit en tant qu’activité spécifique. Tous ces éléments sont essentiels pour enquêter sur les incidents d’usurpation d’identité ou automatiser les réponses ; la formation du personnel à la cybersécurité est donc cruciale.

Pour activer cette fonctionnalité, accédez au centre d'administration Microsoft Entra, puis à Entra ID > Méthodes d'authentification > Paramètres et activez l' option « Signaler les activités suspectes » . Si vous laissez l'option « Géré par Microsoft » sélectionnée, la fonctionnalité restera inactive. Il est donc conseillé de revoir ce paramètre si vous souhaitez que vos utilisateurs participent activement à la détection des attaques.

Vous pouvez également définir un code de signalement que les utilisateurs devront saisir lors des appels vocaux pour indiquer qu'une tentative est suspecte, à condition d'avoir également importé des messages d'accueil vocaux personnalisés pour le locataire. Si vous ne configurez rien, le code par défaut est 0, quelle que soit la valeur définie dans la stratégie.

Gestion des risques liés aux licences Microsoft. Saisissez l'ID P1

Avec une licence P1, les fonctionnalités de protection d'identité sont légèrement plus limitées, mais vous pouvez toujours consulter et analyser les détections de risques liées aux utilisateurs ayant signalé l'authentification multifacteur comme suspecte. Ces détections apparaissent dans le rapport de risques, les journaux de connexion et les journaux d'audit, ce qui constitue un bon point de départ pour l'analyse forensique.

Dans ce cas de figure, la solution est généralement manuelle ou semi-automatisée : l’équipe informatique ou le service d’assistance peut demander aux utilisateurs de réinitialiser leur mot de passe via SSPR (Self-Service Password Reset) ou modifier le mot de passe à leur place. Il est également possible d’automatiser les flux de travail à l’aide de Microsoft Graph ou de PowerShell pour imposer des changements de mot de passe, révoquer les sessions actives, voire désactiver temporairement le compte le temps d’analyser le problème.

Dans les environnements sans P2, vous pouvez également exploiter les événements à risque via les API Graph pour créer vos propres flux de travail de réponse , les intégrer à des systèmes de billetterie ou à des solutions SIEM/SOAR, et ainsi parvenir à une orchestration plus professionnelle des incidents d'identité.

Correction automatique des risques avec Microsoft Enter ID P2

Avec les licences P2, le composant le plus puissant entre en jeu : les politiques d’accès conditionnel basées sur les risques . Ces politiques permettent au système d’appliquer automatiquement des actions telles que le blocage de la connexion ou l’exigence d’une réinitialisation du mot de passe lorsqu’un utilisateur est considéré comme présentant un risque élevé (par exemple, après le signalement d’une activité suspecte).

Dans les paramètres d'accès conditionnel, accédez à Conditions > Risque utilisateur et définissez des règles qui réagissent à des valeurs telles que risque élevé ou moyen. Par exemple, vous pouvez configurer les utilisateurs à risque élevé pour qu'ils modifient leur mot de passe avant de pouvoir continuer , ou bien leur compte sera bloqué jusqu'à ce qu'un administrateur examine leur cas.

Ce modèle d'authentification adaptative s'intègre parfaitement à l'authentification multifacteur (MFA) : au lieu d'exiger systématiquement un deuxième facteur, vous pouvez adapter les exigences d'authentification en fonction du risque en temps réel (localisation inhabituelle, adresse IP suspecte, comportement anormal, etc.). Ainsi, l'utilisateur n'est pas submergé de demandes d'authentification multifacteur lorsque tout est normal, mais le seuil est relevé dès qu'un élément suspecté d'une attaque potentielle est détecté.

Jetons OATH et codes TOTP dans Azure AD

En plus de l'application classique Microsoft Authenticator, Entra ID prend en charge les jetons matériels OATH TOTP qui génèrent des codes à usage unique (OTP) basés sur le temps, généralement toutes les 30 ou 60 secondes, en utilisant SHA-1. Cette option est bien adaptée aux organisations qui privilégient les appareils physiques dédiés à l'authentification multifacteur (MFA) en raison de politiques internes, de secteurs réglementés ou d'utilisateurs ne disposant pas de smartphone professionnel.

Ces jetons sont généralement fournis avec une clé secrète (graine) préprogrammée. Pour les utiliser avec Azure AD, cette clé doit être importée dans le locataire via un fichier CSV. Certaines restrictions importantes s'appliquent : la clé secrète est limitée à 128 caractères encodés en Base32 , ne peut contenir que les lettres a-z et a-Z ainsi que les chiffres 1 à 7, et doit respecter le format attendu par le système pour être acceptée.

Il est également possible d'utiliser des jetons matériels OATH TOTP programmables et reconfigurables , en les traitant de la même manière que les jetons logiciels. Cependant, la prise en charge des jetons matériels OATH fait partie d'une préversion publique, ce qui implique des modifications potentielles, des limitations et des conditions d'utilisation supplémentaires, comme indiqué dans le contrat Azure Previews.

Le processus d'importation des jetons s'effectue à l'aide d'un fichier CSV contenant des colonnes telles que l'UPN, le numéro de série, la clé secrète, l'intervalle de temps, le fabricant et le modèle. Après l'importation via Saisir l'identifiant > Authentification multifacteur > Jetons OATH , le service traite le fichier et vous permet de consulter les erreurs de formatage dans un fichier CSV téléchargeable.

Une fois les erreurs corrigées, chaque jeton doit être activé manuellement : l’administrateur sélectionne « Activer » et saisit le code OTP affiché par l’appareil, ce qui associe définitivement le jeton à l’utilisateur. Chaque personne peut combiner jusqu’à cinq facteurs d’authentification (par jeton ou application) simultanément, offrant ainsi une grande flexibilité pour la redondance ou la transition entre les méthodes.

paramètres d'appel et de message vocal

Une autre méthode courante d'authentification multifacteur (MFA) dans Azure AD est la vérification téléphonique par appel vocal . Les utilisateurs reçoivent un appel automatisé et, pour s'authentifier, ils appuient sur la touche # ou saisissent un code PIN, selon la configuration. Cette expérience est hautement personnalisable, notamment dans les environnements où les appels vocaux restent la méthode privilégiée, voire obligatoire.

Par défaut, Microsoft utilise des numéros de téléphone spécifiques au pays ou à la région pour passer des appels. Aux États-Unis, par exemple, plusieurs numéros sont prédéfinis, tandis que dans d'autres pays, une liste spécifique est fournie. Il est important de communiquer ces numéros aux utilisateurs ou de leur demander de les ajouter à leur liste d'autorisation s'ils utilisent des filtres anti-spam, afin d'éviter tout problème d'acheminement des appels.

Si vous le souhaitez, vous pouvez également définir votre propre numéro d'identification de l'appelant pour les appels nécessitant l'authentification multifacteur (MFA), à condition qu'il s'agisse d'un numéro américain. Cette option se configure dans Entra ID > Authentification multifacteur > Paramètres d'appel téléphonique ; il vous suffit ensuite de saisir le numéro souhaité et d'enregistrer les modifications.

Une autre option de personnalisation intéressante est l'utilisation de messages vocaux personnalisés . Au lieu des enregistrements vocaux standard de Microsoft, vous pouvez importer vos propres fichiers audio au format .wav ou .mp3, d'une taille maximale de 1 Mo et d'une durée inférieure à 20 secondes. Si le message est trop long, la vérification risque d'échouer car l'utilisateur ne pourra pas répondre avant la fin de l'enregistrement.

La langue entendue par l'utilisateur dépend à la fois de la langue détectée dans son navigateur ou son contexte, et des langues disponibles dans les messages personnalisés chargés par l'administrateur. Par exemple, si seul un message d'accueil est en allemand, ce message sera diffusé à tous les utilisateurs, qu'ils soient germanophones ou non, à moins qu'il n'existe des alternatives plus appropriées dans d'autres langues.

Microsoft propose des scripts par défaut pour différents types de messages (authentification réussie, messages d'accueil standard, messages d'alerte en cas de fraude, nouvelles tentatives, activation, etc.) que vous pouvez utiliser comme base pour enregistrer vos propres messages audio . Pour les configurer, retournez dans la section des paramètres d'appel, sélectionnez « Ajouter un message d'accueil », choisissez le type de message et la langue, puis importez le fichier audio.

Configuration avancée du service MFA et adresses IP de confiance

Outre les méthodes de vérification, le portail de configuration du service MFA traditionnel propose des options telles que les adresses IP de confiance, les mots de passe d'application et la fonctionnalité « Mémoriser l'authentification multifacteurs ». Bien que Microsoft encourage de plus en plus l'utilisation de l'accès conditionnel et d'une politique d'authentification unifiée, ce portail reste pertinent dans de nombreux environnements.

Les adresses IP de confiance permettent aux utilisateurs se connectant depuis l' intranet de l'entreprise (segments IP spécifiques) de contourner l'authentification multifacteur (MFA) pour certains flux de navigation. Cette fonctionnalité, disponible avec Microsoft Entra ID P1, est utile pour fluidifier le trafic au sein du réseau tout en maintenant l'authentification multifacteur pour les accès externes.

Dans les locataires gérés, vous pouvez définir jusqu'à 50 plages d'adresses IP au format CIDR considérées comme fiables. Dans les locataires fédérés, vous pouvez également activer l'option « Tous les utilisateurs fédérés » afin que les utilisateurs authentifiés via AD FS depuis l'intranet puissent contourner l'authentification multifacteur (MFA), à condition qu'AD FS émette la notification appropriée (insidecorporatenetwork), configurée via une règle d'émission de revendications.

N’oubliez pas que si vous utilisez l’extension NPS pour fournir l’authentification multifacteur (MFA) aux applications locales, l’adresse IP qu’Azure AD verra sera toujours celle du serveur NPS. Par conséquent, l’utilisation de plages d’adresses IP approuvées peut ne pas se comporter comme prévu. Il est également important de noter qu’en dehors du réseau d’entreprise , l’authentification multifacteur reste requise, même si des adresses IP approuvées sont définies.

La méthode recommandée pour gérer les emplacements de confiance consiste aujourd'hui à utiliser l'accès conditionnel avec des emplacements nommés . Dans Identifiant de connexion > Accès conditionnel > Emplacements nommés, vous pouvez créer un emplacement, le marquer comme approuvé et définir des plages d'adresses IP (par exemple, 40.77.182.32/27). Ces emplacements sont ensuite utilisés dans les stratégies d'accès conditionnel pour déterminer quand l'authentification multifacteur (MFA) est requise.

Activez les adresses IP de confiance à l'aide de l'accès conditionnel ou du service hérité

Pour harmoniser la configuration des adresses IP de confiance existantes avec l'accès conditionnel, une option spécifique « Configurer les adresses IP de confiance pour l'authentification multifacteur » est disponible dans la section Emplacements nommés. Vous pouvez y spécifier l'utilisation des notifications intranet AD FS pour les utilisateurs fédérés ainsi que les plages d'adresses IP publiques à considérer comme fiables.

Si vous préférez conserver l' ancienne configuration de service , vous trouverez également sur cette page les options « Pour les requêtes des utilisateurs fédérés sur mon intranet » et « Pour les requêtes provenant d'une plage spécifique de sous-réseaux d'adresses IP », avec la même logique de notation CIDR et les mêmes limites de plage. Cette configuration restera en vigueur jusqu'à la migration complète vers la nouvelle politique d'authentification.

Méthodes de vérification disponibles et leur gestion

Azure AD propose un large éventail de méthodes d'authentification utilisables pour l'authentification multifacteur (MFA) et la réactivation logicielle sans authentification (SSPR), selon votre configuration. Les méthodes d'authentification multifacteur prises en charge incluent : Microsoft Authenticator, Authenticator Lite (dans Outlook), Windows Hello Entreprise, les clés de sécurité FIDO2, les jetons matériels OATH, les jetons logiciels OATH, les SMS et les appels vocaux.

De plus, certaines méthodes comme la vérification par courriel ou les questions de sécurité ne sont pas considérées comme de l'authentification multifacteur (MFA), mais peuvent servir de facteurs de vérification pour la reconnaissance de mot de passe par application (SSPR). Il existe également les mots de passe d'application, conçus pour les applications plus anciennes ne prenant pas en charge l'authentification moderne et utilisés spécifiquement dans les scénarios d'authentification multifacteur par utilisateur.

Microsoft recommande d'utiliser la stratégie « Méthodes d'authentification » pour gérer toutes ces méthodes . Cette stratégie est accessible via Identifiant de connexion > Sécurité > Méthodes d'authentification > Stratégies. Cette console unifiée vous permet d'activer ou de désactiver des méthodes pour différents groupes d'utilisateurs, de définir des paramètres supplémentaires (comme la configuration de l'authentification sans mot de passe avec Microsoft Authenticator, affichant l'emplacement et le nom de l'application) et de contrôler l'authentification multifacteur (MFA) et la reconnaissance de mot de passe en cas de panne (SSPR) depuis un seul et même emplacement.

Parallèlement, les politiques existantes restent en vigueur : les paramètres d’authentification multifacteur (MFA) dans le centre d’administration Office 365 (concernant l’authentification multifacteur par utilisateur et l’authentification multifacteur conditionnelle) et les paramètres de la méthode d’authentification SSPR (Utilisateurs > Réinitialisation du mot de passe > Méthodes d’authentification). Ces politiques ne se synchronisent pas automatiquement avec la nouvelle politique unifiée. Par conséquent, pendant la période de coexistence, vous devez vous assurer qu’elles sont configurées de manière cohérente.

En cas de coexistence de plusieurs stratégies, l'ordre de traitement est le suivant : d'abord la stratégie des méthodes d'authentification, puis les paramètres MFA hérités, et enfin les paramètres SSPR. Azure AD respecte la configuration de toutes les stratégies ; par conséquent, si une méthode est autorisée dans l'une d'entre elles, l'utilisateur peut s'inscrire et l'utiliser. Pour bloquer complètement une méthode, vous devez la restreindre dans toutes les stratégies concernées.

Dans la console des méthodes d'authentification, vous trouverez également une section Migration indiquant l'étape actuelle : Pré-migration, Migration en cours ou Migration terminée. Lors des deux premières étapes, les anciennes stratégies sont toujours appliquées. Une fois la migration terminée, seule la stratégie des méthodes d'authentification modernes sera prise en compte, les anciennes étant ignorées.

N'oubliez pas d'utiliser l'authentification multifacteurs et des appareils de confiance.

La fonctionnalité « Mémoriser l’authentification multifacteur » vise à simplifier l’expérience utilisateur en lui permettant de ne plus avoir à effectuer de vérifications pendant un nombre de jours défini après avoir réussi l’authentification multifacteur sur un appareil et un navigateur. Elle fonctionne grâce à un cookie persistant enregistré dans le navigateur lorsque l’utilisateur sélectionne l’option « Ne plus me demander pendant X jours ».

Tant que le cookie reste valide (ni supprimé ni expiré) et que l'utilisateur utilise le même navigateur, l'authentification multifacteur (MFA) ne sera pas requise à nouveau dans ce contexte. En revanche, s'il change de navigateur sur le même appareil ou s'il efface ses cookies, une nouvelle vérification sera demandée. Cette option est uniquement disponible pour les flux basés sur un navigateur, et non pour les applications hors navigateur . Toutefois, dans ces dernières, Azure AD vérifie la date de la dernière authentification multifacteur lors de la validation des jetons d'actualisation.

Cette fonctionnalité peut réduire considérablement le nombre de demandes d'authentification multifacteur (MFA) dans les applications web, mais la durée de validité des jetons doit être soigneusement paramétrée : la définir en dessous des 90 jours habituels des clients modernes peut en réalité augmenter la fréquence des demandes MFA dans certaines applications. De plus, l'association de cette fonctionnalité avec le contrôle d'accès conditionnel peut entraîner une augmentation ou une diminution des demandes MFA en fonction des règles configurées.

Pour l'activer, depuis le portail de configuration du service MFA, accédez à Paramètres du service > Mémoriser l'authentification multifacteur , cochez « Autoriser les utilisateurs à mémoriser l'authentification multifacteur sur les appareils de confiance » et définissez la durée (90 jours maximum sont recommandés pour une expérience utilisateur optimale). Dès lors, l'option « Ne plus demander » s'affichera lors de l'authentification multifacteur.

Activer l'authentification multifacteur avec des politiques d'accès conditionnel

Bien qu'Azure AD permette d'activer l'authentification multifacteur (MFA) directement pour chaque utilisateur, Microsoft recommande d'utiliser des stratégies d'accès conditionnel pour contrôler quand et qui doit y recourir. Cette approche offre une granularité bien plus fine et est mieux adaptée aux scénarios réels : applications critiques, accès depuis des réseaux non fiables, rôles privilégiés, etc.

Pour utiliser l'accès conditionnel avec l'authentification multifacteur (MFA), vous avez besoin d'un locataire. Cette fonctionnalité est compatible avec les licences P1 ou d'essai , et nécessite un compte disposant au minimum du rôle d'administrateur d'accès conditionnel (certaines options MFA peuvent également être gérées avec le rôle d'administrateur de stratégie d'authentification). Il est également recommandé de disposer d'un utilisateur de test sans droits d'administrateur et d'un groupe de test (par exemple, « MFA-Test-Group ») afin de valider l'expérience sans impacter l'ensemble de l'organisation.

L'approche classique consiste à créer une stratégie qui s'applique à un ensemble spécifique d'utilisateurs ou de groupes et qui se déclenche pour certaines applications cloud ou actions spécifiques. Ensuite, dans les contrôles d'accès, sélectionnez « Accorder l'accès » et cochez « Exiger l'authentification multifacteur » comme condition nécessaire. La stratégie peut être laissée en mode rapport uniquement afin d'observer son impact avant son activation.

Un exemple classique de test consiste à appliquer la stratégie au groupe de test et à une ressource telle que l'API de gestion des services Windows Azure ou le centre d'administration Microsoft Entra. Vous constaterez ainsi que, lors de l'accès à ces ressources, l'authentification multifacteur (MFA) est demandée ou que l'utilisateur est invité à s'inscrire à la MFA s'il ne l'a pas déjà fait.

L'expérience utilisateur se déroule généralement comme suit : une première connexion sans authentification multifacteur (MFA) à une ressource non protégée, une déconnexion, puis l'accès à la ressource protégée. L'utilisateur est alors guidé tout au long du processus d'enregistrement MFA (via un téléphone d'authentification, un téléphone professionnel avec extension ou une application mobile). Une fois l'enregistrement terminé, les connexions suivantes à la ressource protégée déclenchent une vérification selon la méthode configurée (notification push, SMS, appel téléphonique, code d'application, etc.).

Scénarios hybrides avec Active Directory et authentification multifacteur

Dans de nombreux environnements, Active Directory local demeure le cœur de l'infrastructure d'identité , tandis qu'Azure AD assure l'interface d'authentification pour Microsoft 365 et les applications cloud. Dans ces cas, le déploiement cohérent de l'authentification multifacteur (MFA) à la fois sur site et dans le cloud représente un défi majeur.

Active Directory n'offre une prise en charge native de l'authentification multifacteur (MFA) que via une carte à puce , à ne pas confondre avec la MFA pour AD FS. Afin de renforcer les connexions interactives ou le protocole RDP sur les serveurs et les PC, de nombreuses organisations intègrent des solutions telles que Windows Hello Entreprise ou des fournisseurs MFA tiers (par exemple, Duo) directement dans les terminaux ou les serveurs de rebond ; la résilience des identités et la haute disponibilité sont des considérations essentielles dans ces architectures.

Lorsqu'on utilise des fournisseurs de services d'identité cloud comme Entra ID, il est courant de s'appuyer sur des outils tels que Microsoft Entra Connect (anciennement Azure AD Connect) pour synchroniser les identités entre l'Active Directory local et le locataire cloud. Ensuite, l'authentification multifacteur (MFA), le contrôle d'accès conditionnel et la protection des identités sont appliqués au niveau d'Entra ID pour toutes les applications qui s'authentifient directement auprès de ce dernier.

Les utilisateurs d'Entra ne disposant pas de licences Premium peuvent utiliser les paramètres de sécurité par défaut pour activer un ensemble de règles de sécurité de base, incluant l'authentification multifacteur obligatoire et le blocage des anciennes méthodes d'authentification. Cependant, sans les licences P1 ou P2, l'accès conditionnel est impossible, ce qui limite considérablement la possibilité de définir des règles spécifiques (par application, emplacement, risque, etc.).

À l'inverse, avec des abonnements comme Microsoft 365 Business, E3, E5 ou les licences Entra ID P1/P2, les stratégies d'accès conditionnel sont activées et peuvent être combinées à l'authentification multifacteur (MFA) par utilisateur si nécessaire. Microsoft 365 et Office 365 prennent en charge la MFA par SMS, appel vocal et Microsoft Authenticator, tandis qu'Entra ID propose des options supplémentaires telles que FIDO2, Windows Hello, les jetons OATH, etc.

Les applications utilisant une authentification moderne (telle qu'OpenID Connect ou OAuth2) et s'intégrant directement à Entra ID peuvent tirer pleinement parti de toutes ces fonctionnalités d'accès conditionnel. Pour les applications existantes ou sur site ne communiquant pas directement avec Entra, Azure AD Application Proxy ou l'intégration avec Network Policy Server (NPS) permet d'interposer l'authentification multifacteur (MFA) dans le flux d'authentification.

Authentification adaptative et protection de l'identité

La tendance actuelle en matière de sécurité des identités va au-delà de la simple application uniforme de l'authentification multifacteur (MFA). L'idée est d'adapter les exigences d'authentification au contexte, au niveau de risque et à l'historique de comportement de l'utilisateur. C'est là qu'intervient l'authentification adaptative.

Entra ID Protection analyse en permanence les risques liés à l'utilisateur et au processus de connexion : localisations inhabituelles, appareils inconnus, schémas associés aux bots ou aux attaques par force brute, identifiants trouvés sur des listes volées, etc. Lorsque le risque est élevé, des mesures correctives peuvent être déclenchées, comme l'obligation pour l'utilisateur de réinitialiser son mot de passe ou le blocage direct de l'accès jusqu'à l'intervention d'un administrateur.

En combinant ces fonctionnalités avec l'accès conditionnel, vous pouvez concevoir des politiques telles que : « si le risque lié à l'utilisateur est élevé, bloquer l'accès » ou « si le risque de connexion est moyen à élevé, exiger une authentification multifacteur ». De cette façon, les exigences de vérification ne sont activées qu'en cas de situation suspecte, tandis que dans des circonstances normales, l'utilisateur ne constate aucun changement dans son flux de travail habituel.

Cette couche supplémentaire complète les autres mesures de défense (correctifs, segmentation du réseau, protection des terminaux, surveillance des journaux, etc.) afin de renforcer la résilience globale face aux attaques. Il est important de rappeler que l'authentification multifacteur (MFA) seule ne suffit pas , mais qu'elle constitue l'un des éléments les plus efficaces d'une stratégie de défense en profondeur axée sur l'identité.

En définitive, une configuration soignée des méthodes d'authentification, de l'authentification multifacteur (MFA), de l'accès conditionnel, des adresses IP de confiance, de la signature électronique sécurisée (SSPR) et de la protection de l'identité, aussi bien dans le cloud que dans les environnements hybrides avec Active Directory, permet de constituer une barrière très solide contre le vol d'identifiants, les attaques de phishing et les déplacements latéraux, tout en maintenant une expérience utilisateur acceptable au quotidien.