Votre clé VPN est lisible par tous : ce qu’il faut corriger

Le premier signe est généralement un avertissement, pas une panne. Un client refuse de charger une clé parce que le fichier est lisible par le groupe ou par tous, ou un audit de sécurité trouve client.key en mode 644 dans un dossier de profil qui contient aussi des paquets exportés. Rien n’a encore échoué, et c’est précisément pourquoi l’avertissement est ignoré. La clé fonctionne, le tunnel monte, et le fichier est lisible par chaque compte de la machine.

Le symptôme est un avertissement de permissions, pas une panne

Sur un système de type Unix, une clé privée ne devrait être lisible que par le compte qui exécute le service. Un mode 600 avec le bon propriétaire est la disposition habituelle. Un mode 644 signifie que tout utilisateur local peut copier la clé, et sur un hôte de compilation partagé, c’est un public bien réel.

Les clients qui vérifient cela vous rendent service. Ceux qui ne le font pas ne prouvent pas que le fichier est sûr, et une connexion réussie ne dit rien sur qui d’autre peut lire le matériel qui l’a rendue possible. Traitez l’avertissement comme l’ensemble du constat. Il est exact et il est arrivé avant que quiconque copie le fichier.

Adaptez le mode à l’identité du service

L’accès réservé au propriétaire convient à une clé utilisée par ce propriétaire. Un service doté d’un groupe partagé volontaire peut avoir besoin d’une autre disposition maîtrisée, comme la lecture de groupe sur une clé appartenant à un compte de service. Appliquer aveuglément un seul mode numérique à tous les fichiers casse les clients pris en charge, et chmod -R 777 ne règle rien.

Vérifiez le propriétaire et le compte de service avant de changer quoi que ce soit. Les certificats CA publics et les clés d’identité privées ont des exigences de secret différentes même lorsqu’ils se trouvent dans le même dossier, donc un mode récursif appliqué à tout le dossier traite les deux comme un seul objet.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

Sur d’autres plateformes, utilisez le magasin de clés ou le modèle de contrôle d’accès documenté plutôt que de traduire les modes Unix en supposition. Un nom de fichier finissant par private est une étiquette, pas un mécanisme d’application.

Trouvez les copies que le mode ne couvre pas

Les éditeurs, les archives de sauvegarde, les profils exportés et les paquets temporaires peuvent chacun conserver la même identité. Protégez ces copies selon leur contenu, car resserrer le fichier d’origine ne fait rien pour celle de l’archive tar du mois dernier.

Une phrase secrète sur un fichier de clé est utile pour du matériel stocké et ne justifie pas de publier le fichier chiffré à côté de son mot de passe. Les permissions protègent l’objet actuel du système de fichiers ; elles ne disent rien d’un identifiant déjà copié ailleurs.

Cherchez les copies avant de déclarer le travail terminé : grep -rl la ligne d’en-tête de la clé dans les répertoires probables et un coup d’œil aux exclusions de sauvegarde. Le résultat est généralement plus intéressant que le fichier de départ.

Après la correction, vérifiez et renouvelez

Vérifiez que le service prévu s’authentifie toujours, puis confirmez qu’aucun compte inutile n’a obtenu d’accès. Limitez la sortie de diagnostic aux métadonnées, car imprimer la clé n’est pas nécessaire pour prouver que le fichier est lisible et cela met le matériel dans un journal.

Si la clé a été exposée, resserrez le mode, puis remplacez l’identifiant et révoquez l’ancien. La spécification POSIX chmod explique ce que signifie chaque bit de mode, ce qu’il vaut la peine de savoir avant que le prochain audit vous demande de justifier le nombre choisi.