Pourquoi les clés de serveur et les identifiants utilisateur exigent des propriétaires distincts

La clé qui prouve que votre passerelle est bien elle-même et l’identifiant qui dit qu’une personne peut se joindre sont tous deux des secrets, et c’est là que la ressemblance s’arrête. L’un identifie un service auprès de chaque client ; l’autre identifie un utilisateur auprès de ce service. Les mélanger économise une étape lors de l’installation et coûte un après-midi lors d’un incident, car la restauration de chacun n’est pas la même opération. La séparation est ennuyeuse à mettre en place et mémorable à omettre.

Deux secrets, deux propriétaires différents

La passerelle détient une clé privée ou un certificat dont l’unique tâche est de prouver son identité pendant la poignée de main. Les clients ont besoin du matériel public correspondant pour la vérifier, et ils n’ont jamais besoin de la moitié privée. C’est cette asymétrie qui rend possible l’authentification du serveur sans donner à chaque utilisateur la capacité d’imiter le serveur.

Le matériel utilisateur va dans l’autre sens. Une clé privée de client, un certificat de client ou un mot de passe démontrent que cette personne ou cet appareil précis a reçu un accès. On s’attend à ce qu’il soit distribué, copié entre appareils et finalement révoqué.

WireGuard rend la séparation évidente parce que chaque participant possède une paire de clés : la clé privée du serveur reste sur le serveur, et un fichier de configuration que vous donnez à un utilisateur contient sa propre clé privée plus la clé publique du serveur. Un profil qui contient la clé privée du serveur n’est pas un raccourci, c’est une compromission qui attend un partage de fichier.

Trois questions qui décident de la séparation

Demandez qui doit pouvoir lire le secret, ce qu’une exposition permettrait à un attaquant de faire et si le correctif est une révocation ou une reconstruction du service.

Si un utilisateur peut le lire et que cela prouve l’identité de la passerelle, la réponse à la deuxième question est que l’attaquant peut imiter votre serveur auprès de chaque client — le pire résultat, car les clients sont conçus pour faire confiance à cette identité. Si cela ne prouve qu’un utilisateur, l’exposition accorde à cet utilisateur l’accès à un pair, et la révocation est une opération courante. S’il s’agit d’une clé d’autorité de certification, l’exposition est pire que les deux, puisque l’attaquant peut fabriquer des identités auxquelles chaque extrémité fait confiance.

Ces trois réponses produisent la règle de stockage : la clé de CA vit hors ligne ou dans un coffre, la clé de la passerelle vit sur la passerelle, et les clés utilisateur vivent chez les utilisateurs. Toute disposition qui place les trois dans un seul répertoire par commodité a transformé une décision en accident.

Ce dont un client a réellement besoin

Un client a besoin du certificat public ou de la clé publique du pair, du matériel de CA ou de l’empreinte à laquelle il doit faire confiance, de sa propre clé privée et des détails de l’extrémité. Cette liste ne contient rien qui appartienne à l’identité privée de la passerelle.

La documentation est l’endroit où cela fuit. Un guide qui dit de copier le répertoire du serveur et de supprimer ce dont vous n’avez pas besoin a déjà enseigné le mauvais modèle, car le fichier qui reste après l’étape de suppression est rarement vérifié par quiconque.

Révquez un utilisateur sans toucher à la passerelle

Comme les identités utilisateur sont émises séparément, elles peuvent être retirées séparément. Un déploiement à base de certificats révoque le certificat client et publie une liste de révocation mise à jour ; un déploiement WireGuard retire l’entrée du pair de la configuration du serveur. Aucune de ces opérations ne change la clé propre de la passerelle.

Conservez le registre des émissions, sinon vous ne saurez pas quelle identité retirer. Un tableur suffit, à condition qu’il nomme la personne, l’appareil, le numéro de série ou la clé publique et la date, et à condition que quelqu’un en soit responsable après le départ de la personne qui l’a construit.

Les commandes ci-dessous inspectent un certificat client puis le révoquent via une autorité de style OpenSSL, ce qui est le flux qu’easy-rsa enveloppe :

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publiez la nouvelle liste là où les clients la vérifient, sinon la révocation est une note dans un fichier qui ne change rien. Si votre passerelle accepte des certificats client sans consulter de liste de révocation, dites-le explicitement plutôt que de laisser entendre que la révocation fonctionne.

Gardez les sauvegardes aussi séparées que les secrets

Une archive de reconstruction contient légitimement la clé de la passerelle et le matériel de CA, car sans eux une restauration ne peut pas reproduire le service. Un paquet d’installation client ne doit pas, et les deux ne doivent pas être stockés ensemble. Étiquetez chaque archive selon qui peut la détenir, pas selon la date de création. Cette étiquette est ce qu’un administrateur fatigué lit à deux heures du matin.

Cette distinction fixe aussi qui peut récupérer chacune. Administrer la passerelle, émettre des identités utilisateur et lire des sauvegardes sont trois pouvoirs différents, et une personne qui en a besoin d’un n’a pas automatiquement besoin des autres. Écrivez ces permissions, puis vérifiez-les par rapport à ce que votre stockage autorise réellement, car l’héritage des répertoires accorde silencieusement plus que ce que la politique prévoit.