OWASP 密钥管理备忘单：你需要知道什么

大多数平台工程师都会认出这一幕。

现在是凌晨 2 点。PagerDuty 报警。某个生产服务返回 500。值班工程师一路追查，发现故障源头是内部 service mesh 端点上的 TLS 证书过期了。这个证书是在 14 个月前签发的。没有人记得是谁签发的、由哪个 CA 签名，或者续期流程是什么。工程师找到了一页 Confluence 文档，里面只有不完整的说明，还引用了一个已经不存在的 Vault 路径。

备用方案是 SSH 登录到该服务，生成一个自签名证书，然后重启。故障持续了 47 分钟。事后分析显示，同一集群中的另外三个证书也将在接下来的两周内过期。

或者这个场景：对生产环境执行 Terraform apply 失败了，因为 AWS Secrets Manager 中的数据库凭据已经轮换，但 Terraform state file 仍然引用着旧凭据。轮换是由一位安全工程师手动完成的，他遵循了一份 runbook，但其中并没有把“更新 Terraform state”作为一个步骤。生产部署被阻塞了两个小时，直到三个团队协作才修复了问题。

这些并不是假设性的边缘案例。它们正是当 secrets management 被当作一组孤立的工具选择，而不是一种系统级纪律来对待时，常见的那类运维故障。

OWASP Secrets Management Cheat Sheet 是建立这种纪律的最佳公开起点。它属于 OWASP Cheat Sheet Series，这是一个由社区维护的简明安全参考集合，涵盖了完整的 secrets 生命周期：secrets 应该如何创建、存储、访问、轮换、撤销、审计，以及如何在 CI/CD pipelines、云提供商、容器和 multi-cloud 环境中进行管理。

下面的各节将拆解 OWASP 指南最强的地方、最薄弱的地方，以及每一项建议如何映射到大规模运行基础设施时的运维现实。

OWASP Secrets Management Cheat Sheet 覆盖了什么

这份 cheat sheet 涵盖 11 个部分：通用 secrets management 原则、CI/CD pipelines、云提供商、容器和 orchestrators、实现指导、加密、检测、事件响应，以及 multi-cloud 环境。

涵盖的 secrets 类型：

• API keys
• 数据库凭据
• SSH keys
• TLS 证书
• 加密 keys
• Service account tokens
• IAM 权限
• OAuth client secrets
• 签名 keys

这些内容对那些负责 secrets 在基础设施中如何流转的人最有用：平台工程师、DevOps 团队、SRE、安全工程师，以及基础设施架构师。

蔓延问题：为什么中心化是首先要做对的事

OWASP cheat sheet 以中心化和标准化开篇，这是正确的。在大多数组织里，secrets 问题并不是某个单独的 secret 管理得不好，而是 secrets 无处不在，在每个地方都以不同方式管理，而且没有统一视图来查看到底有哪些 secrets、由谁负责，或者上一次轮换是在什么时候。

一家拥有几十名工程师的典型企业，可能会把 secrets 分散在：

• AWS Secrets Manager，用于 AWS 上的生产工作负载
• Azure Key Vault，用于 Azure 环境
• GitHub Actions secrets，用于 CI pipelines
• GitLab CI/CD variables，用于使用 GitLab 的团队
• 三个不同集群中的 Kubernetes Secrets
• Docker Compose 文件中的环境变量，用于本地开发
• 一个 HashiCorp Vault 实例，只有两个团队在用，其他人都不信任
• SharePoint 上的一张电子表格，由 SRE 团队维护，用于 on-prem 基础设施
• 提交到私有仓库的 .env 文件（是的，至今仍然如此）

OWASP 承认了这一现实。中心化可以意味着使用多个 secrets management solutions，只要交互模式和生命周期管理是标准化的即可。cheat sheet 还指出了一个容易被忽略的重点：secrets management system 本身的 root credentials 需要存放在别处。你最终总会有至少两个系统。

OWASP 的强项

强调标准化而不是简单合并，是正确的框架。告诉一个大型组织“把所有东西都放进一个工具里”并不现实。不同团队有不同的约束。云原生团队可能因为延迟或集成原因，需要使用云提供商原生的 secrets management。on-prem 工作负载则需要一个能在本地运行的解决方案。

