Gouverner les facteurs d’authentification en entreprise

Gouverner les facteurs d’authentification en entreprise

Un facteur robuste ne vaut que si son inscription et son remplacement résistent à la pression opérationnelle. La politique doit donc couvrir le choix des facteurs, leur cycle de vie, la preuve d’identité initiale et la récupération, faute de quoi le support devient un contournement humain de l’authentification.

Explication de la marmotte

Gérer les moyens d’accès d’une entreprise ressemble à la gestion des badges d’un immeuble : choisir qui reçoit quel badge ne suffit pas. Il faut aussi vérifier l’identité avant de le donner, savoir quoi faire lorsqu’il disparaît et empêcher qu’une personne pressée ouvre une porte sans contrôle.

→ Lire l’explication complète de la marmotte

Politique de facteurs selon le profil de risque

Un facteur d’authentification prouve une chose différente selon sa nature : connaissance d’un secret, possession d’un objet ou présence d’une personne. La gouvernance ne consiste pas à empiler ces facteurs jusqu’à épuisement du formulaire de connexion. Elle consiste à attribuer une exigence minimale à chaque population, application et action sensible.

La recommandation est nette : faire du facteur résistant au hameçonnage la cible par défaut pour les identités humaines à privilèges, les accès distants et les applications manipulant des données sensibles. Les clés de sécurité et les passkeys fondées sur Web Authentication (WebAuthn) répondent à cette exigence. Le mot de passe à usage unique, ou OTP (One-Time Password), reçu par message texte ou produit par une application, reste acceptable comme transition ou secours encadré. Il ne doit pas rester le facteur principal des administrateurs.

Le compromis central est brutal : réduire la friction diminue l’abandon et les tickets, mais multiplier les exceptions augmente la surface de contournement. Le passwordless gagne contre le hameçonnage et la réutilisation de mots de passe. Il paie cette sécurité par une gouvernance d’enrôlement, de terminaux et de récupération beaucoup plus stricte. Sans cette discipline, le prétendu accès sans mot de passe devient un accès avec mot de passe caché dans le script du support. Le secteur adore appeler cela une expérience fluide.

Une matrice de politique doit associer au minimum quatre axes :

• Profil d’identité : salarié, prestataire, administrateur, compte de service, compte d’urgence.
• Niveau d’impact : messagerie, application métier, administration de production, coffre de secrets.
• Contexte d’accès : poste géré, poste non géré, réseau interne, Internet, session déjà élevée.
• Facteurs autorisés et interdits : facteur résistant au hameçonnage exigé, OTP autorisé temporairement, message texte interdit, mot de passe seul interdit.

Un compte d’administration ne doit jamais partager sa politique avec le compte bureautique de la même personne. La corrélation identitaire est nécessaire pour l’audit, mais la compromission d’un poste de messagerie ne doit pas donner un chemin direct vers la console d’infrastructure. La séparation des comptes, des facteurs enregistrés et des parcours de récupération est non négociable.

Pour les applications anciennes, une fédération d’identité via un fournisseur d’identité central réduit le nombre de politiques à maintenir. Elle ne modernise pas magiquement le protocole applicatif : un formulaire local, une authentification LDAP (Lightweight Directory Access Protocol) en liaison simple ou une délégation NTLM (NT LAN Manager) peuvent conserver leurs propres faiblesses. Les dépendances héritées doivent être inventoriées avant toute bascule, notamment celles décrites dans le durcissement de NTLM et la désactivation des liaisons LDAP en clair.

Vérification d’identité à l’inscription

L’inscription d’un facteur est un événement de sécurité, pas une préférence d’interface. Autoriser l’ajout d’un nouveau facteur à partir d’une session existante suffit pour un usage courant, mais devient insuffisant si la session a été volée, détournée par hameçonnage ou ouverte sur un poste partagé.

