机密自动化：轮换密钥与动态密钥
- infisical
- 发布于 2025-07-05 20:55
- 阅读 81
文章围绕机密管理中的两种自动化方案展开：自动轮换密钥与动态密钥。前者适合长期运行服务，通过新旧凭证并存的轮换窗口避免停机，降低人工操作风险；后者按需生成、带 TTL，更接近零常驻权限，安全性、可审计性和扩展性更强。文中还比较了两者在安全性、性能、兼容性、实现成本等方面的差异，并给出适用场景：短生命周期任务更适合动态密钥，长连接和性能敏感系统更适合自动轮换。
Secrets 自动化：轮换式 Secrets 与动态 Secrets
发表于 2025 年 7 月 3 日，星期四
当私钥被提交到代码仓库后，往往会引发一种特有的恐慌。随着开发者承担的职责比以往任何时候都更多，人为失误导致漏洞出现也变得再自然不过。解决方案是：设计一个从一开始就防止这种情况发生的系统。
随着云计算的普及，Secrets——例如私钥、API Token 和证书——变得越来越常见。每当 EC2 与 Stripe 或数据库通信时，Secrets 都用于授权访问。然而，由于 Secrets 默认是长期有效的，它们也为黑客提供了极具吸引力的攻击面。
尽管存在风险，许多公司仍然对 Secrets 采用手动轮换。如果它们被悄无声息地窃取，这尤其危险：被泄露的凭证在被发现之前可能会持续有效数月之久，从而为黑客留下可乘之机。
解决这一问题的两种常见方法包括自动化 Secret 轮换和动态 Secrets。
自动化 Secret 轮换
获取 Secrets 的访问权限是黑客最理想的情形之一。一旦遭到泄露，这些凭证就可能允许对敏感计算资源进行无限制的授权访问。
缓解这一问题的一种方法，是在预定的时间间隔后手动轮换 Secrets。从理论上讲，这会限制每个凭证的有效生命周期，但在实践中，这种方式既繁琐又容易留下人为失误的空间。手动轮换给开发者带来了不必要的时间负担，并且在现代技术栈中数百个微服务之间的执行一致性较差，最终导致 Secrets 的有效时间远远长于预期。
相反，我们可以自动化Secret 轮换。通过自动化 Secret 轮换，开发者能够节省时间、消除人为失误，并使更短的 Secret 生命周期成为可能。
轮换式 Secrets 非常适合那些与资源保持持久连接的长期运行服务，例如数据库或外部 API。这些用例受益于稳定的凭证：它们可以按可预测的计划进行轮换，以简单的方式维持持久身份，并避免中断正在进行的操作。
自动化 Secret 轮换是如何工作的？
请求受保护资源的服务会被更新为调用一个 Secrets 提供方，该提供方会提供有效的 Secret。当到了轮换 Secrets 的时间时，Secrets 提供方会自动生成并存储新的 Secret，然后在稍后撤销旧的 Secret。
这种方法通过始终为给定服务维护两个有效 Secret 来防止停机。当一个 Secret 被轮换时，当前 Secret（Secret 1）仍然有效，但会被标记为“inactive”，而新配置的 Secret（Secret 2）会被标记为“active”。两者都有效，但只有一个会被标记为“active”。
当 Secrets 再次轮换时，Secret 2 会被标记为“inactive”但仍然有效，而 Secret 1 最终会被撤销。此时会配置一个新的 Secret（Secret 3）并将其标记为“active”。
自动化 Secret 轮换可以节省开发者时间，也能提升组织的安全性；因为自动化 Secret 轮换是以编程方式完成的，所以在零停机风险的前提下，实现更短的凭证生命周期是可行的。
然而，自动化 Secret 轮换只是自动化 Secrets 生命周期的一种策略。一个更稳健且适用于更多场景的解决方案是动态 Secrets。
动态 Secrets
动态 Secrets 是为特定数据访问即时生成的凭证。
这是一种在身份管理上截然不同的方法。与依赖长期有效的凭证不同，这种方法会为对特定资源的每次请求按需生成新的 Secret，并附带定义好的 TTL。这种严格的作用域限制使其能够实现比传统 Secrets 更细粒度的访问控制，同时达成零常驻权限原则——确保没有任何实体持续保有持久权限。
这种方法有一些实质性的好处。首先，它通过最小化影响范围并为攻击者创造一个不断变化的目标来提升安全性：被泄露的 Secret 在攻击者使用它时很可能已经失效，而且通常它所授予的访问权限也会少于传统 Secret。其次，动态 Secrets 提升了可审计性——使得监控任意特定 Token 所执行的操作成为可能。最后，动态 Secrets 也更具可扩展性，因为不需要在轮换窗口之间进行协调。
动态 Secrets 非常适合短生命周期的临时工作负载，例如 CI/CD 流水线和无服务器函数。这些工作负载天然契合动态 Secrets 模型，因为它们执行时间短且会终止，因此按需生成凭证比管理那些在工作负载生命周期结束后仍然存在的长期 Secrets 更高效。
实现动态 Secrets 的要求
有一些考量因素可以帮助判断动态 Secrets 是否理想：
- **基础设施能力：**受保护资源是否支持自动配置用户和权限？如果不支持，就无法生成动态 Secrets。像 Stripe 这样的外部 API 不支持动态 Secrets，而包括 AWS、Oracle 或 Kubernetes 在内的内部基础设施则允许相对直接的实现。
- **计费：**你的受保护资源是否按创建的每个用户收费？这会使动态 Secrets 变得极其昂贵，并且很可能不可行。
- **性能：**你的受保护资源是否对延迟敏感？如果是，那么配置动态 Secrets 所带来的额外延迟（10-100ms）可能会使这种方法不可行。
动态 Secrets 是如何工作的？
首先，受保护资源必须支持会过期的 Secrets。
对于发往该受保护资源的每一个请求，调用服务都会使用一个 Secrets 管理提供方来生成动态 Secret。然后，Secrets 管理提供方会配置该 Secret 并将其发送回调用服务，此时该服务就可以访问受保护资源，直到 TTL 到期。
总之，动态 Secrets 是按需生成的，并且只在短时间内有效。虽然这需要更多前期设置，而且并不适用于所有用例，但动态 Secrets 提供了更高的安全性和可扩展性。
自动化 Secrets 轮换与动态 Secrets 的对比
让我们比较一下提升 Secrets 安全性的不同方法：
| 标准 | 自动化 Secrets 轮换 | 动态 Secrets |
|---|---|---|
| 安全性 | 风险更高。凭证在更长时间内保持有效。 | 风险更低。凭证在更短时间内保持有效。 |
| 生命周期 | 更长。凭证在轮换周期结束前一直有效。 | 更短。凭证在其 TTL 到期前一直有效。 |
| 实现工作量 | 低。可轻松适配现有使用 Secrets 的系统。 | 中等。需要自定义设置，不过可以通过模板/预构建工作流来缓解。另一方面，自助式数据库访问等用例也可以轻松启用。 |
| 可扩展性 | 可扩展性较差。需要存储 Secrets 并跟踪计划。 | 可扩展性更强。Secrets 可以动态生成。 |
| 可审计性 | 视情况而定。身份是持久的，因此可以随时间监控。 | 视情况而定。每次访问对应的身份意味着可以轻松追踪授予了哪些权限以及授予时间。 |
| 性能影响 | 影响极小，仅在轮换期间 | 中等，每次访问增加 10-100ms |
| 兼容性 | 高。大多数系统都支持 Secrets 以及 Secrets 的自动轮换。 | 较低。服务必须支持自动配置用户和权限。Infisical 提供了针对 Kubernetes 等系统的集成等。 |
| 合规性 | 视情况而定。对要求持久身份的框架更友好。 | 视情况而定（见另一列） |
以下情况请选择动态 Secrets：
- 短生命周期、临时性工作负载，例如 CI/CD 或无服务器函数
- 高安全环境，能够从较短的凭证生命周期中受益
- 兼容的基础设施，支持自动配置用户和权限
以下情况请选择自动化 Secrets 轮换：
- 运行时间更长的工作负载，例如需要持续访问数据库的应用程序
- 性能关键型应用程序，因为动态 Secret 生成比轮换式 Secrets 引入更多延迟（通常每次凭证生成需要 200-800ms，而缓存静态凭证约为 ~1ms）
最后的想法
自动化 Secrets 轮换和动态 Secrets 都能降低安全风险、消除开发者负担并提升可扩展性。
它们也都需要一定的实现工作量。Infisical 通过预构建模板使两者的设置都变得简单。你可以在这里尝试我们面向 AWS 的自动化 Secrets 轮换模板，或者在这里尝试我们面向 GCP 的动态 Secrets 模板。
Mathew Pregasen
技术作者，Infisical
- 原文链接： infisical.com/blog/secre...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
