一种部署要求用户名和密码,另一种要求客户端证书,第三种要求两者兼有。这个选择改变的不只是登录框:它决定了凭据如何签发、如何到期、凌晨 2 点的恢复流程是什么样,以及谁能精确吊销单台设备的访问权限。要比较的是运维生命周期,而不是对话框。

密码是由认证流程校验的账户秘密,而证书是身份加上对其私钥的持有证明。二者是不同的对象,失效方式也不同。

两种不同的证明,两个不同的提示框

密码证明知道某个共享秘密,因此服务器比对哈希,生命周期由账户系统掌握。证书证明持有私钥,服务器会验证一条到其信任的 CA 的签名链。后者可以识别设备而非个人,所以部署常常为每台笔记本签发一张。保护密钥文件的通行短语又是另一回事:它守护静态存储的文件,并不是 VPN 账户密码。

在任何组合下,服务器验证都仍然必要。把有效凭据发给一个你已不再核验其身份的端点,凭据依然等于交给了应答的一方,因此服务器证书校验属于基础配置,而不是排障步骤。

签发、到期和吊销才是真正的成本

密码签发便宜、支持昂贵:重置、策略、复用以及服务台排队。证书把这项成本前移,需要 CA、签发流程和分发渠道,随后还要加上没人记得的到期日历。两者都需要规划吊销。被吊销的证书需要每个服务器都真正读取的 CRL,被停用的账户需要认证后端在下一次连接时而不是下一次同步时拒绝它。

任何机制都不会仅仅因为存在就变得安全。问题在于团队能够一致地运营哪一种生命周期。

设备丢失时坏掉的是什么

笔记本丢失时,撤销那台设备实际使用过的授权。重置密码不会吊销它的证书,签发新证书也不会改变无关账户的密码。按设备分离身份可以实现定向移除,而共享凭据意味着一台设备下线会影响多台。在需要之前就写好每种机制的恢复流程,包括谁能在非工作时间签署替换证书。

演练吊销路径,而不是假设它:吊销一个测试身份,确认服务器在新连接上拒绝它,然后恢复。从未演练过的吊销流程,往往恰好在需要时失败。

在不使工作量翻倍的前提下同时运行两者

许多部署有意把两者结合起来:设备用证书,人员用账户凭据,这样被盗的笔记本不够,泄露的密码也不够。这种组合只有在两条生命周期保持分离且都实现自动化时才划算。否则服务台要跑两条队列,安全收益仍停留在理论层面。

选择服务的客户端和管理工具真正支持的方法。为了让不匹配的配置连上而削弱校验,等于本末倒置,而一份被改到能连上的配置往往已经不再检查它本该检查的东西。

记录每种部署需要哪种证明,以及各自如何吊销。下一次事故问的正是这个。

相关文章