你的DevOps工程师周五辞职 没有通知 包括主密码 或者更简单一点: 你公司唯一的创始人 从两周的旅行回来... ...
无论哪种方式,房间里有人问我们几乎每一次关于Passwork的技术电话中都听到的问题:"这有后门吗?
解开一切的方法?" 诚实的回答是否定的,这是故意的.
任何能立即解密密码管理器中所有数据的"还原一切"按钮,都是一个巨大的单一故障点(SPOF).
如果在紧急情况下建造后门,也为攻击者建造了前门.
妥协一个账户,得到一切。
这不是一个特征, 这是整个系统的威胁模型 崩溃成一个单一的证书。
这个帖子是关于我们如何设计一个没有按钮的零知识密码管理器的访问恢复.
而不是一个神模式的管理员,我们把恢复分成三个孤立的地层,每个地层都有一个狭窄的工作,在它无法做到的事情上有一个硬边界.
我们认为模式概括了我们自己的产品,所以我们分享推理,而不仅仅是特征列表.
零知识困境 零知识架构意味着服务器只见过密码文本.
加密和解密发生在客户端;服务器存储了加密blobs,并且没有加密授权,一个包裹的密钥交给特定用户用于特定的金库,就无法读取.
这对安全来说是件大事,对任何认为恢复工作“某种方式”的人来说都是可怕的。
如果没有人在事故发生前设置了恢复路径,那么数学是毫不含糊的:数据已经消失.
不是"很难得到" 不是"需要一张支持票" 不见了,因为服务器从没有钥匙 我们把这当成一个正确的权衡, 而不是一个工作错误。
替代品,一个总是可以按需要解密的服务器,意味着金库中的每一个密码都是一个服务器妥协而远离突破.
但是这确实意味着恢复不能是事后思考.
它必须是建筑,决定和配置 在任何人需要它之前, 而不是在凌晨2点的事件中即兴。
因此,设计问题变成了:你如何让一个组织从一个账户、一个设备或一个雇员的损失中恢复过来,而从未产生一个能够解密整个系统的单一证书?
解构"神模式":我们的三级恢复模式 我们最终把复苏分成了三个层次,每个层次都解决了一个狭隘的问题。
任何一种,单独或结合,都无法产生万能的主钥匙.
这就是重点。
第1级:基础设施一级,应急控制台 第一层解答了登录问题,而不是数据问题:如果所有者(顶级系统管理员)无法进入自己的账户和正常恢复,像电子邮件链接一样,没有可用的呢?
为此,我们建立了一个应急控制台:一套CLI命令,运行在服务器本身,而不是通过网络UI.
拥有服务器访问权限的管理员可以在正常恢复路径不可用时使用它来重置所有者的密码或两个要素认证.
有两件事是故意的: 它需要服务器级别的访问,通过SSH或控制台,而不是接口中的按钮.
紧急命令被锁定在服务器管理员必须明确启用的州旗后才能运行.
紧急命令默认会被禁用,只有在服务器管理员明确启用所需的州旗后才能使用.
特意活化能保护恢复路径不被意外使用,使其无法单独拥有网络应用程序访问权限的人.
关键边界是应急控制台恢复登录访问,同时保留现有的密码访问模式.
重新设定业主的密码让他们再次签入,并精确地写下事件发生前的金库权限.
破解瓦片仍然取决于事先发放的密码学补助金。
换句话说,紧急控制台解决了账户接入问题,whil