重点在于，无论使用哪种工具，每个团队都应遵循相同的生命周期实践（创建、轮换、撤销、审计和访问控制）。

OWASP 的薄弱之处

cheat sheet 对于蔓延在事件响应期间带来的运维成本着墨不多。当一个凭据被泄露时，第一个问题是“这个 secret 在哪里被使用？”如果答案需要检查六个不同的系统，而每个系统又都有不同的访问控制模型和不同的审计日志格式，你的平均遏制时间就会增加三倍。

访问控制：策略与现实之间的差距

OWASP cheat sheet 建议对单个 secret 进行细粒度访问控制，并将 Least Privilege principle 应用于每个接触 secrets management system 的用户和服务。

这是正确的，也是实践中最常被忽视的建议。

为什么会被忽视

实施细粒度访问控制是一项繁琐的工作，而且需要持续维护。给 DevOps 团队一个共享 admin role，要比为 40 个服务分别定义每个 secret 或每个项目的 policy 容易得多。结果是，大多数组织的访问策略在创建时只是“够用”，之后便逐渐漂移。

更常见的失败模式不是有人故意授予过宽权限，而是权限会随着时间不断累积。一个工程师被加入某个项目，获得其 secrets 的访问权限，后来转到了另一个团队，而原有访问权限从未被撤销。两年后，组织中 30% 的工程师拥有他们不再需要、而且大概也不知道自己拥有的 secrets 访问权限。

OWASP 说对的地方

强调细粒度控制是正确的。secret-level 权限比 vault-level 或 project-level 权限更好。cheat sheet 指出，在 Azure Key Vault 的 legacy access policy model 下，Azure 历史上是按 vault 级别而不是按 secret 级别授予访问权限，这意味着需要单独的 key vault 来隔离访问。

Azure RBAC 现在支持 secret-level role assignments，但许多组织仍在运行 legacy model，而 OWASP 的指导反映了那个旧默认值。无论如何，这都是一个团队容易忽视的真实架构考量。

OWASP 指南中缺失的内容

自动化访问生命周期管理。 在拥有数十或数百名工程师的组织中，人们会频繁更换角色、离职，以及在团队之间流动。访问审查应该自动化并绑定到你的 identity provider。当某人在你的 IdP 中被 offboard 时，他们对 secrets management 的访问应该在几分钟内被撤销，而不是被加入一份“等有人有空再处理”的手工清单。

审批工作流。 在受监管环境中，访问某些 secrets 需要有文档化的审批。这不仅仅是访问控制问题，也是工作流问题。如果审批流程需要 Jira ticket、Slack 消息和一次手动 policy 更新，工程师就会寻找变通办法。secrets management 平台中的内置审批工作流，才是填补这一差距的方式。

轮换和动态 secrets：自动化决定成败

OWASP 关于轮换和动态 secrets 的建议是合理的：定期轮换 secrets，自动化流程，并在可能的情况下使用 dynamic（短生命周期）secrets。

cheat sheet 没有完全传达的是，手动轮换在规模化环境中会失控到什么程度。

手动轮换的失败模式

这个模式是可预测的：

1. 安全团队制定了一项 policy：所有数据库凭据每 90 天轮换一次。
2. 他们创建了一份包含 12 个步骤的 runbook。
3. 前两个轮换周期一切正常。
4. 到第三个周期时，执行轮换的工程师发现现在已经有第四个服务依赖这个凭据，但 runbook 里没有写到。
5. 轮换破坏了生产环境。
6. 事后，轮换周期悄悄从 90 天变成了“等我们有空再说”。

这几乎出现在所有依赖手动轮换的组织中。这不是人的问题，而是系统设计问题。

动态 secrets 才是正确答案（如果它们能用）

OWASP 建议在可能的情况下使用 dynamic secrets：为特定 session 即时生成凭据，并附带定义好的 TTL。当应用启动时，它请求数据库凭据；当它停止时，凭据就会过期。

这是正确的架构。它消除了凭据复用，限制了影响范围，并使被盗凭据在 TTL 过后失去价值。

