Changer le mot de passe VPN sans bloquer tous les appareils

Trois téléphones, un routeur et un contrôle de supervision détiennent encore l’ancien mot de passe, et l’un d’eux se reconnecte toutes les quatre-vingt-dix secondes. Le mot de passe du compte a changé il y a dix minutes, donc chacun de ces clients soumet maintenant une valeur que le serveur rejette. C’est le moment où le mythe se brise : un changement de mot de passe touche le compte, pas les copies de l’ancienne valeur posées sur chaque appareil. Ce qui suit est le travail que le changement n’a pas fait.

Le mythe : un changement, partout à la fois

On croit qu’un changement de mot de passe déconnecte tout et impose une reconnexion propre. Ce n’est pas le cas, car le serveur ne suit que le dernier identifiant qu’il a accepté, tandis que les clients gardent ce qu’ils ont stocké. Un appareil doté d’un mot de passe enregistré le réessaie selon son propre calendrier et échoue en silence jusqu’à ce que quelqu’un remarque que le compte est verrouillé. Dès que vous acceptez que les copies vivent hors du compte, la rotation cesse de ressembler à une action unique.

Rien de tout cela n’argumente contre la rotation. Cela plaide pour traiter les copies enregistrées comme une partie du changement et non comme une réflexion après coup. Un verrouillage vient généralement de tentatives parallèles : chaque appareil continue de soumettre l’ancienne valeur selon son calendrier jusqu’à ce que le compteur se déclenche. Le compte semble alors attaqué alors qu’on ne lui propose que des identifiants que personne n’a remplacés. Cette distinction compte, car la solution est une liste d’appareils et non une politique de verrouillage plus stricte.

Inventoriez les copies avant de faire tourner

Écrivez l’inventaire avant d’ouvrir le formulaire de mot de passe. Listez chaque client, script, automatisation et profil géré qui s’authentifie comme ce compte : le téléphone qui se connecte seul, le routeur configuré il y a deux ans, l’ordinateur portable qui ne s’éveille que le lundi, et le contrôle de supervision qui essaie chaque minute. Pour chacun, notez où l’identifiant est stocké, si l’appareil est joignable pendant le changement et quelle voie de récupération existe s’il ne peut pas se reconnecter. Cette liste transforme un changement risqué en changement planifié, et elle doit exister avant que l’ancien mot de passe cesse de fonctionner.

Les appareils hors ligne sont l’oubli classique. Un portable dans un tiroir revient trois semaines plus tard et présente la valeur périmée au pire moment possible. Notez aussi son emplacement et son calendrier, car vous devrez le poursuivre plutôt que l’attendre.

Sur une flotte Linux, la recherche est mécanique plutôt qu’astucieuse. Cherchez les profils qui référencent un fichier d’identifiants, puis les fichiers d’identifiants eux-mêmes, car c’est la seconde liste qu’il faut réécrire. Répétez l’exercice pour les clients de bureau et les téléphones, où le stockage est un profil ou une entrée de trousseau plutôt qu’un chemin. Le but est une liste que vous pouvez traiter, pas une analyse qui prétend trouver chaque copie.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Comparez les copies aux personnes qui les possèdent. Un appareil que personne ne revendique est un appareil que personne ne mettra à jour, et c’est aussi celui qui continuera le plus probablement à réessayer.

Quel secret vous faites réellement tourner

Un mot de passe de compte n’est qu’un identifiant dans un déploiement VPN. Une phrase de passe de clé, une identité de certificat et un secret de pair facultatif ont chacun leur propre voie de remplacement et leur propre propriétaire. Changer le mot de passe du compte ne fait rien pour un appareil qui s’authentifie par certificat, et réémettre un certificat ne fait rien pour un client qui détient un mot de passe enregistré. Nommez le secret avant de nommer la solution.

Si la rotation est motivée par la suspicion plutôt que par la politique, le processus d’incident prime sur le plan de confort. Révoquez ce que les preuves exigent et acceptez le travail supplémentaire sur la liste des appareils. Cette décision appartient au responsable de l’incident, pas à celui qui tient par hasard le formulaire de réinitialisation du mot de passe.

Remplacez la valeur stockée là où elle vit

Changez l’identifiant via le mécanisme documenté par le service, puis mettez à jour la copie enregistrée ou exécutez le flux de connexion sur chaque appareil que vous voulez conserver. Ne modifiez pas une configuration générée derrière un gestionnaire qui la réécrit, car le gestionnaire restaure l’ancienne valeur à sa prochaine exécution et la modification devient une panne différée. Mettez à jour la source que lit le gestionnaire, ou utilisez le magasin d’identifiants propre au client. Dans tous les cas, l’appareil doit finir avec la nouvelle valeur à l’endroit où le client lit réellement.

Un client qui stocke un fichier de mot de passe a besoin que le fichier soit réécrit, tandis qu’un client qui demande a besoin d’une connexion achevée. NetworkManager garde le secret dans le profil de connexion, donc le changement passe par nmcli plutôt que par un éditeur de texte :

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Un profil qui lit un fichier d’identifiants est un troisième cas. Remplacez le contenu de ce fichier, gardez ses permissions fermées et rechargez le client au lieu de modifier le profil qui pointe vers lui. Le profil n’a pas changé ; seul le secret qu’il lit a changé.

Reconnectez chaque appareil prévu une fois, délibérément, et regardez lesquels échouent. Si un appareil continue d’échouer, examinez le compte vers lequel il pointe et le magasin qu’il lit avant de changer à nouveau le mot de passe, car un second changement multiplie les copies à mettre à jour. Un appareil qui échoue deux fois pointe généralement vers le mauvais compte ou lit un magasin que vous n’avez pas encore trouvé. Corrigez cela, puis reconnectez.

Les sessions et les jetons survivent au mot de passe

Changer le mot de passe ne prouve pas que les sessions existantes ou les certificats séparés ont été révoqués. Certains services maintiennent une session vivante jusqu’à son expiration ou sa fin explicite, et les jetons émis portent leur propre durée de vie. Vérifiez ce que le service fait réellement au lieu de supposer que le changement a été global. Si le changement a été motivé par la suspicion, terminez explicitement les sessions et confirmez le résultat.

Les recommandations sur le cycle de vie des identifiants du NIST SP 800-63B maintiennent les authentificateurs et les sessions dans des catégories distinctes, ce qui explique pourquoi un changement de mot de passe et une déconnexion globale sont des opérations différentes. Traitez-les comme deux tâches avec deux critères d’achèvement. La première est terminée quand la nouvelle valeur fonctionne, et la seconde quand les anciennes sessions ont disparu.

Consignez l’achèvement sans écrire le nouveau mot de passe dans le registre. Un journal de rotation contenant l’identifiant est un nouvel incident qui attend sur un disque partagé. Notez la date, les appareils mis à jour et les appareils encore en attente.