Authentificateur VPN perdu : le remplacer sans désactiver le MFA

Quelqu’un perd son téléphone et le ticket arrive comme « VPN en panne ». Ce cadrage est faux deux fois : le compte existe toujours et la passerelle fait toujours confiance au fournisseur d’identité, donc la seule partie cassée est un facteur que la personne ne détient plus. Traitez cela comme une récupération et non comme une panne : vérifiez le demandeur, enrôlez un remplaçant, retirez la méthode perdue, puis prouvez que le compte fonctionne. Tout cela suppose que le plan ait été écrit avant la perte, car l’inventer pendant l’appel est la façon dont le MFA finit désactivé pour tout le monde.

Étape 1 : lisez les facteurs enrôlés dans un registre, pas de mémoire

La première question n’est pas quel appareil a été perdu, mais ce que le compte peut encore utiliser. Un compte peut porter un mot de passe avec push, un code temporel, une clé matérielle et des codes de récupération imprimés, et perdre l’un de ceux-là est un événement très différent de perdre le seul. Lisez la liste des méthodes dans le système d’identité au lieu de demander à l’utilisateur de s’en souvenir, et dans un locataire Microsoft Entra la requête tient en une ligne :

Get-MgUserAuthenticationMethod -UserId [email protected]

Écrivez ensuite le registre de récupération tant que le compte fonctionne : identifiant du compte, facteurs enrôlés, où vivent les codes de récupération, qui peut vérifier le demandeur de façon indépendante et quels systèmes le compte atteint. Conservez-le dans l’inventaire protégé que l’équipe utilise déjà, jamais dans une note qui contient aussi des codes actifs. Ces cinq champs transforment un appel paniqué en liste de contrôle, et les recommandations du NIST sur le cycle de vie des authentificateurs traitent la récupération comme une partie du justificatif et non comme une exception.

Consignez le canal de vérification comme un champ à part, car c’est la partie que les gens sautent. Un numéro de téléphone rattaché au compte n’est pas un canal indépendant quand la personne qui demande contrôle aussi le téléphone.

Étape 2 : vérifiez le demandeur hors du chemin défaillant

Effectuez le contrôle d’identité par un canal qui ne dépend ni du VPN, ni de la boîte aux lettres, ni de l’appareil perdu. Un rappel vers un numéro du registre RH, ou une vérification en personne avec un responsable déjà dans l’annuaire, fonctionnent tous deux ; un message de chat envoyé depuis le compte en récupération ne fonctionne pas. Le contrôle porte sur la personne, pas sur sa capacité à répondre à des questions sur le compte, car les détails du compte fuient. Consignez qui a vérifié la demande et quand, puisque le prochain relecteur voudra les deux.

Quand la demande arrive avec urgence et pression pour sauter le contrôle, c’est le moment de ralentir. La fraude à la récupération ressemble exactement à un collègue serviable pressé.

Étape 3 : enrôlez le remplaçant, puis retirez l’ancien facteur

Enrôlez le nouvel authentificateur par le flux d’enrôlement normal, jamais par un contournement administratif. Retirez ensuite explicitement la méthode perdue, car enrôler un remplaçant laisse l’authentificateur précédent autorisé jusqu’à ce que quelqu’un le retire. Si l’ancien appareil peut être entre d’autres mains, traitez le retrait comme urgent et suivez le processus d’incident plutôt que celui de récupération. Révoquez les sessions existantes dans la même passe, car une session créée avant le changement peut lui survivre :

Revoke-MgUserSignInSession -UserId [email protected]

Retirer le facteur pour tous les autres, ou assouplir les contrôles de certificat de la passerelle, échange la récupération d’une personne contre une panne qui touche tout le déploiement. Gardez le changement limité au seul compte et escaladez si les preuves pointent vers une compromission plus large. Notez dans le ticket quel facteur a été retiré et lequel l’a remplacé.

Étape 4 : prouvez que le compte fonctionne dans les deux sens

Connectez-vous une fois avec le nouveau facteur via un client pris en charge, puis confirmez que le compte atteint toujours les ressources qu’il atteignait avant la perte. Testez une ressource qui nécessite le tunnel et une qui ne le nécessite pas, pour qu’une défaillance pointe vers la bonne couche. Tentez une connexion avec le facteur retiré et attendez-vous à un rejet plutôt qu’à une invite, ce qui prouve que le retrait a pris effet. Un défi qui échoue depuis un appareil enrôlé existant est un problème d’invite, pas une raison de tout réenrôler.

Demandez ensuite à l’utilisateur d’effectuer la même connexion sans accompagnement. Votre test réussi prouve la configuration ; sa tentative prouve la remise.

Clôturez le ticket avec l’horodatage de la connexion réussie et le nom du facteur désormais utilisé. Mettez à jour le registre de récupération dans la même passe, afin que la prochaine perte parte d’un inventaire exact et non d’un inventaire périmé.

Étape 5 : supprimez la condition qui a rendu cela pénible

Chaque appel de récupération est une preuve sur la conception de l’enrôlement. Si le compte n’avait qu’un seul facteur, exigez-en un second pour tous dans ce groupe. Si les codes de récupération étaient sur l’ordinateur portable perdu, changez où ils vivent. Si la vérification exigeait un responsable en congé, nommez un suppléant. Chaque correctif prend un après-midi et supprime la pire heure de l’incident suivant.

Relisez ensuite le registre de l’étape un face à la réalité. Énumère-t-il les facteurs qui existent réellement, et le canal de vérification atteint-il encore un humain ? Un manuel que personne ne met à jour se dégrade en document que les gens ignorent pendant l’appel pour lequel il a été écrit.