Aujourd’hui, on se retrouve pour tester ensemble une clef FIDO2 sur un environnement Microsoft Cloud. Fini les galères des mots de passe, place à une sécurité renforcée et simplifiée. Dans cet article, je vous partage mon expérience, étape par étape, de la configuration sur un tenant Microsoft à la vérification des connexions via USB et NFC. Venez découvrir comment, avec une approche à la fois technique et accessible, on peut repenser la manière de sécuriser nos identités en ligne.
Qu’est-ce que FIDO ?
FIDO, qui signifie Fast IDentity Online, désigne un ensemble de normes d’authentification qui utilisent la cryptographie à clé publique pour se passer des mots de passe traditionnels.
Concrètement, l’objectif de FIDO est de renforcer la sécurité en ligne en utilisant des méthodes d’authentification plus fiables et ergonomiques, comme les dispositifs matériels (clés de sécurité) ou l’authentification biométrique (empreintes digitales, reconnaissance faciale).
Pour moi, c’est une approche qui simplifie l’expérience utilisateur car, tout en augmentant considérablement la sécurité, ces passkeys sont interopérables, ce qui signifie qu’une seule passkey peut être utilisée sur plusieurs sites ou comptes.
D’ailleurs, j’avais déjà parlé de l’intégration d’une authentification FIDO2 pour le service Azure Virtual Desktop juste ici :
Qu’est-ce que l’Alliance FIDO ?
Créée en 2012, FIDO Alliance est une association d’entreprises du secteur technologique ayant pour objectif de changer la manière dont nous nous authentifions en ligne. L’idée de ce consortium est de se passer des mots de passe, souvent vulnérables, en favorisant des méthodes d’authentification plus sûres et plus simples à utiliser :
Pour résumer, FIDO Alliance réunit de nombreux acteurs du secteur (comme Google, Microsoft, mais pas que) pour développer des standards ouverts, tels que FIDO U2F et FIDO2, qui permettent par exemple d’utiliser des dispositifs matériels (clefs de sécurité) ou des méthodes biométriques pour s’authentifier.
FIDO vs U2F vs FIDO2 ?
Le protocole FIDO original, alias FIDO 1.0, était la première itération de la norme d’authentification FIDO. Publié en 2014, il visait à remplacer les mots de passe traditionnels par des données biométriques et des jetons matériels. Elle comportait à la fois FIDO UAF (Universal Authentication Framework) et FIDO U2F (Universal Second Factor).
En 2016, le World Wide Web Consortium (W3C) et la FIDO Alliance ont commencé à collaborer pour normaliser l’authentification FIDO. Cela a conduit au lancement de FIDO2 en 2018, qui offre une approche plus complète et standardisée de l’authentification sans mot de passe. De nombreux navigateurs célèbres, dont Firefox et Chrome, ont mis en œuvre la norme, ce qui a contribué à son adoption.
FIDO2 a deux composantes principales : WebAuthn et CTAP (Client to Authenticator Protocol). Ensemble, WebAuthn et CTAP offrent une expérience de connexion cryptographiquement sécurisée, pratique et interopérable.
En résumé, les principales différences entre FIDO 1.0 et FIDO2 sont la normalisation, la portée, l’interopérabilité et l’adoption. FIDO2 est un protocole plus complet et normalisé qui est pris en charge par tous les principaux navigateurs et systèmes d’exploitation, y compris Android, IOS, MacOS et Windows.
FIDO2.1 est une petite évolution de la spécification FIDO2 qui vise à combler certaines limites et à renforcer à la fois la sécurité et l’expérience utilisateur. Concrètement, FIDO2.1 apporte notamment :
Une gestion améliorée des PIN et des mécanismes d’authentification locales, avec des règles plus strictes pour éviter les codes trop faibles.
Des processus d’enrôlement et de récupération des identifiants optimisés, pour faciliter la réinitialisation ou le transfert sécurisé des clés.
Une meilleure interopérabilité entre les différents types d’authentificateur (qu’ils soient matériels ou intégrés à un appareil), ce qui simplifie leur déploiement dans des environnements hétérogènes.
En résumé, il ne s’agit pas d’un changement radical, mais plutôt d’un raffinement qui permet d’offrir une sécurité renforcée tout en rendant l’usage du système encore plus fluide et adaptable.
Quelles sont les méthodes de connexion d’une clef FIDO2 ?
USB-A et USB-C :
Pour les PC, on branche la clé directement dans un port USB-A ou USB-C.
Pour les smartphones, il est souvent possible de les utiliser via un câble OTG ou directement sur un port USB-C, selon le modèle.
NFC :
De nombreuses clés intègrent une puce NFC, ce qui permet une connexion sans contact avec des smartphones compatibles (par exemple, iPhone à partir d’iOS 13.3 et de nombreux appareils Android).
À noter toutefois que sur Android, les clés protégées par PIN ne supportent pas la connexion NFC.
La prise en charge des clés de passage de FIDO2.1 (à savoir les clés résidentes protégées par un code PIN) a été introduite dans le cadre de Google Play Services v23 et uniquement par le biais de la méthode de transport USB. Cela signifie donc que :
Android ne prend en charge les identifiants FIDO protégés par un code PIN que si Google Play Services est présent. Android ne prend pas en charge les informations d’identification FIDO protégées par un code PIN via NFC.
Quels sont les risques encourus si je perds ma clef FIDO2 ?
La perte de votre clé FIDO2 peut poser des problèmes d’accès à vos comptes, mais les risques de compromission sont fortement limités. En effet, ces clés reposent sur la cryptographie asymétrique : même si quelqu’un mettait la main sur votre clé, il ne pourrait pas extraire la clé privée qui reste protégée.
De plus, la plupart des dispositifs FIDO2 nécessitent un code PIN ou une authentification biométrique pour être utilisés, ce qui ajoute une couche de sécurité supplémentaire.
Néanmoins, il est important de prévoir une solution de secours. Par exemple, en enregistrant plusieurs clés ou en activant d’autres méthodes de récupération, vous pourrez rapidement révoquer une clé perdue et en associer une nouvelle, sans compromettre l’accès à vos comptes.
Dois-je acheter une licence payante d’Entra ID pour utiliser une clef FIDO2 ?
Non, il n’est pas nécessaire d’acheter une licence Entra ID spécifique pour utiliser une clé FIDO2 en authentification sans mot de passe.
Cette fonctionnalité est incluse dans toutes les éditions d’Entra ID, y compris la version gratuite, même si certaines fonctionnalités avancées (comme l’accès conditionnel) nécessitent des licences Entra ID Premium.
Qui sont Token2 ?
La société Token2 a vu le jour en 2014. Il s’agit d’une entreprise suisse spécialisée dans la cybersécurité, et plus précisément dans l’authentification multifactorielle.
Le siège de Token2 se situe à Versoix, dans la République et le Canton de Genève, en Suisse.
Pour faire simple, ils conçoivent et développent des solutions matérielles et logicielles qui rendent l’authentification en ligne à la fois plus sûre et plus pratique.
D’ailleurs, Token2 est aussi un membre certifié de l’alliance FIDO :
Token2, fier membre de l’Alliance FIDO, a obtenu son certificat FIDO initial en 2019 et fournit une variété de clés de sécurité FIDO depuis plus de 5 ans.
En plus des clés FIDO2 ordinaires, Token2 est ravie de présenter sa très attendue série PIN+, une ligne révolutionnaire de clés de sécurité FIDO2 qui a récemment reçu la certification de l’Alliance FIDO.
Ces clés de sécurité de pointe introduisent des règles avancées de complexité du code PIN qui redéfinissent les standards de sécurité.
Pour aller toujours plus loin dans la sécurité de leurs produits, Token2 a également fait l’objet d’un audit indépendant (réalisé par Compass) en 2024 sur le firmware open source (disponible sur GitHub) de leurs clés Token2 PIN+ (voir leur outil de test de PIN), confirmant leur robustesse et leur transparence.
Enfin, j’en profite pour dire un grand merci à Manon, Emin et Naila pour me permettre de tester vos produits !
Ce qui m’a séduit d’emblée sur cette clef FIDO2.1 R3, c’est la présence du triple combo USB-A, USB-C et NFC, ainsi que le support des normes FIDO et FIDO2.1( avec le support d’OpenPGP et d’OTP) :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser nos tests sur une clef FIDO2.1, il vous faudra disposer de :
Un tenant Microsoft
J’ai choisi dans la première partie de l’article de tester la mise en place d’une clef FIDO2 sur un tenant ne disposant d’aucune licence Entra ID Premium.
Pour vérifier si votre tenant dispose de licences ou non Entra ID Premium, je vous propose de commencer par vérifier cette information
Etape I – Configuration du tenant :
Allez dans la page suivante d’Entra afin de constater la présence, ou non, de licences Entra Premium sur votre tenant :
Ensuite, basculez l’onglet des propriétés afin de déterminer la méthode de sécurité appliquée sur votre tenant :
Enfin, vérifiez l’activation, ou non, de différentes méthodes d’authentification sur cette page :
Notre environnement est donc dans sa configuration la plus basique. Avant de modifier celle-ci, je vous propose de constater les méthodes de sécurité déjà disponibles sur notre utilisateur.
Etape II – Ajout de la méthode d’authentification FIDO2 :
Pour cela, rendez-vous sur la page suivante de votre utilisateur, puis cliquez sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Constatez la liste des méthodes d’authentification déjà accessibles à votre utilisateur :
Retournez sur la page des méthodes d’authentification Entra ID via cette page, puis cliquez-ici :
Activez la méthode FIDO2 :
Configurez au besoin les options de cette méthode, puis cliquez sur Sauvegarder :
Vérifiez le changement de statut pour cette méthode d’authentification :
Attendez environ 5 à 10 minutes avant de continuer la configuration de votre utilisateur.
Etape III – Ajout de la première clef FIDO2 :
Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez à nouveau sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Constatez l’apparition de nouvelles méthodes dans la liste de celles disponibles pour votre utilisateur :
Sélectionnez la méthode appelée Clef de sécurité :
Avant cela, Microsoft souhaite vérifier votre identité par une autre méthode MFA déjà en place, cliquez donc sur Suivant :
Réussissez le challenge MFA avec Microsoft Authenticator :
Une fois réussi, recommencez le processus d’ajout, puis cliquez-ici :
Cliquez sur Suivant :
Microsoft communique alors avec votre OS Windows afin de vérifier et d’enrôler la clef FIDO2 :
Attendez encore quelques secondes :
Confirmez les informations de compte, puis cliquez sur OK :
Cliquez sur OK :
Saisissez le code PIN déjà configuré sur votre clef FIDO2, puis cliquez sur OK :
Touchez physiquement la zone prévue à cet effet pour terminer :
Windows confirme le bon enrôlement de la clef FIDO2 chez Microsoft, cliquez sur OK :
Nommez votre clef FIDO2 afin de l’identifier par la suite plus facilement, puis cliquez sur Suivant :
Cliquez sur Terminer :
Constatez l’apparition de celle-ci dans les informations de sécurité de votre utilisateur :
Il est très fortement conseillé d’enrôler toujours 2 clefs afin d’utiliser la seconde en cas de secours.
Testons maintenant comment l’expérience utilisateur est impactée par l’ajout de cette méthode d’authentification FIDO2.
Etape IV – Test de connexion FIDO2 sur PC :
Sur votre poste, ouvrez un navigateur internet en session privée :
Au lieu de saisir le mot de passe de votre utilisateur, cliquez comme ceci :
Attendez quelques secondes :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Cliquez sur Oui :
Et vous voilà correctement authentifié sur le portail de Microsoft Office 365 :
Nous avons vu l’impact de l’authentification d’une clef FIDO2 pour un compte Cloud de Microsoft. Intéressons-nous maintenant à la nouvelle clef FIDO2 proposée par Token2 et ses différentes possibilités d’authentification.
Etape V – Ajout de la clef FIDO2 Token2 T2F2-Dual:
avant d’utiliser cette nouvelle clef FIDO2 pour un compte, il est nécessaire de lui configurer un code PIN.
Pour cela, rendez-vous dans le menu suivant des paramètres Windows :
Cliquez sur le bouton Gérer :
Touchez la zone prévue à cet effet de votre nouvelle clef FIDO2 :
Cliquez-ici pour configurer le code PIN :
Testez un code PIN simple à 4 caractères afin de constater le refus de la nouvelle clef FIDO2 d’accepter cette valeur trop courte :
Testez un code PIN reprenant une simple suite de chiffres à 6 caractères afin de constater un second refus pour accepter cette valeur trop simple :
Renseignez cette fois 6 caractères aléatoires afin de constater l’acceptation de la valeur complexe :
Si nécessaire, il vous est toujours possible de changer ce code PIN en cliquant ici :
Il vous sera demandé de renseigner l’ancien code PIN avant de pouvoir en configurer un nouveau dans le but de conserver les identités déjà configurées :
Retournez sur la page suivante de gestion de compte de votre utilisateur, puis cliquez sur le bouton suivant :
Cliquez-ici pour ajouter une nouvelle méthode d’authentification :
Sélectionnez à nouveau Clef de sécurité, puis repassez sur toutes les étapes afin que votre nouvelle clef FIDO2 apparaisse dans la liste de ses méthodes d’authentification :
Notre nouvelle clef FIDO2 est maintenant en place pour notre utilisateur.
Comme sa méthode d’authentification via le port USB est la même que pour la première clef, testons directement la possibilité de connexion via NFC depuis un smartphone.
Etape VI – Test de connexion NFC sur smartphone :
Si votre smartphone vous permet une connexion via NFC : ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :
Saisissez le compte de votre utilisateur, puis cliquez sur Suivant :
Sans même saisir son mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :
Le message suivant vous invite à rapprocher ou à connecter votre clef FIDO2 à votre smartphone :
Dans le cadre du NFC, approchez votre clef de sécurité FIDO2 en haut de votre smartphone comme ceci :
Retirez la clef, puis saisissez le code PIN de votre clef FIDO2 :
Le message suivant vous invite à rapprocher à nouveau votre clef FIDO2 à votre smartphone :
Rapprochez une seconde fois votre clef FIDO2 afin de confirmer l’authentification de votre compte, puis cliquez sur Oui :
Constatez la bonne connexion de votre utilisateur aux services de Microsoft :
Comme annoncé plus haut, certains smartphones de la marque Android ne permettent pas la connexion NFC à votre compte dans le cadre d’une clef FIDO2 protégée par un code PIN.
Etape VII – Test de connexion USB-C sur smartphone :
Si votre smartphone ne vous permet pas la connexion via NFC : ouvrez un navigateur internet en session privée, rendez-vous sur la page officielle de Microsoft office, saisissez le nom de compte, puis cliquez sur Suivant :
Sans même saisir de mot de passe, choisissez une méthode d’authentification par une clef de sécurité externe :
Cliquez sur le bouton ci-dessous :
Le message suivant vous invite à connecter votre clef FIDO2 à votre smartphone :
Connectez votre clef de sécurité FIDO2 via USB-C, puis saisissez le code PIN de celle-ci :
Touchez physiquement la zone prévue à cet effet pour terminer :
Cliquez sur Oui :
Constatez la bonne connexion de votre utilisateur aux services de Microsoft :
Etape VIII – Ajout d’un accès conditionnel FIDO2 :
Depuis votre portail Entra ID, rendez-vous dans le paramétrage des Accès conditionnels afin de constater le besoin de licence Entra ID Premium pour activer cette fonction :
Achetez une licence Entra ID Premium ou basculez sur un tenant en disposant déjà :
Vérifiez que la sécurité par défaut de votre tenant est désactivée au profit de l’accès conditionnel :
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :
Configurez celle-ci :
Puis créez votre nouvelle Police d’accès conditionnel :
Saisissez un nom à votre police, sélectionnez votre utilisateur de test, ajoutez l’application Azure, puis cliquez ici :
Autorisez l’accès sous réserve de satisfaire votre méthode d’authentification renforcée :
Ajoutez si besoin une fréquence d’authentification, puis créez votre police d’accès conditionnel :
Attendez quelques minutes, ouvrez un navigateur internet en session privée, puis rendez-vous sur la page officielle de Microsoft office :
Saisissez le nom et le mot de passe de votre compte de test, puis cliquez comme ceci :
Vous voilà correctement authentifié sur le portail de Microsoft Office 365 :
Toujours en navigation privée, ouvrez un nouvel onglet pour vous rendre sur le portail Azure, puis constatez le besoin d’un complément d’authentification FIDO2 :
Saisissez le code PIN de votre clef FIDO2 :
Touchez votre clé FIDO2 sur la zone prévue à cet effet :
Vous voilà correctement authentifié sur le portail Azure :
Avant de conclure cet article, je trouvais intéressant de parler de certains outils très pratiques et mis à disposition par Token2 sur leur site.
Celui-ci vous permet de tester en direct l’enregistrement et l’authentification via des clés FIDO2 et passkeys. Concrètement, il offre une expérience pratique pour :
Enregistrement (Registration) : Vous pouvez inscrire votre clé de sécurité (physique ou intégrée, c’est-à-dire un authentificateur de plateforme) en utilisant l’API WebAuthn. Lorsque la clé clignote, il suffit de toucher le bouton, scanner l’empreinte ou utiliser le NFC (pour les appareils compatibles) pour finaliser l’inscription.
Authentification (Login) : Une fois la clé enregistrée, l’outil simule un processus de connexion sécurisé. Vous pouvez tester différentes configurations de demande de PIN (toujours, si un PIN est défini, ou jamais) pour voir comment cela influence le comportement de l’authentification.
L’outil fido2-manage est un utilitaire de gestion pour les clés de sécurité conformes à la norme FIDO2.1. Concrètement, il permet de :
Lister les dispositifs connectés : Afficher la liste des clés FIDO2.1 détectées.
Afficher des informations détaillées : Consulter les données techniques de la clé (modèle, AAGUID, certificats d’attestation, etc.).
Gérer les passkeys : Visualiser et supprimer les clés résidentes (passkeys) stockées sur l’appareil.
Configurer ou modifier le PIN : Définir, changer ou forcer une modification du code PIN de la clé.
Réinitialiser la clé : Effectuer une réinitialisation aux paramètres d’usine (en notant que cette opération est possible uniquement dans un court laps de temps après la connexion).
Conclusion
En fin de compte, cette aventure avec la clef FIDO2, notamment la PIN+ Dual Release3, m’a prouvé que la sécurité peut être à la fois robuste et intuitive. Que ce soit pour se connecter via USB ou NFC, l’expérience utilisateur reste fluide et rassurante.
Tester ces solutions, c’est un peu comme prendre un virage vers l’avenir de l’authentification : simple, efficace et sans prise de tête.
Merci d’avoir suivi ce test avec moi, et à très bientôt pour de nouvelles explorations tech !
En cette fin juin 2024, Microsoft nous partage un peu plus d’informations sur la future MFA obligatoire à venir pour Azure à partir de juillet 2024. Plusieurs grandes étapes sont maintenant mentionnées et intégrées dans un planning qui démarre dès cet été et se terminera début 2025. De plus, Microsoft nous propose également donc quelques outils pour nous y préparer.
Un second post sur le Tech Community est apparu hier sur ce même sujet, et nous donne quelques informations sur les 2 phases de cette obligation liée à Azure :
Phase 1 – À partir de juillet 2024 : La notification puis l’obligation de la MFA pour le portail Azure sera progressivement étendue à tous les tenants.
Phase 2 – À partir de début 2025 : La notification puis l’obligation de la MFA aux outils de commande liés à Azure : CLI, Azure PowerShell et les outils Infrastructure as Code (IaaC) sera progressivement étendue à tous les tenants.
Partant de ces informations, nous pouvons en déduire les points suivants :
Portail Azure : Le portail Azure est utilisé par les humains, il faudra alors former les utilisateurs et configurer pour chacun d’entre eux une méthode MFA.
Autres outils : D’autres outils (CLI, Cloud Shell, …) sont utilisés par les humains et certains applications. Ces dernières pourront elles faire l’objet d’une bascule vers des identités managés ou des comptes de service.
Impact progressif : Les entreprises utilisant Azure doivent se préparer à une transition progressive des tenants. Elles auront le temps d’ajuster leurs configurations et de résoudre les problèmes potentiels avant que l’implémentation complète ne soit réalisée.
Microsoft a t-il prévu de notifier les administrateurs Azure ?
Microsoft a privilégié la notification des administrateurs globaux 60 jours avant la mise en application des phases 1 et 2. Cela sans doute pour laisser les entreprises organiser les messages et notifications en interne aux personnels Azure impactés par cette mesure.
Le compte à rebours de la mise en application pour votre/vos tenant(s) ne commence pas tant que vous n’avez pas reçu cette première notification de notre part. En outre, nous enverrons des rappels périodiques aux administrateurs globaux à intervalles réguliers entre la première notification et le début de la mise en application pour votre/vos tenant(s).
Pourrons-nous déroger temporairement à cette règle pour un tenant ?
Les mails de notification envoyés par Microsoft devraient comporter un lien pour activer une période de grâce, afin de pouvoir gérer les imprévus :
La première notification de notre part indiquant la date de mise en application pour votre/vos tenant(s) inclura également un lien pour demander la période de grâce. Des détails supplémentaires sur les types de clients, les cas d’utilisation et les scénarios éligibles à la période de grâce seront inclus dans la notification.
MFA pour tout Azure, mais vraiment pour tout le monde ?
Microsoft avait déjà été clair sur ce point, j’en avais également parlé dans mon précédent article :
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement.
Malgré cette information, une confusion a déjà pu s’installer, et c’est pour cela que ce second post de Microsoft reprécise que les utilisateurs finaux non gestionnaires d’Azure ne seront pas impactés :
Les utilisateurs finaux qui accèdent à des applications, des sites web ou des services hébergés sur Azure, mais qui ne se connectent pas au portail Azure, à la CLI ou à PowerShell, ne sont pas soumis à cette exigence de Microsoft. Les exigences d’authentification pour les utilisateurs finaux seront toujours contrôlées par les propriétaires de l’application, du site web ou du service.
Quid des accès conditionnels d’Entra ID ou de la sécurité par défaut ?
Microsoft a décidé d’implémenter ce contrôle MFA en amont des mesures de sécurité actuelles :
Sécurité par défaut activée : aucun changement car la MFA est déjà requise pour accéder aux outils Azure.
Accès conditionnel Azure : une police d’accès conditionnel plus restrictive et nécessitant une authentification plus forte que cette nouvelle règle sera appliquée en priorité.
Quid des comptes « brise-glace » ?
En mai dernier, Microsoft ne donnait pas encore de méthodes spécifiques pour ces comptes d’urgence. C’est maintenant chose faite :
Nous avons pris connaissance de vos questions concernant les comptes « verre cassé » ou « accès d’urgence ». Nous recommandons de mettre à jour ces comptes pour qu’ils utilisent FIDO2 ou l’authentification basée sur un certificat (lorsqu’elle est configurée en tant qu’AMF) au lieu de s’appuyer uniquement sur un mot de passe long. Ces deux méthodes satisferont aux exigences de l’AMF.
Pour éviter les soucis de connexion le jour J, Microsoft propose un outil de type tableau de bord, et une commande PowerShell d’extraction sous format EXCEL. Ces deux outils donne plus de visibilité sur les utilisateurs Azure concernés et mal préparés. Voici les deux liens directs mis à disposition par Microsoft :
Authentifiez-vous avec un compte disposants des autorisations nécessaires :
Acceptez les permissions demandées :
Une fois l’authentification terminée, fermez la fenêtre du navigateur :
Attendez que l’export Excel se termine :
Ouvrez le fichier Excel généré :
Constatez sur le premier onglet un tableau récapitulatif des utilisateurs qui se sont connectés au portail Azure, à Azure CLI ou à Azure PowerShell au cours des 30 derniers jours en interrogeant les journaux de connexion et de leur méthodes MFA enregistrées :
✅ MFA Capable + Signed in with MFA : L’utilisateur a enregistré des méthodes d’authentification MFA et s’est connecté avec succès au moins une fois à Azure en utilisant MFA.
✅ MFA Capable : L’utilisateur a enregistré des méthodes d’authentification MFA mais s’est toujours connecté à Azure en utilisant l’authentification à facteur unique.
❌ Not MFA Capable : L’utilisateur n‘a pas encore enregistré de méthode d’authentification multifacteur et ne s’est pas connecté à Azure à l’aide de MFA.
Constatez sur le second onglet un graphique et des totaux des utilisateurs prêts ou non :
Conclusion – Comment se préparer avant le jour J ?
Commencez dès à présent à créer une nouvelle règle d’accès conditionnel équivalente à la future implémentation prévue par Microsoft. Il existe un template de police d’accès conditionnel très proche du résultat attendu :
Cette police cible la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement est un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Vous pourrez par la suite changer son statut sur ON :
Microsoft vient d’annoncer, via un article posté sur le Techcommunity, une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous! Quand cela va arriver ? Qu’est-ce que cela implique ? Ces questions et bien d’autres encore sont légitimes. Tentons d’y voir plus clair ensemble.
Dans cet article sous forme de FAQ, je vous propose de commencer quelques notions important :
L’utilisation d’un mot de passe uniquement ne protège pas complètement des attaques. Si le mot de passe est faible ou s’il a été exposé ailleurs, un attaquant peut l’utiliser pour y accéder. Quand vous exigez une deuxième forme d’authentification, la sécurité est renforcée parce que ce facteur supplémentaire n’est pas un élément qu’un attaquant peut facilement obtenir ou dupliquer.
La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Entra ID impose de mettre en place les 3 méthodes d’authentification suivantes :
Un élément que vous connaissez (ex. mot de passe)
Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
Un élément qui vous définit (ex. identifiant biométrique, tel qu’une empreinte digitale)
Voici l’écran de configuration utilisateur d’une méthode MFA possible :
Quelle licence est nécessaire pour la disposer d’une MFA ?
Les choses ont quelque peu évolué ces dernières années chez Microsoft. Les licences Entra ID présentes et assignées aux utilisateurs concernés sont le point de départ aux méthodes de MFA disponibles.
Cette information au niveau tenant est disponible sur la page principale d’Entra ID :
Entra ID Gratuit : paramètres de sécurité par défaut activés
Entra ID Gratuit
Office 365
Entra ID P1
Entra ID P2
Protection des comptes avec authentification multifacteur
●
● (comptes d’administrateur général uniquement)
●
●
●
Application mobile comme second facteur
●
●
●
●
●
Appel téléphonique comme second facteur
●
●
●
Le SMS comme deuxième facteur
●
●
●
●
Contrôle d’administration sur les méthodes de vérification
●
●
●
●
Alerte de fraude
●
●
Rapports MFA
●
●
Messages de bienvenue personnalisés pour les appels téléphoniques
●
●
ID d’appelant personnalisé pour les appels téléphoniques
●
●
Adresses IP approuvées
●
●
Mémoriser MFA pour les appareils fiables
●
●
●
●
MFA pour les applications locales
●
●
Accès conditionnel
●
●
Accès conditionnel en fonction du risque
●
Autrement dit, un tenant même gratuit (ou non) et ayant la sécurité par défautactivée dispose d’une MFA accessible à tous ses utilisateurs :
Tous les utilisateurs d’un locataire Microsoft Entra ID Gratuit peuvent utiliser l’authentification multifacteur Microsoft Entra à l’aide des paramètres de sécurité par défaut. L’application d’authentification mobile peut être utilisée pour l’authentification multifacteur Microsoft Entra lors de l’utilisation des paramètres de sécurité par défaut Microsoft Entra ID Gratuit.
Les paramètres de sécurité par défaut peuvent être activés dans le niveau Microsoft Entra ID Free. Avec les paramètres de sécurité par défaut, tous les utilisateurs sont activés pour l’authentification multifacteur à l’aide de l’application Microsoft Authenticator. Il n’est pas possible d’utiliser la vérification par SMS ou appel téléphonique avec les paramètres de sécurité par défaut, mais uniquement l’application Microsoft Authenticator.
Mais pourquoi alors payer pour un service MFA disponible gratuitement ?
L’activation de la sécurité par défaut sur un tenant est gratuite, mais reste non personnalisable. Microsoft recommande d’ailleurs une utilisation agile de la MFA grâce à l’utilisation de polices d’accès conditionnel, disponibles dans les licences Microsoft Entra ID P1 ou P2.
Un précédent article dédié aux accès conditionnels est disponible juste ici :
Existe-t-il des différentes configurations MFA possibles sur un tenant ?
Pour rappel, il est actuellement possible de configurer le challenge MFA via 3 méthodes distinctes :
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur (per-user MFA)
Important : N’activez pas ou n’appliquez pas l’authentification MFA par utilisateur si vous utilisez également des polices d’accès conditionnel.
Stratégie
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
●
●
Flexibilité de la configuration
●
Fonctionnalité
Exempter les utilisateurs de la stratégie
●
●
Authentification par appel téléphonique ou SMS
●
●
●
S’authentifier par Microsoft Authenticator et jetons logiciels
●
●
●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
●
●
Bloque les protocoles d’authentification hérités
●
●
●
Les nouveaux employés sont automatiquement protégés
●
●
Déclencheurs MFA dynamiques en fonction des événements à risque
●
Stratégies d’authentification et d’autorisation
●
Configurable en fonction de l’emplacement et de l’état de l’appareil
●
Prise en charge du mode « Rapport seul »
●
Possibilité de bloquer complètement les utilisateurs/services
●
Attention la méthode appelée Authentification multifacteur par utilisateur ou Per-user MFA est vouée à disparaitre :
En mars 2023, nous avons annoncé la dépréciation de la gestion des méthodes d’authentification dans les stratégies héritées de l’authentification multifacteur et de la réinitialisation de mot de passe en libre-service (SSPR). À compter du 30 septembre 2025, les méthodes d’authentification ne pourront pas être managées dans ces stratégies MFA et SSPR héritées.
Peut-on migrer d’une configuration MFA à une autre ?
A cause de ce décommissionnement prévu pour 2025, Microsoft a déjà mis à disposition une documentation expliquant différentes étapes pour assurer une transition réussie :
Le SSPR (Réinitialisation du mot de passe en libre-service) et l’ancienne méthode MFA seront donc gérés par les Méthodes d’authentification unifiées :
Qu’est-ce qui se passe en juillet 2024 ?
La nouvelle est passée un peu inaperçue, mais juillet 2024 marque un pas important pour la sécurité Azure :
En juillet (2024), les équipes Azure commenceront à déployer des mesures de sécurité supplémentaires au niveau des locataires pour exiger l’authentification multifactorielle (MFA).
Autrement dit, le déploiement de cette règle MFA sera progressif et concernera à terme l’ensemble des tenants hébergés sur le Cloud public de Microsoft.
Quels sont les services impactés par ce changement ?
Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement. Enfin, gardez à l’esprit qu’Azure est accessible via différentes méthodes, et seront donc toutes concernés :
Portail Azure
CLI
PowerShell
Terraform
À partir de juillet 2024, un déploiement progressif de cette application pour le portail uniquement commencera. Une fois le déploiement terminé pour le portail, un déploiement progressif similaire commencera pour CLI, PowerShell et Terraform.
Il s’agit donc d’assurer un contrôle MFA systématique afin de protéger les actions en relation avec la gestion des ressources Azure.
Quelles seront les méthodes de MFA possibles pour Azure ?
Les méthodes MFA classiques suivantes pourront être utilisées pour l’authentification Azure :
Microsoft Authenticator
Authenticator Lite (dans Outlook)
Windows Hello Entreprise
Clé de sécurité FIDO2
Token matériel OATH (préversion)
Token logiciel OATH
SMS
Appel vocal
Quelles sont les identités concernées / non concernées ?
Merci à John Savill pour ce schéma expliquant l’impact entre tous les types d’identités possibles sur Entra ID :
Sont donc concernées :
Toutes les identités humaines accédant à Azure dans le cadre de l’administration de ressources (membres et invités)
Sont donc non concernées :
Principaux de services
Identités managées (user ou système)
Comptes basés sur des tokens et utilisés pour l’automatisation
Un travail chez les utilisateurs est donc nécessaire. Mais un contrôle est aussi à prévoir sur les process automatisés utilisant des identités utilisateurs au lieu de des principaux de service ou d’identités managées.
Comment se rendre compte de l’impact avant le jour J ?
Après investigations, Il existe un template de police d’accès conditionnel qui semblerait très proche du résultat attendu par l’évolution de Microsoft prévue pour juillet 2024 :
Cette police semble bien cibler la gestion des ressources Azure :
La mise en place de cette police en mode Report seulement serait alors un premier pas vers la compréhension de ce qui va se passer sur votre environnement :
Conclusion
Dans tous les cas, gardez en tête les points suivants, et je ne peux que vous conseiller de prendre les devants dès que possible :
Microsoft recueille encore les feedbacks pour certains scénarios tels que les comptes « break-glass ».
Commencez à examiner les identifiants Entra utilisés pour les opérations de management, développement et les accès API à Azure Resource Manager.
Si nécessaire, remplacer les identités des utilisateurs par des principaux de service ou des identités managées.
Cette semaine, Microsoft vient juste d’annoncer la disponibilité générale (GA) de fonctionnalités récentes liées à l’Accès Conditionnel, et très présent au cœur d’Entra ID. L’ajout de tableaux de bord sur plusieurs ressources (utilisateurs, périphériques et applications) faciliteront grandement le contrôle de la bonne couverture des polices d’accès conditionnels sur les besoins.
Tous les environnements informatiques sont en quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers du Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations sécuritaires à gérer.
Le périmètre de sécurité moderne s’étend au-delà du périmètre réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations utilisent désormais des signaux basés sur l’identité dans le cadre de leurs décisions de contrôle d’accès.
L’accès conditionnel repose sur un certain nombre de signaux ou paramètres d’entrée. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :
Emplacement (adresse IP)
Appareil (OS, version, conformité, …)
Utilisateur Entra ID
Application interrogée
IA (Détection des risques en temps réel géré par Entra ID Identity Protection)
Qu’est-ce qu’une Décision pour Entra ID ?
La décision est le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est possiblement question de bloquer l’accès à l’utilisateur, ou de l’autoriser selon des conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :
Exiger une authentification multifacteur (cas plus utilisé)
Exiger que l’appareil soit marqué comme conforme
Exiger un appareil joint en hybride à Entra ID
Exiger une stratégie de protection des applications
Qu’est-ce qu’une Option d’application pour Entra ID ?
Ces options apportent une supervision de session et des accès de l’utilisateur telles que :
Empêcher l’exfiltration des données
Protéger lors du téléchargement
Empêcher le chargement de fichiers sans label
Bloquer les programmes malveillants potentiels
Surveiller les sessions utilisateur pour la conformité
Bloquer l’accès
Doit-on disposer de licence pour utiliser l’accès conditionnel ?
Rappel important : Mi-juillet 2023, Microsoft a annoncé renommer son service Azure AD (Azure Active Directory). Ce changement est encore en cours et devrait être finalisé pour la fin de cette année. Cette simplification de dénomination est en cohérence avec le périmètre de la gestion identitaire élargie et gérée par le Cloud de Microsoft.
Cela a aussi pour conséquence un léger changement de nom de certaines licences :
L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Microsoft Entra ID Premium P1/P2. Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :
Microsoft Entra ID Premium P1
Microsoft Entra ID Premium P2
Enterprise Mobility + Security E3
Enterprise Mobility + Security E5
Microsoft 365 Business Premium
Microsoft 365 A3
Microsoft 365 A5
Microsoft 365 F1
Microsoft 365 F3
Microsoft 365 F5 Security
Microsoft 365 F5 Security + Compliance
Je vous remets également le lien vers le site très utile créé par Aaron Dinnage :
Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?
Cette question me revient très souvent 😉. Il faut savoir que cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :
Certains services clients ne sont actuellement pas en mesure de limiter les avantages à des utilisateurs spécifiques. Nous vous recommandons d’acquérir des licences pour tout utilisateur dont vous avez l’intention de bénéficier et/ou d’accéder au service.
Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.
Maintenant que la partie licence est clarifiée, nous allons pouvoir nous intéresser aux principales fonctionnalités de l’accès conditionnel.
Pour vous rendre sur les règles d’accès conditionnel, allez sur la page suivante d’Entra ID dédiée :
Voici quelques fonctionnalités de l’accès conditionnel d’Entra ID que je vous propose d’étudier :
La page d’accueil de l’accès conditionnelle a été revue pour afficher plusieurs informations essentielles aux équipes IT :
C’est vraiment ce qui manquait à ce service : la visibilité. Il est maintenant beaucoup plus simple de comprendre d’un rapide coup d’œil les éléments suivants :
Polices actives ou non : les polices d’accès conditionnel ont 3 statuts possibles. Le mode « Rapport seulement » est utile pour contrôler l’impact durant une phase de test sans perturber les utilisateurs.
Utilisateurs : Affiche le nombre d’utilisateurs ayant pu s’authentifier sans passer par aucune police d’accès conditionnel.
Périphériques: Affiche le nombre de poste étant non managés ou non conformes.
Applications : lien vers une liste des applications couvertes et non couvertes par une police d’accès conditionnel
Par exemple, un clic sur la première rubrique affiche le journal d’événements d’ouverture de session avec les filtres adéquats :
Un clic sur les applications ou sur l’onglet Couverture montre 2 différents tops applications :
Top des applications non couvertes par un accès conditionnel
Top des applications couvertes par un accès conditionnel
Là encore, un clic est possible pour basculer à nouveau sur le journal des événements d’ouverture de sessions afin d’identifier plus facilement les utilisateurs concernés par l’application ciblée :
Microsoft a même pensé au graphique afin d’améliorer la prise de vue dans son ensemble de ce que représente les accès conditionnés à ceux en étant dépourvues :
Voici une nouvelle vidéo qui résume bien ce nouvel écran :
Fonctionnalité II – Création d’une police :
Le véritable moteur de l’accès conditionnel d’Entra ID est : la police.
Depuis longtemps, il est possible de créer une police d’accès conditionnel depuis une feuille blanche. Vous devrez alors choisir parmi toutes les options disponibles dans les sections suivantes :
Utilisateur(s) : cible la police sur un utilisateur, un groupe d’utilisateurs ou même des utilisateurs selon leurs rôles. Il est même possible d’exclure des utilisateurs selon ces mêmes règles.
Destination(s) cible(s) : cible une ou plusieurs applications Cloud créées sur votre tenant. Là encore, Il est même possible d’exclure des applications si nécessaire.
Condition(s) : ajoute des conditions (ou signaux) présents au moment de l’authentification. Comme le risque calculé par Entra ID Identity Protection ou encore la localisation du poste.
Condition(s) d’accès : détermine si l’accès est bloqué et cela même si le processus d’authentification est réussi, ou conditionne l’accès selon des critères supplémentaires : MFA, poste conforme…
Contrôle(s) de session : renforce si besoin les conditions de persistance de la session au sein de l’application.
Fonctionnalité III – Création d’une police à partir d’un modèle :
Microsoft a proposé il y a plusieurs mois déjà de simplifier la création de police d’accès conditionnel en proposant des modèles de départ :
Ces modèles de base sont classifiées dans les 5 sections suivantes :
Vous pouvez à tout moment changer le statut de votre police. Cela permet de désactiver celle-ci si les résultats sécuritaires obtenus ne sont pas ceux attendus :
Fonctionnalité IV – Test d’une police avec la fonction « Et si » :
Tester une police d’accès conditionnel est possible avec un utilisateur de test ou via la fonction Et si. Cette second option est très utile si l’utilisateur n’est pas disponible ou si le scénario de test demande des conditions très particulières.
Un grand nombre de paramètres (signaux) sont disponibles pour réaliser des tests dans tous les sens :
Et le résultat ne se fait pas attendre, notre nouvelle police d’accès conditionnel créée à partir d’un modèle joue bien son rôle :
Fonctionnalité V – Déclaration de lieux nommés :
Par exemple, quand des lieux sont considérés comme des sites de l’entreprise et que la sécurité réseau est géré par le service IT, il devient utile de les renseigner ici :
Cela permet alors de créer des règles d’accès conditionnel plus précises en incluant ou excluant ces lieux :
Fonctionnalité VI – Configuration d’une MFA renforcée :
L’authentification multi-facteurs est devenue la norme pour s’authentifier sur Internet. Mais toutes les méthodes multi-facteurs ne se valent pas. Microsoft propose de laisser le choix des méthodes MFA aux administrateurs :
Par exemple, ils peuvent faire en sorte que seules les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible. Toutefois, pour accéder à une ressource non sensible, ils peuvent autoriser des combinaisons d’authentification multifacteur (MFA) moins sécurisées, telles que mot de passe + SMS.
Plusieurs méthodes de MFA renforcées sont déjà disponibles et il est aussi possible de créer les siennes :
Il suffit après d’appeler ces méthodes de MFA renforcées dans la configuration de la police d’accès conditionnel :
Conclusion :
L’accès conditionnel sous Entra ID a réussi s’imposer comme la référence de base dans l’autorisation d’accès aux ressources de l’entreprise. Les personnalisations possibles et la prise en compte d’exclusions apporte beaucoup de souplesse et évite la fatigue sécuritaire chez les utilisateurs. Nul doute que d’autres fonctionnalités sont encore à venir 😎.
