Ressources · 24
Déployer une authentification résistante au phishing
Choisir des facteurs liés au service légitime et protéger leur enrôlement, perte et révocation.
· 17 min
Ce que ce guide permet
- Cartographier les accès
- Choisir un protocole résistant
- Sécuriser l’enrôlement
- Exercer la récupération
Contrôle express
- Quels comptes donnent accès aux données ou fonctions critiques ?
- Le facteur est-il lié cryptographiquement au vrai service ?
- Qui autorise l’ajout d’un nouvel authentificateur ?
- Comment révoquer un appareil perdu ?
- Les exceptions ont-elles un responsable et une date de fin ?
Méthode pas à pas
- 01
Inventorier les chemins d’accès
Recenser applications, fédération, administrateurs, comptes de secours et méthodes actuelles. Repérer les connexions qui acceptent encore un code saisi manuellement.
Livrable : matrice comptes, applications et facteurs.
- 02
Choisir la résistance requise
Évaluer des protocoles cryptographiques liés au canal ou au nom du vérificateur, comme WebAuthn/FIDO2 lorsque l’application le permet. Un OTP recopié dans une page peut être relayé et n’est pas considéré résistant au phishing par le NIST.
Livrable : choix de méthode et limites connues.
- 03
Piloter sur les comptes sensibles
Tester navigateurs, appareils, délégation, usage hors ligne éventuel et accessibilité avec un groupe représentatif. Prévoir plusieurs moyens autorisés sans multiplier les accès dormants.
Livrable : scénario pilote et critères de succès.
- 04
Protéger l’enrôlement
Vérifier l’identité et la session avant d’ajouter une clé, notifier l’utilisateur et enregistrer l’événement. Tester le refus d’un enrôlement demandé depuis un contexte suspect.
Livrable : procédure et journal d’ajout.
- 05
Prévoir perte et révocation
Documenter le signalement, la désactivation, la récupération et le contrôle d’identité pour un moyen perdu. Tester ce parcours sans contourner la protection par un canal faible.
Livrable : exercice de récupération et révocation.
- 06
Étendre et surveiller
Déployer par groupes, mesurer la couverture, suivre les échecs et les exceptions, puis supprimer les méthodes anciennes quand le retour d’expérience permet de le faire.
Livrable : tableau de migration et registre des exceptions.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Couverture | Comptes sensibles utilisant une méthode résistante | Étendre la migration |
| Enrôlement | Ajouts avec contrôle et notification | Corriger les chemins faibles |
| Récupération | Pertes simulées traitées sans contournement | Rejouer le scénario |
| Exceptions | Accès restants avec propriétaire et date | Résorber les anciens facteurs |
Erreurs fréquentes
- Qualifier tout MFA de résistant au phishing
- Protéger la connexion mais laisser un enrôlement faible
- Oublier les administrateurs et comptes de secours
- Supprimer l’ancien facteur avant de tester la récupération
Questions fréquentes
Un code à usage unique suffit-il ?
Le NIST précise qu’un code saisi manuellement peut être relayé par un faux service ; il n’établit donc pas une résistance au phishing.
Faut-il une clé physique pour chaque personne ?
La méthode dépend du niveau d’assurance et du contexte ; certains authentificateurs WebAuthn synchronisables peuvent convenir à certains usages, avec des choix de récupération adaptés.
Que faire après la perte d’un appareil ?
Révoquer le moyen concerné, suivre la procédure de récupération vérifiée et notifier l’utilisateur selon la politique du service.
Références officielles
Pour aller plus loin
Analyses associées
