Mots de passe VPN ou certificats client : ce qui se rétablit le plus vite

Un déploiement demande un nom d’utilisateur et un mot de passe, un autre un certificat client, et un troisième les deux. Le choix change bien plus que la fenêtre de connexion : il décide comment les identifiants sont émis, comment ils expirent, à quoi ressemble une restauration à 2 heures du matin et qui peut révoquer l’accès pour exactement un appareil. Comparez le cycle de vie opérationnel plutôt que la boîte de dialogue.

Un mot de passe est un secret de compte validé par un processus d’authentification, tandis qu’un certificat est une identité plus la preuve de possession de sa clé privée. Ce sont des objets différents avec des modes de défaillance différents.

Deux preuves différentes, deux invites différentes

Un mot de passe prouve la connaissance d’un secret partagé, donc le serveur compare un hachage et le système de comptes possède le cycle de vie. Un certificat prouve la possession d’une clé privée, et le serveur vérifie une chaîne de signatures jusqu’à une CA de confiance. Le second peut identifier un appareil plutôt qu’une personne, ce qui explique pourquoi les déploiements en émettent souvent un par ordinateur portable. Une phrase secrète protégeant un fichier de clé est encore autre chose : elle garde le fichier au repos et n’est pas le mot de passe du compte VPN.

La vérification du serveur reste nécessaire dans toutes les combinaisons. Des identifiants valides envoyés à un point de terminaison dont vous ne vérifiez plus l’identité restent des identifiants remis à celui qui a répondu, ce qui explique pourquoi le contrôle du certificat de serveur appartient au profil de base et non à une étape de dépannage.

L’émission, l’expiration et la révocation sont le vrai coût

Les mots de passe sont bon marché à émettre et coûteux à soutenir : réinitialisations, politique, réutilisation et file d’attente du support. Les certificats déplacent ce coût en amont, où il faut une CA, un processus de signature et un canal de distribution, puis ajoutent un calendrier d’expiration dont personne ne se souvient. Les deux nécessitent une révocation planifiée. Un certificat révoqué a besoin d’une CRL que chaque serveur lit réellement, et un compte désactivé a besoin que le backend d’authentification le refuse à la prochaine connexion et non à la prochaine synchronisation.

Aucun des deux mécanismes ne devient sûr parce qu’il existe. La question est de savoir quel cycle de vie l’équipe peut exploiter de manière cohérente.

Ce qui casse lorsqu’un appareil est perdu

Pour un ordinateur portable perdu, retirez l’autorisation que cet appareil a réellement utilisée. Une réinitialisation de mot de passe ne révoque pas son certificat, et l’émission d’un nouveau certificat ne change pas le mot de passe d’un compte sans rapport. Des identités distinctes par appareil rendent possible un retrait ciblé, tandis que des identifiants partagés signifient que le retrait d’un appareil en affecte plusieurs. Rédigez la procédure de restauration pour chaque mécanisme avant d’en avoir besoin, y compris qui peut signer un certificat de remplacement en dehors des heures ouvrables.

Exercez le chemin de révocation au lieu de le supposer : révoquez une identité de test, confirmez que le serveur la refuse sur une nouvelle connexion, puis restaurez-la. Un processus de révocation jamais exercé tend à échouer exactement au moment où on en a besoin.

Exploiter les deux sans doubler le travail

De nombreux déploiements combinent délibérément les deux : un certificat pour l’appareil et un identifiant de compte pour la personne, de sorte qu’un ordinateur portable volé ne suffit pas et qu’un mot de passe divulgué ne suffit pas non plus. Cette combinaison ne rentre dans ses frais que si les deux cycles de vie restent séparés et que les deux sont automatisés. Sinon, le support gère deux files et le gain de sécurité reste théorique.

Choisissez la méthode que les clients du service et les outils de gestion prennent réellement en charge. Affaiblir la vérification pour qu’un profil mal adapté se connecte inverse tout l’intérêt, et un profil modifié jusqu’à ce qu’il se connecte est souvent un profil qui ne vérifie plus ce pour quoi il a été conçu.

Notez quelle preuve chaque déploiement exige et comment chacune est révoquée. Le prochain incident demandera exactement cela.