Déployer le passwordless dans un parc hétérogène

Déployer le passwordless dans un parc hétérogène

Le passwordless ne se déploie pas en remplaçant un écran de connexion par un autre. Dans un parc hétérogène, il faut faire coexister des postes capables de protéger une clé matériellement, des applications qui exigent encore un mot de passe, et des parcours de secours qui ne deviennent pas la nouvelle porte d’entrée préférée des attaquants.

Explication de la marmotte

Passer au passwordless ressemble au remplacement progressif de vieilles serrures dans un grand immeuble habité. Certaines portes acceptent déjà une méthode moderne, d’autres ne connaissent que leur vieille clé. Le but est d’améliorer la sécurité sans laisser des occupants dehors pendant les travaux.

→ Lire l’explication complète de la marmotte

Compromis du passwordless dans un parc mixte

Le gain central est net : supprimer le mot de passe du parcours courant retire la cible la plus rentable du hameçonnage, du rejeu et de la pulvérisation de mots de passe. Le prix est tout aussi net : l’organisation doit gérer des authentificateurs physiques, des postes non homogènes, des procédures de récupération et des exceptions applicatives pendant plusieurs années.

Il faut donc refuser le big-bang. Il produit généralement deux systèmes d’authentification mal maîtrisés, un mot de passe historique jamais désactivé et une collection de contournements créés sous pression. Le passwordless n’est pas une migration d’interface. C’est une migration d’assurance d’identité et de reprise.

Une stratégie praticable segmente les populations selon le risque d’usurpation et la capacité de récupération, pas selon la facilité de démonstration. Les comptes d’administration, les comptes à privilèges et les opérateurs d’infrastructure passent d’abord. Ils concentrent le risque, utilisent souvent des postes administrés, et supportent mieux une procédure stricte. La population générale suit lorsque l’enrôlement, le support et les exceptions sont mesurés.

Les mécanismes modernes reposent souvent sur FIDO (Fast IDentity Online) et WebAuthn (Web Authentication), qui permettent à un authentificateur de prouver la possession d’une clé privée liée au service demandé. Cette page ne détaille pas leur mécanique cryptographique : le sujet est de faire vivre ce modèle là où Kerberos, les mots de passe et les applications historiques restent présents.

Le choix à trancher est le suivant :

• imposer le passwordless pour les accès à haut privilège dès que les postes administratifs sont éligibles ;
• maintenir une coexistence explicitement bornée pour les applications legacy ;
• ne jamais présenter le mot de passe résiduel comme un secours acceptable pour un compte déjà migré.

Vingt ans de gestion d’identités apprennent que « temporaire » est une unité de temps très créative. Sans date cible, propriétaire et métrique de sortie, l’exception devient une fondation technique.

Prérequis de plateforme et inventaire d’éligibilité

Avant l’enrôlement, il faut disposer d’un annuaire ou fournisseur d’identité capable d’appliquer des politiques par groupe, de journaliser les événements d’authentification et de distinguer les méthodes fortes des méthodes de récupération. Une politique globale sans ciblage par population interdit la migration progressive et force le retour arrière général au premier incident.

Les postes récents doivent être inventoriés selon des capacités vérifiables :

• présence et état d’un TPM (Trusted Platform Module), composant matériel protégeant des secrets liés au poste ;
• compatibilité du système d’exploitation avec une authentification locale par code personnel ou biométrie ;
• lecteur biométrique réellement exploitable par le système, pas seulement présent dans une fiche produit qui a dû être rédigée par un poète ;
• chiffrement du disque et démarrage sécurisé actifs ;
• rattachement de l’équipement à une gestion de parc, par exemple un MDM (Mobile Device Management) ;
• synchronisation horaire, connectivité vers le fournisseur d’identité et collecte centralisée des journaux.

La biométrie n’est pas un facteur envoyé au fournisseur d’identité. Elle déverrouille localement l’authentificateur du poste. Cette distinction compte : une empreinte enregistrée localement ne remplace ni une clé matérielle ni une procédure de récupération.

Les applications doivent être classées en quatre catégories : fédérables vers un fournisseur d’identité, compatibles Kerberos, limitées au mot de passe, ou incapables de recevoir une identité utilisateur moderne. L’inventaire doit inclure les tâches planifiées, les services Windows, les scripts d’administration et les clients épais. Les identités non humaines ne doivent pas être converties en comptes humains passwordless : elles nécessitent des identités de charge de travail, des certificats ou des secrets gérés.

Pour les environnements encore dépendants de NTLM (NT LAN Manager), le passwordless utilisateur ne corrige pas les faiblesses du protocole. Une session peut encore déclencher des flux hérités, relayer des défis ou utiliser des secrets de compatibilité. Le chantier doit être coordonné avec le durcissement de NTLM, sans confondre suppression du mot de passe interactif et disparition du mot de passe dans l’infrastructure.

