机密信息扩散问题

机密蔓延是敏感凭据在组织内不受控制地扩散。机密是任何能够授予访问权限的信息：应用程序编程接口密钥、数据库密码、开放授权令牌、TLS 私钥、SSH 密钥和加密密钥。

当这些机密散落到本不应存放它们的位置时，就会发生蔓延：

• 源代码和配置文件
• 持续集成/持续交付流水线和环境变量
• 容器镜像和基础设施即代码
• 聊天消息、维基和工单系统

一旦机密存在于多个位置，您就无法可靠地跟踪、轮换或撤销它。

最常见的根本原因是硬编码的 secret，也就是直接写入源代码的凭据。开发期间这样做很方便，但最终会变成永久性的安全隐患。

下面是应用程序代码中硬编码的数据库密码：

现在，任何拥有此文件读取权限的人都能获得生产环境密码。这包括每位开发人员、每个持续集成运行器，以及之后克隆该代码库的任何人。

硬编码密钥的一个严重风险是版本控制历史。即使您在后续提交中删除了一个 secret，它仍会永久存在于每个代码库副本的版本控制历史中。

您可以随时从历史记录中恢复泄露的 secret：

因此，从最新提交中删除 secret 并不能消除泄露影响。必须将该 secret 视为已泄露，并立即进行轮换。

当包含硬编码密钥的代码库被推送到 GitHub 等公开托管平台后，自动化机器人会在几秒到几分钟内抓取它。

现实中的后果包括：

• 云账单爆炸：泄露的 AWS 密钥被用于启动加密货币挖矿集群，一夜之间产生数万美元的费用。
• 数据泄露：暴露的数据库凭据导致全部数据被窃取。
• 横向移动：攻击者利用一个泄露的令牌进一步渗透基础设施。

云服务商和 GitHub 现在都运行secret 扫描，能够自动检测有时还会自动撤销泄露的密钥，但您不能把它当作安全保障。

容器引入了一种隐蔽的扩散途径。构建期间烘焙进镜像的密钥会存储在镜像层中，并被发送到拉取该镜像的每个镜像仓库和主机。

一种常见错误是先复制一个 secret 文件，再在后续镜像层中删除它；该 secret 仍存在于之前的镜像层中：

任何拉取该镜像的人都可以提取该镜像层并读取密钥。请改用构建 secret 或运行时注入。

将密钥从代码中移出并放入环境变量是有所改进，但并不是完整的解决方案。环境变量解决了硬编码问题，却引入了新的暴露途径：

• 泄露在崩溃转储和错误堆栈跟踪中
• 在 Linux 上，其他进程可以通过 /proc/<pid>/environ 查看
• 调试工具打印完整环境时被记录
• 以明文存储在会被意外提交的 .env 文件中

环境变量可用于低敏感度配置，但高价值密钥应存放在具有访问控制和审计功能的专用密钥管理器中。

密钥扩散会使事件响应几乎无法进行。当一个 secret 无处不在时，以下两个问题将无法回答：

• 它在哪里？ 找不到的密钥就无法轮换。
• 谁使用过它？ 没有集中的访问日志，就无法界定泄露范围。

单个泄露凭据的影响范围会随着密钥扩散而扩大。在十个服务之间重复使用同一个共享密码，意味着一次泄露就会危及全部十个服务。集中管理以及唯一、短期有效的密钥可以显著缩小这一范围。

阻止泄露最省成本的时机是在它进入版本控制之前。提交前密钥扫描器会检查暂存的更改，并阻止包含凭据模式的提交。

常用的开源工具包括 gitleaks、trufflehog 和 detect-secrets。典型的提交前钩子会在本地运行：

请将其与持续集成中的服务器端扫描结合使用，这样即使开发人员绕过本地钩子，也仍会被检测出来。

如果一个 secret 出现在不该出现的地方，请按以下顺序处理。应先轮换，清理历史记录是次要步骤，因为副本可能已经存在。

• 1. 轮换：立即撤销泄露的 secret 并签发一个新的。
• 2. 审计：检查暴露期间的访问日志，确认是否有任何未经授权的使用。
• 3. 清除：从历史记录中删除 secret（例如使用 git filter-repo），然后强制推送。
• 4. 预防：添加扫描功能，并将 secret 移入管理器，防止问题再次发生。

绝不要跳过第 1 步。只要 secret 接触过公开暴露面，就已经泄露，仅此而已。

当密钥权限过大且共享过度时，扩散会更加严重。应用最小权限原则，可以在发生泄露时限制损害：

• 为每个服务提供自己的凭据，绝不共享。
• 将每个密钥的权限限制在所需的最低范围内（只读而非管理员权限）。
• 优先使用会自动过期的短期有效凭据。
• 按环境隔离密钥：开发密钥绝不能授予生产环境访问权限。

这些做法可以将灾难性泄露转变为可控且可恢复的事件。

工具本身无法解决扩散问题，文化才可以。成熟的组织会把密钥管理视为一项持续的规范：

• 默认立场：源代码中绝不存放 secret。
• 将密钥集中存储在具有访问控制和审计日志的托管保险库中。
• 在每个阶段自动扫描：提交前、持续集成和镜像仓库。
• 让轮换成为日常操作，而不是只在紧急情况下进行。
• 培训每位工程师识别并报告暴露问题，不追究责任。

目标是建立这样一个系统：secret 难以泄露，发生泄露后也容易恢复。

您已经了解，分散且硬编码的密钥为何是最常见、危害最大的安全弱点之一。

• 密钥扩散是凭据在代码、流水线、镜像和聊天工具之间不受控制地传播。
• 硬编码密钥会永久存在于版本控制历史中；删除它们并不能消除泄露影响。
• 公开代码库会在几分钟内被抓取，导致云账单爆炸和数据泄露。
• 环境变量和镜像层都是容易泄露的载体，并非安全的存储方式。
• 密钥扩散会扩大影响范围，使轮换和事件响应无法进行。
• 解决办法：提交前进行扫描；发生泄露时先轮换；集中存储在保险库中，并应用最小权限原则。

接下来，我们将使用保险库和 secret 存储库正确地集中管理密钥。