已保存的 VPN 密码：谁能解密以及何时能解密

一个在 XML 中显示加密密码的 VPN 客户端，其实几乎什么也没告诉你。密文只能说明该值在那份表示里不是以明文保存的。谁能解密、用什么密钥、在哪个用户上下文中解密，这些才是决定存储是否有帮助的问题。在把文件判定为安全或不安全之前，先回答这些问题。

确认存储的是什么对象

从产品有文档记录的存储模型入手。客户端可能保存可恢复的密码、令牌或对凭据存储的引用，每种形式暴露面都不同。XML 元素名并不等于设计，看起来像 base64 的字符串也不是加密的证据。

向厂商或管理员确认连接时是哪个组件读取该值。

然后确认保护接口是否有文档说明。在 Windows 上，CryptProtectData 用由加密用户登录凭据派生出的密钥保护数据，而机器级选项会改变谁能解密。这是说明作用域为何重要的具体例子。它并不证明某个特定 VPN 客户端使用了该接口。

把被盗副本与运行时用途分开看

一个无需询问你就自动重连的客户端，必须有受支持的方式来恢复凭据。保护备份副本并不会消除这种能力。任何在正确用户上下文中运行的程序都可能走同一条路径，所以端点本身就在信任边界之内。文件权限和进程特权会收窄这条边界，但不会消除它。

离线文件类说法通常就错在这个区分上。静态加密能挡住没有账户却复制单个文件的人。挡不住以该账户身份运行的代码。

两句话可以同时成立，而在事件响应中起决定作用的是后一句。

读懂真正生效的访问控制

检查文件的 ACL 及其上级目录，而不只是文件模式。在 Windows 上，把用户配置文件的有效权限与客户端服务或计划任务的有效权限作比较。为某个用户保护的机密，不会自动对管理员受保护，也不会自动对管理员开放。

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

记录是哪个身份在运行客户端，因为该身份就是解密主体。

对于受管设备群，相关控制可能是设备管理而不是文件。要问凭据是否托管、能否远程吊销，以及设备丢失时的流程是什么。

为暴露做预案，而不是去测试解密

不要为了证明一个观点就对文件运行陌生的提取工具。它可能奏效，可能损坏配置文件，而且无论结果如何都会改变证据。如果确实需要验证，请使用有文档记录的设计和经授权的评估。

如果确认已经暴露，就在身份所有者处轮换凭据。

删除已保存条目并不等于吊销。它能让该客户端不再提供该值，但对已被取走的副本或已被授权的会话毫无作用。要更换凭据、结束所有者能结束的会话，并记录轮换了什么、何时轮换。

厂商评审要问的问题

要问清存的是哪个机密、哪个组件使用它、由用户密钥还是机器密钥保护它、日常使用与备份分别适用哪些访问控制，以及保存策略和远程失效如何管理。这五个答案才描述设计，XML 描述不了。

把答案与部署记录放在一起，好让下一位评审不必重复这项工作。

保存凭据是便利与暴露之间的取舍。要有意识地做这个取舍，并写下是谁接受了它。