Migration par populations à privilèges

Les administrateurs constituent la première vague, avec des règles plus strictes que celles de la population générale. Chaque compte à privilèges doit posséder au moins deux authentificateurs enregistrés, détenus séparément : un authentificateur principal et une clé de sécurité physique de secours. Le téléphone personnel ne doit pas devenir une dépendance obligatoire lorsque la politique BYOD (Bring Your Own Device) le refuse ou que les zones d’exploitation interdisent les réseaux mobiles.

La clé de sécurité physique est un coût récurrent, pas un achat ponctuel. Il faut prévoir le stock initial, le stock de remplacement, l’expédition sécurisée, l’enregistrement d’inventaire, la révocation lors de la restitution et le délai de remplacement. Une clé perdue doit être désactivée dès le signalement, sans attendre une enquête romanesque sur le trajet entre deux salles de réunion.

Pour les administrateurs, l’accès aux consoles sensibles doit exiger une authentification résistante au hameçonnage. Une notification à valider sur un téléphone ne suffit pas contre la fatigue de validation, aussi appelée MFA (Multi-Factor Authentication) bombing. Une clé physique avec vérification locale de présence et, si possible, code personnel, réduit ce risque.

La deuxième vague couvre les populations générales éligibles. On commence par les postes gérés et les applications fédérées. Les équipes avec postes partagés, travail hors ligne prolongé, accès à des environnements industriels ou contraintes d’accessibilité reçoivent un parcours dédié. L’accessibilité n’est pas une exception décorative : si la biométrie ou une clé compacte ne peut pas être utilisée, il faut une autre méthode forte documentée.

Les comptes à privilèges doivent rester distincts des comptes bureautiques. Enregistrer la même clé sur les deux peut être acceptable selon le niveau de risque, mais fusionner les comptes ne l’est pas. Le compromis entre ergonomie et séparation des tâches se décide dans la gouvernance des identités, puis se contrôle techniquement par les groupes, les politiques et les journaux.

Exemple d’inventaire TPM avant une vague Windows

Avant de cibler un groupe d’utilisateurs Windows, l’état matériel doit être mesuré sur les postes réellement administrés. La commande PowerShell suivante interroge le TPM local et produit un état exploitable par un outil de collecte de parc.

# Exécuter dans une console PowerShell élevée sur un poste Windows.
# Get-Tpm retourne l'état du composant de protection matériel.
$tpm = Get-Tpm

[pscustomobject]@{
    ComputerName     = $env:COMPUTERNAME
    TpmPresent       = $tpm.TpmPresent
    TpmReady         = $tpm.TpmReady
    TpmEnabled       = $tpm.TpmEnabled
    TpmActivated     = $tpm.TpmActivated
    Manufacturer     = $tpm.ManufacturerIdTxt
    ManufacturerVersion = $tpm.ManufacturerVersion
} | Format-List

TpmPresent=True ne suffit pas. Un TPM désactivé, non initialisé ou sans politique de démarrage cohérente ne protège pas l’authentificateur local comme attendu. L’inventaire doit aussi vérifier la version du système, le chiffrement de disque et la conformité de gestion. Un tableur rempli à la main peut servir de preuve archéologique, pas de contrôle de déploiement.

Applications legacy, Kerberos et mot de passe résiduel

Kerberos reste compatible avec un parcours passwordless lorsque le poste obtient les tickets nécessaires après une ouverture de session forte. En revanche, une application qui demande explicitement un mot de passe dans son propre formulaire sort du modèle : elle ne sait pas déléguer l’authentification, elle la réimplémente. C’est une dette applicative, pas une propriété inévitable du passwordless.

Trois traitements existent :

1. fédérer l’application vers le fournisseur d’identité si elle supporte un protocole moderne ;
2. maintenir Kerberos pour les applications intégrées au domaine, en supprimant les invites de mot de passe utilisateur ;
3. isoler l’exception mot de passe avec des contrôles compensatoires, une échéance et un propriétaire applicatif.

Il ne faut pas conserver un mot de passe utilisable sur Internet pour « compatibilité locale ». Cette décision réintroduit le hameçonnage sur le même identifiant que le compte passwordless. Si une application legacy l’exige, limiter son accès au réseau interne, appliquer une authentification forte en amont et empêcher la réutilisation de ce secret sur les services fédérés.

Le passwordless ne garantit pas l’autorisation. Une clé prouve une identité, elle ne dit pas si cette identité peut modifier une règle réseau, exporter des données ou administrer un annuaire. Les droits, la séparation des rôles, les postes d’administration dédiés et la validation des actions sensibles doivent venir de l’architecture d’autorisation. Le mot « zero trust » imprimé sur une slide ne délègue aucun privilège correctement.

Attaques, récupération et exploitation durable