Le parcours doit exiger une authentification récente avec un facteur déjà approuvé avant l’ajout, la suppression ou le renommage d’un facteur. Cette réauthentification doit être liée à l’action : une session ouverte depuis plusieurs heures ne doit pas pouvoir enregistrer silencieusement une nouvelle clé. L’événement doit produire un journal contenant l’identité, le facteur ajouté, le canal, l’adresse réseau, l’appareil déclaré et le résultat. Les données personnelles inutiles n’ont rien à faire dans ce journal. L’audit n’est pas une collection de timbres-poste.

La preuve d’identité initiale dépend de la population. Pour un salarié, la source d’autorité est le processus d’arrivée géré par les ressources humaines et le responsable hiérarchique, pas une adresse électronique personnelle déclarée dans un formulaire. Pour un prestataire, elle vient du sponsor interne nommé et d’une durée d’habilitation bornée. Pour un administrateur, elle doit inclure une approbation séparée et une remise contrôlée du premier facteur.

Un code envoyé à l’adresse électronique professionnelle ne constitue pas une vérification d’identité indépendante lorsque cette messagerie est accessible avec la même session fédérée. Il valide au mieux le contrôle de cette boîte à cet instant. La même règle vaut pour un message texte envoyé au numéro de téléphone déjà déclaré : ce canal ne doit pas autoriser seul l’ajout d’un facteur plus puissant.

L’inscription doit prévoir deux facteurs de secours résistants au hameçonnage pour les populations critiques, stockés sur des supports distincts. Enregistrer deux passkeys synchronisées dans le même écosystème de terminaux ne crée pas deux voies indépendantes de reprise. Une panne de compte de synchronisation, un effacement à distance ou une compromission de ce compte atteint les deux. L’indépendance se mesure aux dépendances, pas au nombre d’icônes dans le portail.

Récupération de compte et contournement du support

La récupération est le point où l’architecture rencontre le téléphone, l’urgence et le script lu trop vite. Si un agent peut réinitialiser un accès après quelques questions biographiques ou une validation par messagerie personnelle, la robustesse du facteur principal devient décorative.

Il faut séparer trois opérations : retrouver l’accès à un compte, enregistrer un nouveau facteur et relever un niveau de privilège. Elles n’ont ni le même impact ni le même délai. La récupération d’un compte bureautique peut déclencher un accès limité et temporaire. L’inscription d’un nouveau facteur d’administration doit exiger une validation hors bande par deux personnes habilitées, suivie d’un délai de refroidissement avant les actions les plus sensibles.

Un canal hors bande est indépendant du canal compromis présumé. Un appel au numéro indiqué dans le ticket n’est pas hors bande. Une réponse depuis la boîte professionnelle possiblement compromise ne l’est pas davantage. Les canaux acceptables sont ceux enregistrés avant l’incident et protégés par une procédure de vérification documentée.

Les attaques connues suivent un scénario banal : hameçonnage de session, ajout d’un facteur par l’attaquant, suppression des alertes, puis persistance. Une autre variante vise le centre de support : usurpation vocale, informations publiques, pression temporelle et demande de réinitialisation. La contre-mesure n’est pas une meilleure question secrète. Les questions secrètes sont des mots de passe dont la réponse est souvent sur un réseau social, ce qui mérite presque une médaille de l’absurde.

Les contrôles attendus sont précis :

• interdire au support de voir, dicter ou modifier un secret d’authentification ;
• imposer une approbation à quatre yeux pour tout changement de facteur privilégié ;
• notifier l’ancien et le nouveau canal lors d’un changement ;
• placer sous délai les changements à fort impact, avec possibilité d’annulation ;
• détecter l’ajout de facteur suivi d’une élévation de privilèges ou d’une exportation de données ;
• maintenir un compte d’urgence distinct, à accès journalisé et testé, sans le transformer en compte quotidien.

La gouvernance de la sécurité doit désigner les propriétaires de ces parcours. Le fournisseur d’identité opère les écrans ; le propriétaire métier arbitre l’identité ; le support exécute une procédure limitée. Confondre ces rôles produit des droits permanents accordés au nom de la continuité. La continuité est nécessaire, le passe-partout l’est beaucoup moins.

