Commencez par les administrateurs et imposez-leur, via Conditional Access, l'authentication strength intégrée Phishing-resistant MFA. Elle n'autorise que Windows Hello for Business ou un identifiant de plateforme, une clé de sécurité FIDO2, ou l'authentification par certificat Entra (multifacteur). Le SMS et les approbations push ne satisfont plus la politique pour ces comptes sur les ressources qu'elle couvre, même si l'invite de mot de passe subsiste (voir Ce qui pose problème).
Pourquoi commencer par les admins
La présentation de l'authentification par Microsoft indique que le MFA fondé sur le SMS, les OTP par e-mail ou les applications d'authentification est exposé au phishing à distance, où l'attaquant vole des mots de passe ou des codes à usage unique sans toucher à l'appareil de l'utilisateur. Microsoft recommande à la place Windows Hello for Business, les passkeys (FIDO2), les clés de sécurité FIDO2 ou l'authentification par certificat. Un compte admin est l'endroit où un code volé coûte le plus cher, et une petite équipe n'en a qu'une poignée à migrer.
Méfiez-vous de l'option intégrée intermédiaire. Selon la documentation sur les authentication strengths, la strength Passwordless MFA inclut la connexion par téléphone avec Microsoft Authenticator. La strength Phishing-resistant, elle, ne l'inclut pas.
Préparer le tenant
Les passkeys (FIDO2) sont disponibles dans toutes les éditions d'Entra ID sans licence supplémentaire. Conditional Access nécessite Entra ID P1.
Les paramètres se trouvent sous Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). Il faut au minimum le rôle Authentication Policy Administrator. Trois points comptent :
- L'activation des profils de passkeys est irréversible. Vous ne pouvez pas faire marche arrière, et vos paramètres globaux actuels sont déplacés dans un profil Default. Jusqu'à trois profils, Default compris, sont pris en charge.
- Allow self-service set up doit être sur Yes, faute de quoi les utilisateurs ne peuvent pas enregistrer de passkey via Security info. C'est un paramètre global, non propre à un profil.
- L'enregistrement exige une validation MFA datant de moins de cinq minutes.
Pour les admins, l'exemple de la documentation est un profil avec le type de passkey Device-bound et Enforce attestation sur Yes. Device-bound signifie que la clé privée ne quitte jamais un appareil physique unique, comme une clé de sécurité ou Microsoft Authenticator. Les passkeys synchronisés ne prennent pas en charge l'attestation, et Microsoft précise de les considérer comme résistants au phishing, mais avec le niveau de sécurité des autres authentificateurs non attestés. Le texte du NIST exige à l'AAL3, son niveau le plus élevé, un authentificateur résistant au phishing avec une clé non exportable. Les clés device-bound sont donc la solution la plus proche parmi les options d'Entra.
Imposer avec une authentication strength
Créez une politique Conditional Access, ciblez vos rôles ou votre groupe d'admins, puis dans les contrôles d'octroi choisissez Require authentication strength. Sélectionnez Phishing-resistant MFA. Vous ne pouvez pas la combiner avec Require multifactor authentication dans la même politique, car la strength MFA intégrée équivaut à ce contrôle.
Les strengths intégrées ne sont pas modifiables, et Microsoft les met à jour lorsque de nouvelles méthodes apparaissent. Si vous avez besoin d'un ensemble figé de méthodes autorisées, créez une strength personnalisée.
Vous n'avez pas à désactiver le SMS pour tout le monde. La strength se superpose à la politique Authentication methods et la restreint pour un scénario donné. Le personnel peut conserver mot de passe et approbation push pour les ressources courantes, tandis que les admins sont soumis à la politique plus stricte.
Ce qui pose problème
Un admin saisit toujours un mot de passe en premier. Conditional Access est évalué après l'authentification initiale, donc la strength n'exige une méthode résistante au phishing qu'à ce moment-là.
Si un utilisateur se connecte avec un mot de passe comme méthode principale et que la strength exige Windows Hello for Business, cette méthode ne lui est pas proposée. Il doit relancer la session, sélectionner Sign-in options et choisir la méthode requise. Mentionnez-le dans vos consignes aux admins.
Deux contrôles agissent à des moments différents. Enforce attestation ne s'applique qu'à l'enregistrement : un passkey enregistré sans attestation n'est donc pas bloqué à la connexion une fois l'option activée. Réenregistrez ensuite les clés des admins. Les restrictions de clés par AAGUID s'appliquent à la fois à l'enregistrement et à la connexion, de sorte que retirer un AAGUID précédemment autorisé verrouille tous ceux qui ont enregistré ce modèle.
Le chevauchement de profils est permissif, et il joue sur l'enregistrement comme sur la connexion au niveau de la politique de passkeys. Lorsqu'un utilisateur relève de plusieurs profils, un passkey est autorisé s'il satisfait pleinement au moins l'un d'eux, sans ordre particulier. Un admin qui fait aussi partie d'un groupe « tous passkeys synchronisés ou device-bound » peut donc enregistrer et utiliser un passkey synchronisé, du moins du point de vue de la politique de passkeys. Les sources n'indiquent pas si la strength de Conditional Access l'accepte, alors testez ce cas.
Après l'activation, vérifiez le profil Default sous Enable and target. Si sa cible est All users et qu'il autorise les passkeys synchronisés, redirigez-le vers des groupes qui ne contiennent pas vos admins. N'excluez pas plutôt les admins dans la politique Passkey (FIDO2) : un groupe exclu est totalement bloqué pour l'enregistrement et la connexion FIDO2, et cela prévaut sur toute inclusion.
La fréquence de connexion et la strength peuvent être satisfaites à des moments différents. Avec une strength passkey et une fréquence de connexion d'une heure, une connexion par passkey effectuée il y a 24 heures, combinée à un déverrouillage Windows Hello aujourd'hui, satisfait les deux. Si vous comptez sur des fréquences courtes pour les admins, testez ce cas.
Temporary Access Pass figure dans la strength MFA, mais pas dans la strength résistante au phishing. Notre propre déduction, que les sources n'énoncent pas : un processus de récupération ou d'amorçage reposant sur un Temporary Access Pass ne satisfera pas la politique, il lui faut donc une exclusion ou une politique distincte. Décidez-le avant l'application, pas pendant l'incident.
Par où commencer
- Listez tous les comptes dotés d'un rôle admin et choisissez-en deux ou trois pour le groupe pilote.
- Activez les profils de passkeys, vérifiez la cible du profil Default, créez un profil admin avec Device-bound et Enforce attestation sur Yes, et ciblez-le uniquement sur le groupe pilote.
- Enregistrez au moins deux authentificateurs par admin pilote, par exemple une clé de sécurité et Windows Hello, et vérifiez que la connexion fonctionne avec chacun.
- Créez la politique Conditional Access avec la strength Phishing-resistant MFA pour le groupe pilote. Par bonne pratique générale (les pages Microsoft utilisées ici ne traitent pas des comptes break-glass), excluez les comptes d'accès d'urgence et donnez à chacun sa propre clé FIDO2.
- Étendez à tous les admins. Ne supprimez les passkeys enregistrés avant l'application de l'attestation qu'une fois que chaque admin a réenregistré une clé attestée, afin que personne ne soit verrouillé.
- Faites tester le résultat. Notre équipe de conseil peut examiner la politique, et un test d'intrusion montre si un chemin d'administration accepte encore une méthode plus faible.