La principale attaque vise le parcours de récupération. Si le support peut réinitialiser un authentificateur après quelques questions publiques et un appel téléphonique convaincant, l’attaquant contourne la cryptographie sans même la regarder. La récupération d’un compte à privilèges doit exiger une vérification hors bande, un approbateur distinct et une journalisation exploitable.

Les autres surfaces d’attaque sont connues :

• vol d’une clé physique : exiger un code personnel lorsque le modèle le supporte, révoquer immédiatement et conserver un second authentificateur ;
• compromission d’un poste déjà ouvert : verrouillage automatique, chiffrement de disque, détection de session anormale et poste d’administration séparé ;
• enrôlement frauduleux d’un nouvel authentificateur : exiger une méthode forte existante ou une vérification d’identité contrôlée ;
• contournement vers une méthode faible : interdire les méthodes de repli pour les groupes à privilèges ;
• perte de journalisation : envoyer les événements d’enrôlement, d’échec, de récupération et de révocation vers un SIEM (Security Information and Event Management).

Les clés privées d’authentification ne se sauvegardent généralement pas comme un fichier exportable. La reprise repose sur plusieurs authentificateurs enregistrés, des procédures d’enrôlement de remplacement et la capacité à rétablir les politiques du fournisseur d’identité. Sauvegarder les configurations de politiques, les groupes de ciblage, les journaux d’audit et l’inventaire des clés est donc plus déterminant que chercher à copier une clé censée ne jamais sortir de son matériel.

Une métrique de migration doit distinguer comptes éligibles, comptes enrôlés, comptes effectivement utilisés sans mot de passe, exceptions actives et récupérations. Mesurer seulement les enrôlements revient à compter des extincteurs sans vérifier qu’ils fonctionnent. Le taux de repli vers mot de passe est la métrique qui révèle le vrai état de la migration.

🐝 Ce qui arrive si on s’en passe

Sans cette brique, l’identifiant reste le plus petit dénominateur commun du parc : un même secret sert au poste, aux applications historiques et aux services exposés, si bien qu’une capture unique ouvre plusieurs périmètres à la fois. Les journaux d’authentification ne portent alors aucune distinction de niveau d’assurance : une connexion validée par une clé matérielle et une saisie de mot de passe volée se ressemblent, ce qui prive la détection du signal le plus utile. Faute de cycle de vie des authentificateurs (enrôlement, révocation, remplacement), un objet perdu reste valide sans trace exploitable, et la réinitialisation par le support devient le chemin d’accès le moins coûteux pour un attaquant. L’absence d’inventaire d’éligibilité empêche enfin de démontrer quels comptes sont réellement protégés, donc de mesurer la reprise après incident.

🦫 Explication de la marmotte 🍫

Le passwordless permet de prouver son identité sans taper le mot de passe habituel. Une personne utilise un appareil personnel de travail ou une clé de sécurité physique. Cet objet garde une information secrète qui ne doit pas être copiée ni envoyée au site demandé. Lors de la connexion, le site demande une preuve. L’objet produit cette preuve après une vérification locale, par exemple un code personnel ou une empreinte reconnue par le poste.

Le déploiement commence par repérer les postes capables de protéger cette information secrète et les applications capables d’accepter cette nouvelle connexion. Les administrateurs passent en premier parce que leur compte peut modifier les systèmes. Ils reçoivent aussi une seconde clé rangée séparément, afin de ne pas perdre l’accès si le premier objet disparaît ou tombe en panne.

Certaines vieilles applications demandent encore un mot de passe. Elles restent temporairement accessibles avec des règles plus strictes, puis doivent être modifiées ou remplacées. Garder ce mot de passe utilisable partout annulerait une grande partie du bénéfice.

En cas de perte, le service informatique désactive la clé perdue, vérifie l’identité de la personne avec une procédure contrôlée, puis enregistre une nouvelle clé. Cette procédure doit être surveillée, car un fraudeur cherchera souvent à obtenir un nouvel accès plutôt qu’à casser la protection elle-même.

À lire aussi

• 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.
• Authentifier les personnes et les servicesRelier cryptographie et authentification réelle : mots de passe, sessions, MFA, Kerberos, PAKE, OPAQUE, WebAuthn et passkeys.
• 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.
• Attestation distante TPM et démarrage mesuréMettre en œuvre l’attestation à distance et le démarrage mesuré pour prouver l’intégrité d’un système à un tiers sans lui accorder une confiance aveugle.

Pages voisines

La citent

• Authentification défi-réponse, rejeu, relais et attaque hors ligne
• Gouverner les facteurs d’authentification en entreprise

Déployer le passwordless dans un parc hétérogène

Elle cite

• ⇄Lien dans les deux sens :Configurer Windows Hello for Business sans mot de passe
• Kerberos et KDC dans Active Directory, attaques et durcissement
• NTLM : protocole authentification LAN Manager New Technology Microsoft
• Déployer FIDO2 pour comptes à privilèges

⇄ : les deux pages se citent l’une l’autre.