限制在于，并非所有系统都支持动态凭据创建。遗留数据库、第三方 API、SaaS 平台以及许多内部服务仍然需要静态凭据。对于这些场景，自动化轮换（而不是手动轮换）就是备选方案。

按自动化潜力对每个 secret 分类

按两个维度审计你的 secrets：

• 这个 secret 能否动态生成？ 如果可以，就使用带有短 TTL 的 dynamic secrets。
• 它的轮换能否完全自动化？ 如果可以，就按计划使用自动化轮换。
• 两者都不行？ 那就是你风险最高的库存，你应该积极减少这部分。

支持数据库 dynamic secrets、自动化轮换策略，以及与消费这些 secrets 的系统集成的现代 secrets management platform，正是让这一切在规模化环境下可行的关键。没有平台支持，你就只能为每次轮换维护自定义脚本，而这些脚本本身又会成为维护负担。

CI/CD 中的 Secrets：你的 Pipeline 就是一个生产系统

OWASP cheat sheet 对 CI/CD 的一个判断完全正确：把你的 CI/CD 工具当作生产环境。

大多数组织并没有这样做。CI/CD pipeline 往往是整个基础设施中权限最高的系统。它拥有部署到生产环境的凭据、访问 secrets management systems 的权限，以及修改正在运行服务的能力。然而，它经常比它所部署的生产系统拥有更弱的访问控制、更少的监控和更差的加固。

CI/CD secret 可以存在的三个地方

OWASP 列出了三种选项：

1. 存在于 CI/CD 工具本身中（GitHub Actions secrets、GitLab CI/CD variables、Jenkins credentials）。这是最常见的方法，也是大规模环境中最危险的方法。拥有仓库 maintainer 级访问权限的任何人都能看到这些 secrets。是否会在 fork 仓库时复制 secrets，取决于平台配置。pipeline 输出也经常会通过调试日志或错误消息泄露 secrets。

2. 存在于专用 secrets management system 中，pipeline 在运行时对其进行认证。这更好。pipeline 获取短生命周期 credentials 来访问所需的 secrets，并且作用域限定到特定 job。归因仍然可以保留。但 pipeline 仍然会接触这些 secrets，这意味着一旦 pipeline 被攻破，仍可能将其外泄。

3. 完全不在 pipeline 中。 pipeline 部署服务，并告诉 orchestrator（Kubernetes、ECS 等）使用哪个 service account。服务本身在启动时检索自己的 secrets。pipeline 从不看到生产 secrets。这是在架构上可行时的最佳选项。

OWASP 低估的方面

外泄风险。 一个攻击者（或一个粗心的开发者）如果能修改 pipeline 定义，就可以添加一步，把 secrets 回显到远程 endpoint、用 base64 编码，或者写入一个会作为 build artifact 上传的文件。检测需要：

• 监控 pipeline 定义的变更
• 审查 pipeline 输出中的编码内容
• 对 CI/CD runner 异常的网络外连进行告警

GitHub Actions 上的供应链攻击。 被攻破的第三方 action 可以访问 workflow 可用的所有 secrets。将 actions 固定到特定 commit SHAs（而不是 tags），并在使用前审计第三方 actions，是超出 OWASP 当前范围的关键实践。GitHub 的 security hardening guide for Actions 对此有更详细的说明。

尽量让 secrets 完全不进入 pipeline

在可行的情况下，优先选择第三种方式（服务自己检索 secrets）。对于 GitHub Actions，使用 OIDC federation 在运行时对你的 secrets management platform 进行认证，而不是将长期 credentials 存储为 GitHub secrets。

要求对任何 pipeline 定义变更进行 merge request 审批。监控 pipeline 输出中的 secret 泄露。以同样的补丁、加固和监控纪律对待你的 CI/CD 基础设施，就像你对待生产环境一样。

Kubernetes Secrets：默认配置远远不够

OWASP 关于容器和 orchestrators 的指导，在运行 Kubernetes 的团队那里最具运维相关性。

默认的 Kubernetes Secrets 问题

