SPEC 6 — 城堡的钥匙

描述#

项目始终与受限资源进行交互。例如，访问添加和删除团队成员、授予提交权限或将文件上传到特定主机。

记录资源对于确保不间断操作至关重要。团队成员了解谁拥有资源访问权限以及如何获取资源访问权限非常重要。例如，如果需要通过 SSH 将更新后的项目文档上传到远程服务器，哪些团队成员可以执行此操作，以及发布经理如何请求访问权限？

此外，项目开发人员有时需要共享秘密，例如服务器密码和社交媒体登录信息。通常，这些秘密会分发给需要它们的人，而没有任何集中系统来跟踪秘密或谁有权访问它们。当需要访问服务器时，通常会争先恐后地寻找拥有凭据的人。

本 SPEC 讨论了分发秘密的系统要求，提供了一个示例实现，并列出了合适的托管服务。

需要注意的是，在许多情况下，可以避免使用秘密和密码。大多数在线服务（GitHub、PyPI 等）都具有权限系统，开发人员可以通过该系统获得所需的访问权限。可以通过 SSH 密钥授予服务器访问权限，每个开发人员都必须保护好自己的密钥。本文档处理无法做到这一点的情况，以及必须共享秘密的情况。

原则#

1. 必须记录受限的项目资源。

   例如，托管服务或网页的服务器，以及在 GitHub、聊天、邮件列表等上添加/删除项目成员的过程。

2. 为开发人员分配完成其工作所需的最低权限。

   定期（例如每年）审查权限以维持最低权限。

   令牌是应进行范围限定（最低必要权限）并设置在合理时间段（通常为一年）后过期存储的典型秘密示例。必须记录轮换和撤销此类令牌的说明。

3. 项目资产应尽可能由至少两名维护人员访问。这确保了即使关键团队成员离开项目或无法工作时也能访问资产。

4. 用于分发项目秘密的系统必须具有以下属性

   • 秘密以加密形式存储在中央（远程）位置。
   • 必须能够向选定的团队成员授予对秘密的访问权限。
   • 必须能够撤销将来对秘密的访问权限。¹
   • 系统不得依赖于封闭源代码或商业加密工具，这些工具以后可能会消失或无法使用，尽管如果此类解决方案允许导出所有数据，则可以考虑使用它。

   无论选择哪种系统，其用户界面都应与预期用户的功能相匹配。这降低了密码被复制到安全性较低的机制（如便签或文本文件）的风险。例如，如果目标受众不习惯使用 GPG 或命令提示符，则以下pass实现可能不起作用，应考虑使用 1password 或 bitwarden 等替代方案。

核心项目认可#

生态系统采用#

徽章#

项目可以通过包含 SPEC 徽章来突出显示其对本 SPEC 的采用。

要使用一个徽章指示采用多个 SPEC，请参见此处。

实现#

密码存储：托管#

以下托管解决方案符合上述 (2) 中的原则。

自托管解决方案

• vaultwarden；开源

付费解决方案

• bitwarden 提供 25% 的非营利折扣；托管开源

赞助解决方案

• 1password；闭源

密码存储：离线#

Pass 是标准的 Unix 密码管理器，它将密码存储为磁盘上的加密文件。密码保管库 是一个满足上述原则的示例实现。秘密以加密形式存储在公共 Git 存储库中。保管库使用gopass（pass 的更用户友好的实现）通过 GPG 密钥管理访问。每个秘密都使用应具有访问权限的所有开发人员的公钥进行加密。如果删除开发人员的访问权限，则会重新加密保管库，以便该开发人员无法读取存储库的未来副本（但秘密被视为已泄露，因此必须轮换）。

其他常见场景#

• 发布包：PyPi 提供了一种可信发布者机制来避免密码

其他安全建议#

• 2FA：开发人员必须对服务登录使用双因素身份验证。这降低了帐户被接管以及随后发布欺诈性软件的风险。
• 密码必须由密码管理器生成。这确保了密码具有足够的长度和复杂度。
• SSH 密钥必须有密码。Ed25519 是当前推荐的密钥类型，可以使用ssh-keygen -t ed25519生成。

注释#

请参阅gopass 的安全目标。