密钥蔓延：我们如何修复 412 个泄露的 Token
3 月 3 日凌晨 2:13，一个 CI 流水线运行失败。我们在 37 个仓库中发现了 412 个泄露的 API Token。这次错误让高达 120 万美元的潜在违规成本面临风险。
大多数团队认为使用 Vault 就能解决一切问题。但实际上，Vault 可能会成为延迟方面的单点故障。当 Token 存在于 Vault 之外时，通常会使用硬编码值或环境变量。这些回退方案不会出现在审计日志中。
我们的指标显示了这种蔓延带来的代价：
- 正常的密钥检索：每次请求 48 ms。
- 泄露期间：每次请求 187 ms。
构建代理（Build agents）从一个遥远的 Vault 集群中为每个作业拉取 12 个 Token。这导致了超时，并迫使开发人员手动回滚更改。延迟不仅仅是流程变慢的问题，它还是一个会推高云账单并拖慢开发人员进度的成本中心。
如果攻击者利用了 staging 仓库中泄露的一个 AWS 密钥，每小时可能造成 120 美元的损失。仅仅一小时的滥用成本就超过了一次季度安全审计。
静态扫描器让我们失望了。它们漏掉了我们 78% 的 Token。为什么？因为这些 Token 是即时生成的，存在于构建产物（build artifacts）中，而不是源代码中。GitHub Actions 的一个步骤将 Token 写入了 Docker 层。扫描器什么也没看到，但该 Token 在我们的注册表中存放了数周之久。
你需要的是运行时可见性（runtime visibility），而不仅仅是静态检查。
我们构建了一个 Lambda 引擎来解决这个问题。它通过 CloudTrail 监控新密钥，并将其与我们的 Vault 进行比对。以下是新的工作流：
- 通过 Webhook 检测密钥。
- 查询 Vault 获取元数据。
- 通过提供商 API 使 Token 失效。
- 提交一个 PR 以从文件中移除该密钥。
- 如果通过 CI，则自动合并该 PR。
该引擎在 27 分钟内轮换了 412 个 Token，成功率高达 99.97%。
我们现在会追踪密钥时长（secret age）。如果 Token 超过 30 天，构建就会失败。这一简单的规则在一个季度内使新泄露量减少了 62%。我们还使用孤立森林（isolation-forest）模型来标记异常的使用模式。如果 Token 出现在新的 IP 地址上，系统会立即对其进行轮换。
不要再把 Token 当作文件来对待。要将密钥时长和检索延迟视为关键指标。如果你这样做，蔓延现象将会减少。
Optional learning community: https://t.me/GyaanSetuAi