Mot de passe VPN enregistré : qui peut le déchiffrer et quand
Un texte chiffré dans un fichier client ne prouve presque rien. Identifiez le propriétaire de la clé, l'usage à l'exécution et les contrôles d'accès avant de juger le stockage.
Un client VPN qui affiche un mot de passe chiffré dans son XML ne vous a presque rien dit. Le texte chiffré répond seulement que la valeur n'est pas stockée en clair dans cette représentation. Qui peut le déchiffrer, avec quelle clé et dans quel contexte utilisateur sont les questions qui décident si le stockage aide. Répondez-y avant de qualifier le fichier de sûr ou de non sûr.
Déterminez quel objet est stocké
Partez du modèle de stockage documenté du produit. Un client peut stocker un mot de passe récupérable, un jeton ou une référence à un magasin d'identifiants, et chacun présente une exposition différente. Le nom de l'élément XML n'est pas la conception, et une chaîne qui ressemble à du base64 n'est pas non plus une preuve de chiffrement.
Demandez au fournisseur ou à l'administrateur quel composant lit la valeur au moment de la connexion.
Identifiez ensuite l'API de protection si elle est documentée. Sous Windows, CryptProtectData protège les données avec une clé dérivée des identifiants de session de l'utilisateur qui chiffre, et son option de portée machine change qui peut déchiffrer. C'est un exemple concret de l'importance de la portée. Ce n'est pas la preuve qu'un client VPN donné utilise cette API.
Séparez une copie volée de l'usage à l'exécution
Un client qui se reconnecte sans vous demander a besoin d'un moyen pris en charge de récupérer l'identifiant. Protéger une copie de sauvegarde ne supprime pas cette capacité. Tout programme exécuté dans le bon contexte utilisateur peut emprunter le même chemin, et c'est pourquoi le point de terminaison lui-même se trouve à l'intérieur de la frontière de confiance. Les permissions de fichier et les privilèges de processus resserrent cette frontière ; ils ne la suppriment pas.
C'est la distinction que rate généralement une affirmation sur un fichier hors ligne. Le chiffrement au repos peut arrêter quelqu'un qui copie un fichier sans le compte. Il n'arrête pas le code qui s'exécute sous ce compte.
Les deux affirmations peuvent être vraies en même temps, et la seconde est celle qui compte lors de la réponse à incident.
Lisez les contrôles d'accès qui s'appliquent réellement
Vérifiez l'ACL du fichier et le répertoire parent, pas seulement le mode du fichier. Sous Windows, comparez les permissions effectives du profil utilisateur avec celles du service ou de la tâche planifiée du client. Un secret protégé pour un utilisateur n'est pas automatiquement protégé contre un administrateur, ni automatiquement exposé à celui-ci.
icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv
Notez quelle identité exécute le client, car cette identité est le sujet du déchiffrement.
Pour un parc géré, le contrôle pertinent peut être la gestion des appareils plutôt que le fichier. Demandez si l'identifiant est déposé en séquestre, s'il peut être révoqué à distance et quelle est la procédure en cas de perte d'un appareil.
Prévoyez l'exposition au lieu de tester le déchiffrement
N'exécutez pas un outil d'extraction inconnu sur le fichier pour démontrer un point. Il peut fonctionner, il peut endommager le profil et, dans tous les cas, il modifie les preuves. Utilisez la conception documentée et une évaluation autorisée si une vérification est réellement nécessaire.
Si l'exposition est établie, faites tourner l'identifiant chez le propriétaire de l'identité.
Supprimer l'entrée enregistrée n'est pas une révocation. Cela peut empêcher ce client de proposer à nouveau la valeur, et cela ne change rien à une copie déjà prise ou à une session déjà autorisée. Remplacez l'identifiant, terminez les sessions que le propriétaire peut terminer et consignez ce qui a été renouvelé et quand.
Les questions pour un examen fournisseur
Demandez quel secret est stocké, quel composant l'utilise, quelle clé utilisateur ou machine le protège, quels contrôles d'accès s'appliquent à l'usage normal et aux sauvegardes, et comment la politique d'enregistrement et l'invalidation à distance sont gérées. Ces cinq réponses décrivent la conception ; le XML non.
Conservez les réponses avec le dossier de déploiement pour que le prochain relecteur ne refasse pas l'exercice.
Un identifiant enregistré est un compromis entre commodité et exposition. Faites ce compromis délibérément et notez qui l'a accepté.