团队密码管理器：该评估什么
团队密码管理器不是「加了很多席位」的个人产品。它的工作不一样：它必须能扛住人员的加入与离开，还必须能回答「谁在什么时候访问过什么」这类问题。大多数工具是按共享功能被打分的，而在第二个问题上不及格。
本文就是这份评估清单，外加：如果你想在自控的基础设施上使用共享集合，OpenKey 的模型是如何运作的。
真正不同的那些要求
1. 带真正访问控制的共享保险库
「能和团队共享」只是入场券。真正要紧的是：访问权限是按集合还是按人、能否在不暴露全部内容的前提下共享一个子集，以及一个外包人员能否恰好只看到一个服务。
- 要么全给要么不给的共享方式很快就撑不住，它撑不过大约五个人。
- 按集合共享才是最低限度的可用模型。
- 一旦有了审阅者和审批者，你要的就是基于角色的访问控制（admin / member，最好再加上只读）。
2. 真能收回访问权的离职处理
这正是把个人工具与团队工具区分开的那条要求，也是最常被缺掉的那条。
有人离开时，你需要知道：
- 他们是 立即 失去访问权，还是要等到下次同步？
- 他们是否仍持有共享凭据的 离线副本 — 如果有，你要怎么处理？
- 你能否撤销一次共享，并确定那份副本已经没了？
- 组织所有权和管理员权限能否在他们离开后存续，还是团队就此失去了自我管理的能力？
答不上这些问题的工具，是一件伪装成生产力功能的合规隐患。
3. 自动化与机器访问
在 UI 里操作的人只占问题的一半。另一半是：
- 用于 CI 和脚本的 CLI
- 用于开通配置和内部工具的 API
- 不会因为某个人离开就过期的 服务账户
- 从目录服务或存有旧共享凭据的表格中做 批量导入
有基础设施的团队通常这四样都需要。一个只有浏览器扩展的密码管理器，经不起一次部署流水线。
4. 零知识，以及它在商业上意味着什么
对个人来说，零知识是一项隐私偏好。对组织来说，它是一种合规立场：它决定了「我们的供应商被攻破了」与「我们的供应商被攻破了，而他们手里只有密文」之间的区别。
它同时也会限制功能。有些厂商会提供账户恢复、管理员重置，或需要服务器端明文的策略强制 — 而其中每一项都在有意削弱零知识属性。两种立场都站得住脚；你应该在知情的前提下做出选择，而不是在事后的事故复盘中才发现。
5. 审计轨迹
「我能否证明 3 月 3 日谁访问过生产数据库的密码？」这需要一份访问日志：按明确期限保留，并且可以导出给审计方。
诚实地说明它的边界：在零知识系统里，管理员能看见某条目 被访问过，而看不见 它包含什么。这是正确的行为，同时也是你的审计所能证明之事的一个限制。
6. 自带基础设施
总有一次安全评审会问：共享凭据会不会离开你的网络。可选的答案是：签有合同 DPA 的厂商托管、私有云，或自托管。自托管是其中唯一一种你能亲自验证的，也是唯一一种你能拿出证据说明服务器上只有密文的。
7. 经得住人数增长的成本模型
按席位定价，而每个外包人员、每个服务账户、每个只读审计员都要占一个席位的话，账单很快就变得可观。要查清楚：
- 只读席位的定价
- 服务账户是否免费
- 已停用的用户是否仍然计数
- 是否有可用于评估的免费层级
面向团队的评分表
| 标准 | 权重 | 为何要紧 |
|---|---|---|
| 离职处理与撤销 | ×3 | 最多工具不及格的那条要求 |
| 按集合的访问控制 | ×3 | 防止一个外包人员看见全部内容 |
| CLI 与 API 访问 | ×3 | 机器占了你用户的一半 |
| 可验证的零知识 | ×3 | 合规与泄露风险敞口 |
| 服务账户 | ×2 | 长期存在的非人类访问 |
| 带保留期限的审计日志 | ×2 | 证明历史上的访问 |
| 支持自托管 | ×2 | 把凭据留在你的网络之内 |
| 紧急访问 | ×1 | 管理员失联时的应急通道 |
| 批量迁移工具 | ×1 | 摆脱那张共享表格 |
OpenKey 如何处理团队访问
OpenKey 的共享模型正是为此而建，而且它在几个地方有意做得不同寻常 — 在你围绕它设计流程之前，值得先弄清楚。
组织与共享集合
共享需要 Pro 和一台配置好的自托管服务器，并且所有人都在同一个服务器 URL 上。模型如下：
- 发布身份密钥，这样对端才能为你包装密钥。在 OpenKey 中这一步是在浏览器扩展的独立（服务器）模式下完成的 — 应用的「设置 → 数据」页面里没有这个操作。
- 创建一个组织，并在它下面建立共享集合。客户端加密组织名称，并为你这位所有者封装一把组织密钥。
- 通过邮箱邀请成员（他们必须已经存在于服务器上），角色为
admin或member。你的客户端用他们已发布的身份密钥封装组织密钥，并发出这份邀请。 - 对方在待处理邀请中接受并同步；共享集合就会出现。
服务器把组织名称、共享载荷和身份密钥都存为不透明密文。它从不解包组织密钥。
管理员的权限：撤销待处理邀请、更改角色、移除成员。有一处限制需要提前规划 — 所有者不能离开组织，而所有权转让也不是一条独立的恢复路径。尽早指定第二位所有者，而不是把它当成一个走过场。
条目共享是快照，不是实时文档
这是最重要的一条操作细节。当你把单个条目或一个集合共享给别人时：
- 加密载荷在 共享那一刻被冻结，并在对方接受时复制进他的保险库。
- 之后你对自己那份的修改 不会 推送给对方。
- 撤销会阻止待处理的接受。它 不会 删除接收方已经导入的副本。
所以条目共享的行为像是递给对方一个密封信封，而不是共享一份实时文档。凡是必须保持同步的东西 — 一个共享的服务账户、一个全团队共用的内部工具 — 都应该用组织共享集合，成员们在一把共享的组织密钥下持续读取同一份密文。
把这一点搞反，就会产生那个经典故障：你更新了一个共享密码，以为所有人都拿到了新的，而半个团队手里拿的还是你一个月前就轮换过的凭据。
OpenKey 不做的事
值得直说，因为它会影响你何时应该改选别的东西：
- 客户端没有管理员强制的策略引擎。 没有任何服务器端规则能在整个团队范围内强制一个最小密码长度。
- 没有自动化的离职处理钩子。 移除成员是手动操作：在组织中撤销或移除，然后处理那些已经被接受的条目共享。
- 没有 SCIM 或目录同步。 成员资格通过组织与共享 API 管理。
- 没有服务器端的条目访问审计日志。 服务器看不到明文，因此无法记录被读取了什么。
- 同步是按 revision 的最后写入获胜，而不是 CRDT。 并发编辑可能互相覆盖；重要时请一次只在一台设备上编辑。
如果你需要自动化的离职处理、策略引擎，或合规级访问日志，那就选一款商业团队产品。OpenKey 是为那些希望把密码学放在自己客户端上、并且愿意自己运行协作层的团队准备的。
向团队推广
- 先把服务器跑起来。 服务器设置，并按加固清单加固。
- 创建你自己的账户，从扩展发布身份密钥。
- 创建组织，然后按每个服务或团队边界建一个共享集合。先从共享的基础设施账户开始 — 出错时破坏最大的就是这些。
- 在邀请之前，为每个人发布身份密钥，否则封装那一步找不到他们。
- 小批量邀请，并在加入下一批之前确认某位成员确实能打开一个共享集合。
- 搬走那张共享表格。 目前还躺在团队表格里的每一个凭据，都是你优先级最高的导入项。
- 在需要之前就写好离职处理流程。 写下来就两步：从组织中移除；复查并撤销条目共享。
一分钟版本
首先按离职处理、按集合的访问控制和机器访问来评估 — 而不是按共享功能。优先选择你能亲自验证的零知识，并查清厂商的恢复与管理员功能是否悄悄地需要服务器端明文。如果你要自托管，请记住条目共享是快照：任何必须保持最新的内容，都要用组织共享集合。