Kubernetes Secrets 只是 base64 编码，而不是加密。默认情况下，任何拥有正确 RBAC 权限的人都可以读取某个 namespace 中的每个 secret。通过 Kubernetes 暴露的环境变量可以通过 kubectl describe pod 看到，并且会被大多数 logging agents 捕获。存放 secrets 的 etcd 数据存储是否启用了静态加密，则取决于集群配置。

OWASP cheat sheet 建议：

• 通过挂载 volume 或 sidecar containers 注入 secrets，而不是通过环境变量
• 永远不要把 secrets 烘焙进容器镜像
• 确保 etcd backend 启用了静态加密
• 将访问限制在 pod 内部，而不是在多个 deployments 之间共享

这些都没错。但它们都不是原生 Kubernetes 集群的默认行为。OWASP Kubernetes Security Cheat Sheet 提供了更多背景。

sidecar 模式

OWASP 推荐用于 secret 注入的 sidecar 模式：一个 sidecar container 对 secrets management system 进行认证，检索所需的 secrets，并将它们写入一个共享的内存 volume（medium: Memory 的 emptyDir）。应用程序从该 volume 读取。sidecar 还可以定期刷新 secrets，从而在无需重新部署的情况下支持轮换。

这个模式效果很好，但它增加了运维复杂性。每个 pod 现在都有一个额外的 container，需要配置、监控和更新。对于管理数百个服务的团队来说，一个在集群级别处理 secret 同步的 Kubernetes operator（而不是每个 pod 一个 sidecar）通常更合适。

Infisical Kubernetes Operator 采用了这种方式，将 Infisical 中的 secrets 同步到 Kubernetes 集群，并在上游 secrets 轮换时自动刷新。这消除了每个 pod 单独配置 sidecar 的需要，同时仍然避免将 secrets 放入环境变量和容器镜像中。

OWASP 忽略的 GitOps 张力

cheat sheet 没有讨论 GitOps 与 secrets management 之间的张力。使用 ArgoCD 或 Flux 管理集群状态的团队面临一个真实问题：desired state（包括 secret references）存放在 Git 中，但实际的 secret values 不应存放在 Git 中。

像 Sealed Secrets 或 External Secrets Operator 这样的解决方案存在，就是为了弥合这一差距，但它们也增加了另一层工具链。具备原生 Kubernetes operator 的 secrets management platform 可以通过处理 external secrets store 与集群之间的同步，而无需让 secret values 经过 Git，从而降低这种复杂性。

Multi-Cloud：让一切都更难的现实

OWASP 的 multi-cloud 指南涵盖了预期中的挑战（不同的 API、不一致的 policy、碎片化的审计），并建议采用一个中心化、云无关的解决方案。

OWASP 指南中实用的部分

建议使用一个能够与多个云提供商集成的中心化解决方案是正确的。对于在 AWS、GCP、Azure 和 on-prem 之间运行工作负载的组织来说，这也是唯一可行的方法。

将每个云提供商原生的 secrets management 分开使用，会产生三个（或更多）不同的系统，它们有不同的访问控制模型、不同的轮换机制和不同的审计日志格式。

OWASP 没有涵盖的内容

非人类身份蔓延。 machine identities（service accounts、workload identities、API tokens、证书）现在在大多数大型组织中的数量比 human identities 多 10 倍甚至更多。每个云提供商都有自己的 machine identity 模型（IAM roles、service accounts、managed identities），而这些模型在不同提供商之间并不通用。一个同时处理 certificate lifecycle management 和跨云边界 privileged access 的 secrets management platform，正好填补了这一空白。

缩短的 TLS 证书生命周期。 当证书生命周期下降到 47 天（到 2029 年公共 TLS 证书的当前趋势）时，对于任何拥有不止少量证书的组织来说，手动 certificate management 在运维上都会变得不可能。自动化的证书签发、续期和撤销，需要成为 secrets management strategy 的一部分，而不是由另一个团队使用另一套工具单独管理的独立领域。

OWASP Secrets Management 清单

用这个清单来评估你当前的状况。如果你无法勾选某一项，那就是你的优先处理列表。

中心化和标准

☐ 所有 secrets 都存储在指定的 secrets management system 中，而不是代码、配置文件或电子表格中