Déploiement passwordless dans un parc hétérogène

La migration doit commencer par l’inventaire des navigateurs, systèmes d’exploitation, terminaux partagés, applications fédérées et applications à authentification locale. Sans cet inventaire, le projet découvre les incompatibilités après avoir retiré le mot de passe. C’est une méthode coûteuse pour produire des réunions.

Découper le parc en trois groupes :

1. Compatible : poste géré et navigateur prenant en charge WebAuthn. Activer le passwordless, imposer au moins un facteur de secours et mesurer les échecs.
2. Fédérable sans WebAuthn direct : application ancienne derrière un proxy d’authentification ou une fédération. Protéger l’entrée avec un facteur moderne, puis accepter que le protocole interne reste hérité.
3. Non migrable à court terme : application locale ou poste ancien. Conserver un mot de passe long et unique, ajouter un OTP si possible, réduire l’exposition réseau et fixer une date de retrait technique.

Le groupe 3 n’est pas une excuse pour généraliser le mot de passe à tout le monde. Il constitue une dette technique explicitement suivie. Chaque exception doit avoir un propriétaire, une justification, une portée et une échéance. Une exception sans échéance est une règle qui porte une moustache.

Le mot de passe ne doit être supprimé qu’après observation des parcours de secours et des taux d’échec. Désactiver d’abord la connexion par mot de passe pour les groupes compatibles, tout en conservant une récupération contrôlée, évite qu’un mécanisme ancien reste actif comme repli automatique. Un repli silencieux vers le mot de passe annule la résistance au hameçonnage au premier écran de connexion malveillant.

Exemple de politique vérifiable

Le fichier suivant formalise une politique minimale. La commande vérifie que les profils privilégiés interdisent le message texte et exigent deux facteurs de secours. Elle s’exécute avec jq, processeur JSON (JavaScript Object Notation), installé localement.

policy-facteurs.json

{
  "profils": [
    {
      "nom": "administrateur-production",
      "facteur_primaire": "webauthn",
      "secours_minimum": 2,
      "sms_autorise": false,
      "recuperation": "double-approbation-hors-bande"
    },
    {
      "nom": "utilisateur-standard",
      "facteur_primaire": "webauthn",
      "secours_minimum": 1,
      "sms_autorise": false,
      "recuperation": "validation-identite"
    }
  ]
}

# Échoue si un profil administrateur accepte le SMS ou manque de deux secours.
jq -e '
  .profils[]
  | select(.nom | startswith("administrateur"))
  | (.sms_autorise == false and .secours_minimum >= 2)
' policy-facteurs.json >/dev/null

Cette vérification ne déploie rien. Elle empêche seulement qu’une politique documentée dérive sans contrôle dans un dépôt de configuration. Pour relier cette règle à l’architecture d’identité globale, consulter la page Identités et les principes d’architecture cybersécurité.

Exploitation, révocation et reprise

Chaque facteur doit avoir un identifiant, un propriétaire, une date d’inscription, un état, une dernière utilisation et un motif de révocation. La perte d’un terminal exige la révocation du facteur associé, mais la révocation n’interrompt pas forcément les sessions déjà établies. Les jetons de session doivent donc avoir une durée courte pour les actions sensibles et être invalidables côté serveur après un événement de récupération.

Superviser les échecs de récupération, les changements de facteurs, les connexions depuis un nouvel appareil et les demandes répétées de support. Les alertes doivent être corrélées à l’identité et au niveau de privilège, pas seulement à l’adresse réseau. Un attaquant peut changer d’adresse plus vite qu’un tableau de bord ne change de couleur.

La sauvegarde concerne la configuration du fournisseur d’identité, les règles de politique, les journaux nécessaires à l’enquête et les comptes d’urgence. Elle ne doit jamais contenir de secrets de récupération en clair. Tester la reprise implique de restaurer cette configuration dans un environnement isolé, de vérifier les dépendances de fédération et de confirmer que les comptes d’urgence restent contrôlés. Une sauvegarde jamais restaurée est une croyance religieuse avec stockage objet.

