Authentification multifacteur et accès conditionnel

Les identifiants volés sont la principale cause des failles de sécurité dans le cloud. Un mot de passe seul peut être dérobé par hameçonnage, deviné par force brute ou exposé lors d’une faille chez un tiers. L’authentification multifacteur (MFA) exige un second facteur de vérification qu’un attaquant a peu de chances de posséder, même après avoir obtenu un mot de passe, ce qui réduit considérablement le risque d’accès non autorisé à votre environnement Azure.

Entra ID prend en charge plusieurs facteurs de vérification MFA. L’option la plus sécurisée et recommandée est l’application Microsoft Authenticator, qui fournit une correspondance de numéros et des notifications push. Les autres options comprennent une clé de sécurité FIDO2 (jeton matériel), un jeton OATH logiciel, un SMS ou un appel vocal. Les SMS et les appels vocaux offrent un niveau de sécurité inférieur et ne doivent être utilisés qu’en solution de secours.

Dans Entra ID, MFA peut être imposée par trois mécanismes. Security defaults est l’option gratuite en un clic qui impose MFA à tous les utilisateurs, mais sans possibilité de personnalisation. La MFA par utilisateur (ancienne méthode) active MFA pour certains comptes d’utilisateur. L’approche moderne recommandée repose sur les Conditional Access policies (Entra ID P1/P2), qui imposent MFA uniquement lorsque certaines conditions de risque sont réunies, réduisant ainsi les contraintes pour les connexions à faible risque.

Conditional Access (Entra ID P1) est un moteur de règles « si-alors » : si un utilisateur (ou un groupe) tente d’accéder à une ressource dans certaines conditions, alors l’accès est accordé ou bloqué, ou des contrôles supplémentaires sont exigés, comme MFA ou un appareil conforme. Les conditions peuvent inclure l’identité de l’utilisateur, la conformité de l’appareil, l’emplacement IP, l’application consultée et le score de risque d’Identity Protection d’Entra ID.

Une stratégie Conditional Access comporte deux parties : les attributions (qui et ce à quoi la stratégie s’applique) et les contrôles d’accès (ce qui se produit lorsque la stratégie se déclenche). Les attributions définissent les utilisateurs/groupes, les applications cloud consultées et les conditions (emplacement, plateforme de l’appareil, risque lié à la connexion). Les contrôles d’accès déterminent s’il faut accorder l’accès (en exigeant éventuellement MFA, un appareil conforme ou une application approuvée) ou le bloquer entièrement.

Les emplacements nommés de Conditional Access permettent de définir des plages d’adresses IP approuvées (comme le réseau de vos bureaux) ou des pays. Une stratégie courante consiste à exiger MFA lorsqu’un utilisateur se connecte depuis l’extérieur d’un emplacement nommé approuvé, mais à autoriser le passage direct depuis une adresse IP de bureau connue. Cela réduit les contraintes pour les employés présents sur site tout en renforçant la sécurité des utilisateurs à distance ou en déplacement.

Conditional Access peut exiger que l’appareil utilisé pour accéder à la ressource soit conforme (qu’il respecte les stratégies de conformité des appareils Intune) ou qu’il s’agisse d’un appareil d’entreprise joint à Azure AD en mode hybride. Ainsi, même si les identifiants sont valides, les connexions depuis des appareils personnels ou non gérés sont bloquées ou doivent satisfaire des contrôles supplémentaires. Les contrôles fondés sur l’appareil constituent un pilier essentiel du modèle de sécurité Zero Trust.

Entra ID Identity Protection (P2) utilise l’apprentissage automatique pour évaluer chaque connexion et lui attribuer un score de risque : faible, moyen ou élevé. Les facteurs de risque comprennent les déplacements impossibles (connexion depuis deux pays en quelques minutes), les adresses IP anonymes, les identifiants divulgués et la détection d’attaques par pulvérisation de mots de passe. Les stratégies Conditional Access peuvent se déclencher selon le niveau de risque — par exemple, exiger MFA en cas de risque moyen et bloquer automatiquement l’accès en cas de risque élevé.

Avant d’appliquer une stratégie Conditional Access, vous pouvez la placer en mode Rapport uniquement. Dans ce mode, la stratégie évalue toutes les connexions et enregistre ce qui se serait produit (accès accordé, bloqué ou MFA exigée), sans appliquer réellement les contrôles. Vous pouvez ainsi valider l’impact de la stratégie sur vos utilisateurs avant de l’activer et éviter des blocages inattendus dus à des conditions mal définies.

L’outil What If du volet Conditional Access permet de simuler un scénario de connexion — en indiquant un utilisateur, une application, une adresse IP, une plateforme d’appareil et un niveau de risque — puis d’afficher les stratégies qui s’appliqueraient et le résultat combiné. Cet outil est particulièrement utile pour résoudre les problèmes d’accès et vérifier que l’ensemble de vos stratégies produit le résultat attendu pour certains utilisateurs et certaines conditions.

Chaque organisation devrait conserver au moins deux comptes d’accès d’urgence de type break-glass, exclus de toutes les stratégies Conditional Access, y compris des exigences MFA. Ces comptes ne doivent être utilisés qu’en cas de défaillance de l’infrastructure MFA ou de blocage de tous les administrateurs. Les identifiants break-glass doivent être conservés dans un coffre-fort physique, utiliser de longs mots de passe aléatoires, ne disposer d’aucune méthode MFA enregistrée et faire l’objet d’un audit renforcé à chaque utilisation.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que MFA exige un second facteur au-delà du mot de passe, ce qui réduit considérablement le risque de vol d’identifiants, que les stratégies Conditional Access appliquent des contrôles d’autorisation ou de blocage selon l’utilisateur, l’application, l’emplacement et les conditions de risque, et qu’Identity Protection utilise une évaluation du risque fondée sur l’apprentissage automatique pour déclencher automatiquement des contrôles d’accès. Nous allons maintenant étudier l’authentification unique et les identités externes dans Entra ID.