☐ 每个 secret 都有文档化的 owner、用途和 consumers 列表

☐ 与 secrets management system 的交互模式在各团队之间保持一致

☐ secrets management system 的 root/admin credentials 存储在一个单独且安全的位置

访问控制

☐ 权限配置在 secret 或 project 级别，而不是系统级

☐ 对每个用户和服务都强制执行 Least Privilege

☐ 访问审查已自动化，并与 identity provider 绑定

☐ offboarding 会在几分钟内撤销 secrets management 访问权限

轮换和生命周期

☐ machine secrets 按定义好的自动化计划轮换

☐ database credentials 和其他受支持的 backend 使用 dynamic secrets

☐ rotation procedures 会在 staging 中定期测试

☐ 对已过期和已撤销的 secrets 进行监控，查看是否存在尝试复用

☐ 每个 secret 都有定义好的过期时间或轮换周期

CI/CD Pipeline 安全

☐ CI/CD 基础设施经过加固，并被当作生产系统对待

☐ pipeline secrets 的作用域按 job 限定，而不是按 repository 或组织限定

☐ pipeline 输出会被监控是否存在 secret 泄露

☐ fork/copy 操作不会传播 secrets

☐ 在可能的情况下，已部署的服务在运行时自行检索自己的 secrets

☐ 第三方 actions/plugins 固定到特定 commit SHAs

Kubernetes 和容器安全

☐ etcd 已启用静态加密

☐ secrets 通过 mounted volumes 或 operators 注入，而不是通过环境变量

☐ 没有 secrets 被烘焙进容器镜像或 Docker ENV/ARG 指令

☐ RBAC 将 secret 访问限制到特定的 service accounts 和 namespaces

☐ 外部 secrets management platform 是事实来源，而不是原生 Kubernetes Secrets

加密

☐ 所有 secrets 都在静态时加密（AES-256 GCM 或等效方案）

☐ 所有 secrets 都通过 TLS 传输

☐ 加密 keys 与其保护的 secrets 分开存储

☐ 备份使用单独管理的 keys 加密

☐ Terraform state backends 使用加密

检测与监控

☐ 在代码推送之前，pre-commit hooks 会扫描 secrets

☐ CI/CD pipelines 包含 secrets scanning 作为阻断门禁

☐ repository 扫描覆盖完整 Git 历史，而不只是 HEAD

☐ audit logs 捕获所有 secret access、creation、rotation 和 deletion 事件

☐ 已针对异常的 secret access 模式配置告警

☐ audit logs 至少保留 90 天且可查询，冷存储保留更久

事件响应

☐ 存在 break-glass credentials，单独存放，并按季度测试

☐ 针对 secret exposure 有文档化的 incident response 程序

☐ 撤销可以在几分钟内完成

☐ 在过去 12 个月内，至少对一次 secret exposure 事件进行了桌面演练

Multi-Cloud 和 Hybrid

☐ 统一的 secrets management 方法覆盖所有云提供商和 on-prem

☐ 各环境之间的 access controls、轮换周期和 policies 保持一致

☐ 审计轨迹将所有环境中的事件聚合到单一可查询系统中

☐ machine identity（证书、service account tokens）与 secrets 一起管理

开始弥补这些差距

文章开头那个凌晨 2 点的证书故障，以及被阻塞的 Terraform deploy，有着相同的根本原因：secrets 被当成分散工具中的单独决策来管理，而没有统一的生命周期。OWASP cheat sheet 定义了什么是好的做法。

Infisical 是一个开源平台，通过开箱即用的 Kubernetes、Terraform、GitHub Actions 以及 60 多种其他工具集成，将 secrets、证书和 privileged access management 集中管理。它处理了 OWASP cheat sheet 所描述的运维要素：中心化存储、自动化轮换、细粒度访问控制，以及跨云、on-prem 和 hybrid 环境的审计日志。

如果你当前的设置依赖手动 runbooks、散落的环境变量，或者某人在三年前做的一张电子表格，你可以免费试用 Infisical。或者如果你想讨论你的具体设置，可以预约演示。

Ashwin Punj

Solutions Engineer，Infisical

• 原文链接： infisical.com/blog/owasp...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～