🐝 Ce qui arrive si on s’en passe

Sans politique de facteurs ni registre d’inscription, l’analyse post-incident ne peut plus dater ni délimiter la compromission : rien ne distingue une clé enregistrée par le titulaire d’une clé ajoutée par un tiers, et la remédiation dégénère en réinitialisation globale du parc, avec interruption de tous les accès légitimes. La preuve d’identité initiale n’étant rattachée à aucune source d’autorité, la désactivation d’un départ ou d’une fin de prestation laisse des facteurs actifs sans propriétaire identifiable. Les dérogations accordées pour les applications anciennes se figent faute d’échéance et de propriétaire, si bien que le repli par mot de passe reste disponible partout et annule le bénéfice des facteurs résistants au hameçonnage. Enfin, sans séparation des parcours, le centre de support devient le chemin d’authentification réel, non mesuré et non auditable.

🦫 Explication de la marmotte 🍫

Une entreprise doit décider quels moyens permettent à chaque personne de se connecter. Les personnes qui administrent des systèmes ou accèdent à des données sensibles reçoivent des moyens plus difficiles à voler par un faux site de connexion. Le mot de passe peut rester présent pour des logiciels anciens, mais il ne doit pas redevenir automatiquement le moyen principal partout.

Avant de donner un nouveau moyen de connexion, l’entreprise vérifie l’identité avec une source fiable, par exemple le processus d’arrivée d’un salarié et la validation d’un responsable. Une personne déjà connectée doit prouver à nouveau son identité avant d’ajouter ou supprimer un moyen d’accès. Chaque changement est enregistré et signalé.

Si le moyen est perdu, la récupération suit une procédure séparée. Le support ne doit pas pouvoir remplacer un accès après un appel ou quelques informations personnelles. Pour les accès sensibles, deux personnes autorisées valident la demande par des canaux prévus avant l’incident. Le nouvel accès peut être limité pendant un délai.

Les anciens postes et logiciels sont classés selon ce qu’ils supportent. Ceux qui peuvent utiliser les nouveaux moyens migrent en premier. Les autres gardent des protections temporaires et une date de retrait. Les changements, pertes et tentatives inhabituelles sont surveillés. Enfin, les règles, journaux et accès d’urgence sont sauvegardés puis testés, car une récupération qui échoue pendant une panne ne récupère rien du tout.

À lire aussi

• Authentification défi-réponse, rejeu, relais et attaque hors ligneComment l'authentification par défi-réponse prouve la connaissance d'un secret sans le transmettre dans CHAP, NTLM, Kerberos et FIDO2, et pourquoi le rejeu, le relais et l'attaque hors ligne restent possibles.
• Comment limiter le mouvement latéral après compromissionLe mouvement latéral permet à un attaquant déjà présent de progresser vers des systèmes plus sensibles, mais la segmentation et la détection interne en réduisent fortement la portée.
• Authentifier les personnes et les servicesRelier cryptographie et authentification réelle : mots de passe, sessions, MFA, Kerberos, PAKE, OPAQUE, WebAuthn et passkeys.
• Déployer FIDO2 pour comptes à privilègesGuide pratique de priorisation et de déploiement progressif de l’authentification multifacteur résistante au phishing pour les comptes à privilèges.

Pages voisines

La citent

• DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir
• Les passkeys, et ce qui se déplace
• NIST
• Principes de sécurité, identité et cryptographie utile au réseau

Gouverner les facteurs d’authentification en entreprise

Elle cite

• Déployer le passwordless dans un parc hétérogène
• Grand-père Castor raconte : bind LDAP en clair, corrigé
• NTLM : protocole authentification LAN Manager New Technology Microsoft
• Déployer WebAuthn FIDO2 passwordless sur une application web
• La récupération de compte, maillon faible