Déployer FIDO2 pour comptes à privilèges
Déployer FIDO2 pour comptes à privilèges
Section intitulée « Déployer FIDO2 pour comptes à privilèges »L’authentification multifacteur (MFA, Multi-Factor Authentication) par FIDO2 (Fast IDentity Online 2) doit devenir le facteur par défaut des comptes qui administrent l’identité, les infrastructures, les environnements cloud et les chaînes de livraison. Le compromis est net : on gagne une résistance réelle au phishing et aux proxys de relais, on paie en inventaire, en procédures de secours et en discipline d’exploitation.
→ Lire l’explication complète de la marmotte
Décision d’architecture FIDO2 pour les privilèges
Section intitulée « Décision d’architecture FIDO2 pour les privilèges »FIDO2 associe une preuve détenue par l’utilisateur à un service précis. Le navigateur transmet l’origine du site au dispositif d’authentification, qui refuse de signer pour une origine différente. Un clone de portail, un lien dans un courriel ou un proxy de phishing ne peut donc pas réutiliser cette preuve sur le vrai domaine. C’est précisément ce que les codes à usage unique et les notifications mobiles ne garantissent pas.
La recommandation est tranchée : imposer des clés matérielles FIDO2 itinérantes pour les comptes à privilèges de niveau critique, et refuser les facteurs fondés sur le téléphone comme solution principale. Les codes par message, les applications générant des codes temporaires et les validations par notification restent récupérables par ingénierie sociale ou relayables en temps réel. Le bouton « approuver » sur un téléphone est devenu un sport de combat contre la fatigue humaine.
Un authentificateur de plateforme, intégré au poste de travail ou au téléphone, peut convenir aux comptes d’administration de périmètre limité si le poste est géré, chiffré, mesuré et lié à une identité de terminal. Pour l’administration de l’annuaire, de l’Identity Provider (IdP), du tenant cloud, de l’autorité de certification ou de la chaîne de signature, retenir deux clés matérielles distinctes par identité : une active, une de secours. Une clé synchronisée dans un coffre grand public ne fournit pas le même contrôle de possession ni le même modèle de récupération.
FIDO2 ne remplace pas la séparation des comptes. Un administrateur doit utiliser une identité nominale sans privilège pour la messagerie et la navigation ordinaire, puis une identité dédiée pour l’administration. Sinon, on protège la serrure de la salle des machines tout en laissant les clés sur le bureau de la cafétéria.
Le protocole WebAuthn (Web Authentication) est l’interface utilisée par les navigateurs et les applications web pour FIDO2. Le fournisseur d’identité doit vérifier au minimum l’identifiant du site, l’identifiant de la preuve publique enregistrée, le défi cryptographique envoyé pour la session et, lorsque le risque le justifie, les règles d’attestation du dispositif. La signature prouve la possession de la clé privée, qui ne doit pas sortir de la clé matérielle.
Priorisation des comptes à privilèges
Section intitulée « Priorisation des comptes à privilèges »Ne pas lancer une campagne globale avant de traiter les identités qui permettent de contourner toute la campagne. La priorisation suit la capacité de prise de contrôle, pas le titre du poste ni la couleur du badge.
- Niveau 0 : administration de l’annuaire, du fournisseur d’identité, des domaines, des contrôleurs de fédération, des coffres de secrets, des autorités de certification et des HSM (Hardware Security Module). Ces comptes peuvent créer des identités, modifier des politiques ou signer des jetons.
- Plan de contrôle cloud : propriétaires d’organisation, administrateurs de tenant, comptes de facturation capables de rétablir des accès, administrateurs de journalisation et de réseau.
- Production et livraison : administrateurs Kubernetes, hyperviseurs, bastions, consoles de sauvegarde, registries d’images, administrateurs CI/CD (Continuous Integration/Continuous Delivery), gestionnaires de secrets et comptes de signature de code.
- Accès à fort impact métier : support capable de réinitialiser des facteurs, administrateurs de messagerie, opérateurs de données sensibles et gestionnaires de comptes à privilèges.
- Population générale : migration ultérieure, avec une politique distincte pour les cas sans navigateur ou sans terminal géré.
Les comptes de service non interactifs ne doivent pas recevoir une clé FIDO2 fictive pour cocher une case de conformité. Ils doivent être éliminés lorsqu’ils sont inutiles, remplacés par des identités de charge de travail à durée courte, ou limités à des secrets stockés dans un coffre avec rotation. Une authentification humaine n’est pas un pansement pour une automatisation mal conçue.
Constituer pour chaque compte prioritaire un enregistrement contenant le propriétaire, le rôle, les applications accessibles, les facteurs autorisés, les clés de secours, la dernière vérification et la procédure de récupération. Cet inventaire rejoint les règles de gestion des identités et doit être corrélé aux droits effectifs, pas aux groupes théoriques. Un groupe vide sur un diagramme ne bloque aucune élévation réelle.
Prérequis de plateforme et règles d’enrôlement
Section intitulée « Prérequis de plateforme et règles d’enrôlement »Avant l’enrôlement, vérifier que l’IdP prend en charge WebAuthn pour les parcours d’authentification, les élévations de privilège et la récupération de compte. Beaucoup de produits savent afficher un bouton de sécurité, puis retombent sur un code par courriel pour réinitialiser le facteur. Cette retombée annule le modèle de menace : le chemin de secours devient le chemin d’attaque.
Exiger les conditions suivantes :
- domaines HTTPS stables, avec les origines WebAuthn explicitement autorisées ;
- navigateur récent et OpenSSH (Secure Shell) version 8.2 ou ultérieure pour les accès administratifs par terminal ;
- au moins deux clés certifiées FIDO2 par identité critique, provenant de lots distincts lorsque l’exigence de continuité est élevée ;
- code PIN (Personal Identification Number) activé sur la clé, avec vérification locale de l’utilisateur ;
- poste d’administration dédié ou fortement durci, sans navigation quotidienne ni messagerie ;
- journalisation centralisée des enrôlements, suppressions, échecs et modifications de politiques ;
- procédure de récupération séparée de l’équipe qui administre les comptes courants.
L’attestation permet à un service de vérifier le type et, selon le modèle, la provenance d’un authentificateur. Elle est utile pour interdire des dispositifs inconnus dans le périmètre critique, mais elle n’est pas une preuve magique de sécurité. Les chaînes d’attestation évoluent, les politiques de confidentialité limitent leur disponibilité et un matériel approuvé peut être volé. Autoriser une liste de modèles sans gérer la possession et le cycle de vie revient à collectionner des numéros de série avec une ferveur administrative touchante.
Prévoir un groupe pilote qui couvre les navigateurs, les systèmes d’exploitation, les accès réseau et les comptes de secours. Le pilote ne valide pas seulement que l’enrôlement réussit : il doit vérifier une perte de clé, une désactivation de compte, une révocation, un changement de poste, une panne de l’IdP et un accès depuis un réseau filtré.
Déploiement progressif et politiques d’accès conditionnel
Section intitulée « Déploiement progressif et politiques d’accès conditionnel »Commencer par activer FIDO2 en mode autorisé, sans encore bloquer les facteurs existants. Enrôler les deux clés, vérifier les connexions sur les applications critiques, puis faire appliquer la règle exclusivement au groupe pilote. Après validation des parcours de récupération, étendre par niveau de privilège. Ne jamais retirer les facteurs historiques avant que la seconde clé soit testée sur au moins deux chemins d’accès pertinents.
Pour les comptes critiques, la politique doit refuser les facteurs relayables, imposer une authentification récente pour les opérations sensibles et exiger une nouvelle preuve lors de l’élévation. Le SSO (Single Sign-On) réduit les demandes d’authentification, mais une session SSO compromise reste une session valable. Limiter sa durée, lier son émission à un poste conforme lorsque la plateforme le permet, et protéger les opérations d’administration par une réauthentification.
Les comptes d’urgence doivent rester rares, nominativement responsables et surveillés. Une procédure de récupération qui accepte un appel au support et quelques réponses publiques n’est pas une récupération, c’est une porte latérale avec un panneau « discrétion appréciée ». Pour les périmètres critiques, exiger une validation hors bande par deux responsables, tracer l’événement et imposer une rotation immédiate des facteurs après usage.
Relier ce chantier à la réduction des mécanismes hérités. Désactiver l’authentification faible, notamment les accès LDAP (Lightweight Directory Access Protocol) anonymes ou en clair, évite qu’un compte protégé par FIDO2 soit contourné par une interface plus ancienne : durcir LDAP.
Exemple OpenSSH avec clé FIDO2
Section intitulée « Exemple OpenSSH avec clé FIDO2 »L’accès administrateur SSH doit utiliser une clé FIDO2 distincte de celle des portails web lorsque la séparation des usages est exigée. Installer libfido2 et OpenSSH 8.2 ou plus récent, connecter la clé matérielle, puis générer une clé liée à la présence locale.
# Vérifier que la bibliothèque détecte la clé FIDO2 connectée.fido2-token -L
# Générer une clé SSH nécessitant une présence physique sur la clé.# L'option -O verify-required impose aussi la vérification par code PIN.ssh-keygen -t ed25519-sk -O verify-required \ -f ~/.ssh/id_admin_fido2 \ -C "admin-fido2"
# Installer uniquement la clé publique sur le bastion cible.
# Vérifier que l'accès fonctionne avant de supprimer les anciennes clés.Le serveur reçoit une signature, pas la clé privée. Conserver la clé publique dans un référentiel d’accès, l’associer au compte nominatif et retirer immédiatement cette autorisation lors de la perte ou du départ. La suppression de la clé publique coupe les nouvelles connexions, pas les sessions SSH déjà ouvertes : un mécanisme de fermeture des sessions ou des durées maximales reste nécessaire.
Surface d’attaque, limites et exploitation
Section intitulée « Surface d’attaque, limites et exploitation »FIDO2 bloque le phishing de collecte et de relais, mais ne bloque pas un poste compromis. Un logiciel malveillant exécuté dans la session peut utiliser une session déjà ouverte, voler des jetons, modifier une transaction ou attendre que l’opérateur insère la clé. La protection restante vient du poste d’administration durci, de la segmentation réseau, du contrôle des sessions et de la journalisation. Les bastions et accès distants protégés font partie du même contrôle, pas d’un décor d’architecture.
Surveiller les créations et suppressions de preuves FIDO2, les changements de politique, les connexions sans facteur résistant au phishing, les récupérations d’urgence et les authentifications depuis des réseaux ou terminaux inhabituels. Une alerte doit inclure le compte, le facteur utilisé, l’application, l’origine réseau, l’état du terminal et l’action demandée. Sans cette contextualisation, le centre opérationnel reçoit une pluie de logs, ce qui est une forme très coûteuse de météo.
La perte d’une clé impose sa révocation immédiate dans l’IdP et dans chaque système qui conserve sa propre liste de clés, notamment SSH. La clé de secours doit être stockée sous contrôle physique séparé, avec test périodique documenté. Les clés FIDO2 ne se sauvegardent pas comme des secrets exportables : sauvegarder la clé privée casserait précisément la propriété recherchée. La reprise repose donc sur les clés de secours, les procédures d’identité et les droits minimaux temporaires.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans FIDO2 sur les comptes à privilèges, un code temporaire ou une notification approuvée via un proxy de relais produit une session d’administration authentique aux yeux de l’IdP. L’attaquant peut l’employer aussitôt pour enregistrer son propre facteur, ajouter une relation de fédération ou créer un compte d’administration. Ces ajouts survivent au changement de mot de passe de la victime, si bien que la réinitialisation seule ne suffit plus à l’évincer. La détection perd aussi un signal discriminant : le journal indique une authentification multifacteur réussie, identique à une connexion légitime. L’analyse doit alors reposer sur l’adresse d’origine et l’état du terminal, faute de pouvoir exiger une preuve liée à l’origine exacte du portail.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »L’authentification à plusieurs facteurs demande plus qu’un mot de passe. Pour les comptes capables de modifier les systèmes, le facteur supplémentaire choisi doit être une clé physique personnelle. Cette clé garde une partie secrète qui ne quitte jamais le matériel. Lors d’une connexion, le site demande une preuve liée à son adresse exacte. La clé vérifie cette adresse, demande parfois un code personnel ou un geste physique, puis produit une réponse que le site peut contrôler.
Un faux site peut copier l’apparence du vrai portail, mais il ne possède pas la bonne adresse. La clé refuse alors de produire une réponse exploitable pour le vrai service. C’est pourquoi cette méthode résiste mieux aux messages frauduleux demandant de se connecter en urgence.
Le déploiement commence par les comptes pouvant créer d’autres comptes, changer les règles de connexion ou contrôler les serveurs. Chaque personne concernée reçoit deux clés : une pour l’usage courant et une gardée séparément en cas de perte. Les anciennes méthodes restent disponibles seulement pendant les tests, puis elles sont retirées pour les comptes les plus dangereux.
Cette protection échoue si le poste est déjà infecté, si une session ouverte est volée, ou si la récupération de compte accepte des preuves trop faibles. Il faut donc aussi surveiller les connexions, protéger les postes d’administration, retirer vite les clés perdues et contrôler strictement les accès de secours.
À lire aussi
- Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.
- Pourquoi la cyber-hygiène individualise la responsabilitéLa notion de cyber-hygiène déplace souvent vers l'utilisateur final une responsabilité qui relève des choix de conception, d'exploitation et de gouvernance de l'organisation.
- Gouverner les facteurs d’authentification en entreprisePolitique de choix des facteurs, déploiement progressif du passwordless, vérification d’identité et récupération de compte dans un parc hétérogène.
- Micro-formations de sensibilisation sécurité régulièresGuide pratique pour déployer un programme de sensibilisation à la sécurité fondé sur des micro-formations régulières plutôt qu’une session annuelle.
Pages voisines
La citent
- Déployer DMARC de observation à reject
- Détecter l’impossible travel sur les connexions
- Calculer le coût total de possession d'un contrôle de sécurité
- Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi
- Comment contrer le spear phishing et la fraude au président
- Déployer le passwordless dans un parc hétérogène
- EDR : fonctionnement, angles morts et contournements
- Guide d'hygiène informatique ANSSI en 42 mesures, mode d'emploi
- Itinérance mobile et confiance entre opérateurs
- L'administration Active Directory en tiers en une page
Déployer FIDO2 pour comptes à privilèges
Elle cite