团队凭据保管库：共享机密本该如何运作

共享为什么让个人管理器的模型失效

个人管理器只有一个所有者、一个主密码、一组设备。团队凭据保管库必须回答个人工具从不面对的问题：一个机密要怎样才能送到同事手上，而服务器在传输途中和存储时都读不到它？你怎么证明接收人真的是你的同事，而不是往目录里塞了一把公钥的攻击者？这个人离开时，机密会怎么样？从个人保管库里复制粘贴到聊天工具，一个问题也没回答，而这正是今天多数团队的实际做法。

机制，一步一步来

1. 每个保管库都有自己的密钥

保管库里的条目，包括保管库的名称，都用一把只存在于成员设备上的密钥加密。在 Keyvaci 中，这是 XChaCha20-Poly1305，密钥最终由每位成员的主密码经 Argon2id 派生，全程都在浏览器里完成。

2. 共享是公钥密码学，不是数据库里的一行

授予访问权限，是用接收人的公钥去加密保管库密钥。服务器转发的是密文；它打不开自己转发的东西。

3. 身份由人来副署

任何共享系统里最危险的一刻，都是去信任一把公钥。Keyvaci 要求管理员通过另一条渠道核对每位成员的密钥校验码，再用组织签名密钥为它副署。任何一次共享之前，设备都会先校验这个签名。攻击者要骗过的，从此是一个活人，而且要在线外骗过，不再是一张查询表。

4. 角色被执行两遍

仅查看、可编辑和全部权限（管理员）这几种角色，既由服务器检查，也体现在每位成员实际持有的密码学材料上。数据库出错，还不足以让一个机密泄露。

5. 撤销会重新加密

移除一个人，会更换保管库密钥，并在你的设备上把每一个条目重新加密。他的笔记本电脑还记得什么，从此不再重要。这是你评估任何产品时都该要求的性质；细节见我们的离职流程指南。

服务器应该知道什么

几乎什么都不知道：组织里有哪些人，存在哪些保管库，谁持有对每个保管库的授权，以及一份只可追加的安全事件日志。保管库的名称、条目的内容，以及每一把密钥，都保持为密文。我们在安全页面上公开了这份完整清单，因为一个拿不出这张表的团队保管库，是在索要它还没挣到的信任。