API密钥与证书管理等密钥的安全管理指南

许多网络安全攻击看起来并不像精心策划的银行抢劫，而更像是用别人留在锁孔里的钥匙打开一扇门。以优步为例。2014 年，该公司遭到入侵，原因是一名工程师意外地将一个 AWS 访问密钥提交到了公共 GitHub 仓库。威胁行为者利用该密钥访问了超过 10 万名司机的个人数据。

如果像这样简单的入侵都能发生在优步身上，那么它可能发生在任何地方：像 丰田 和 梅赛德斯-奔驰 这样的传统品牌、像 美国网络安全和基础设施安全局 这样的政府机构，以及现代科技公司，都曾在 GitHub 上泄露过敏感的凭据。

这些看似是鲁莽的错误（确实如此），但它们是看似无害的捷径积累成灾难性漏洞的后果：

• 为了测试而提交一个 API 密钥
• 为了加快新同事的上手速度，通过私信发送一个认证Token
• 将你的工程师使用的同一个 .env 文件发送给负责网站改版的承包商

培训无法解决这个问题。人类会犯错，有时会把便利性置于安全性之上。这是一个被称为 秘密扩散 的系统性问题。

当密钥、Token、证书和其他敏感数据在环境和服务中扩散的速度超过任何团队能够追踪的速度时，就会出现秘密扩散。没有人知道存在的秘密的全部范围、谁能访问它们，或者它们带来了什么风险。用纯文本文件和 Slack 消息来存储和共享秘密，对于少量秘密来说可行（尽管不安全），但在规模上无法手动管理。

限制性的、手动执行的策略（即使可行）也会拖慢工程师的速度。“为什么这个不工作了？” 这样的日子可能会过去好几天，直到新的 API 密钥被手动分享给所有需要它的人。同样的道理也适用于非人类身份：过期的数据库凭据导致不明原因的宕机会产生操作摩擦。处理秘密的快速、便捷方式并不安全，但极度限制性的姿态会使运营陷入停滞。

这就是核心矛盾：工程师和服务需要数百到数千个秘密才能运行，这些秘密必须能够随时可用，同时绝不能冒被暴露的风险。

这就是现代秘密管理的挑战：这是一场军备竞赛，旨在先发制人地对抗威胁行为者，这些行为者配备了能够嗅探广泛使用的基础设施中尖端漏洞和十年旧漏洞的人工智能。

中心化秘密管理对于避免安全事件至关重要，如果事件确实发生，也能够在继续快速交付的同时限制其爆炸半径。

什么是秘密管理？

秘密管理是存储和共享秘密的实践。

每一位使用秘密的开发者、团队和公司，都以某种方式管理着秘密，即使他们从未定义过实践。

糟糕的秘密管理，在网络安全领域相当于把密码写在信用卡上。在纯文本文件中存储和共享未加密的秘密是秘密管理的一种形式，但肯定不安全。

良好的秘密管理实践包括访问控制、审计日志、加密存储和其他最佳实践。

良好秘密管理的目标是避免安全漏洞（如果确实发生，则迅速响应并限制其影响），以及避免因应用程序缺少所需内容而导致的停机。

什么算是秘密？

秘密是一种敏感信息，它授予对某物的访问权限，如果泄露可能造成危害。一些常见秘密的例子：

• API 密钥：用于 Stripe、OpenAI、Twilio 等服务的Token。
• 数据库凭据和连接字符串：postgres://user:password@host:5432/db。
• SSH 密钥：用于向服务器和 Git 提供商进行身份验证的私钥。大型组织管理着数百万个这样的密钥。
• TLS/SSL 证书 私钥：用于对服务器进行身份验证和加密流量的密钥对。
• OAuth 和服务账户Token：通常具有广泛作用域（如 repo:admin）的Token。
• 加密密钥（DEK 和 KEK）：用于加密静态数据的对称密钥。
• 云访问密钥：AWS 的 AKIA… 密钥、GCP 服务账号 JSON 文件、Azure 客户端密钥。
• 其他：Webhook 密钥、JWT 签名密钥、代码签名证书、容器注册表凭据、Helm 和 Artifactory Token。

在云开发时代，秘密的数量呈爆炸式增长，产生了一种称为 秘密扩散 的现象，在这种情况下，没有人能全面了解存在哪些秘密、它们在哪里以及谁有权访问它们。

这是一个关键问题，因为潜在的攻击面巨大（数百万个可能被暴露的秘密），而且秘密被泄露的后果严重（数据泄露、勒索软件攻击）。这一切使得秘密管理成为任何软件开发团队的必要任务。

为什么秘密管理很重要

因凭据泄露而导致的持续入侵，本身就有足够理由认真对待秘密管理。但法规和合规标准（包括 HIPAA、GDPR 和 SOC 2）也要求严格管理网络安全。

秘密管理的错误会导致真实的漏洞

凭据滥用是现代入侵中最常见的初始访问向量。根据 Verizon 的 2025 年数据泄露调查报告，被盗凭据涉及了 88% 的基本 Web 应用攻击。它们出现在大约三分之一的确认泄露中。

随着像 Claude Code 这样的人工智能代理比以前编写更多的代码，代码审查资源变得紧张。这使得情况更加恶化：GitGuardian 的 2025 年秘密扩散状况 报告发现，仅在 GitHub 上硬编码的秘密数量在 2025 年大约翻了一番，而且超过 90% 的这些秘密在泄露后五天内仍然有效且可被利用。

这可能导致严重的入侵：

• 思科（2026 年 3 月）：从 Trivy 供应链攻击中窃取的凭据使攻击者获得了 AWS 密钥和对 300 多个 GitHub 仓库的访问权限。
• Vercel（2026 年 4 月）：一名员工向第三方 AI 工具（Context.ai）授予 OAuth 权限，导致 Lumma Stealer 感染，并在未被发现的情况下潜伏了两个月。
• 三星德国（2025 年）：Raccoon 信息窃取程序在 2021 年窃取了一名承包商的凭据。此后四年无人轮换这些凭据，然后在 2025 年它们被用于一次涉及 27 万条记录的数据泄露。
• PowerSchool（2025 年 1 月）：被盗的承包商凭据（没有使用多因素认证）导致一个密码暴露了 6000 万条学生记录。

这些只是几个例子，但我们还能举出数百个。

关键信息是：秘密正在大规模泄露，在泄露后往往长期有效，并且不断被攻击者利用。

运营风险：秘密不仅会导致泄露，还会导致宕机

秘密既需要保护，又是每位工程师工作所需的工具。除了安全性之外，不佳的秘密管理实践还会在工程团队中造成运营问题并拖慢工作进度。

例如，一次预定的 秘密轮换 会中断所有部署，直到所有工程师手动替换了他们 .env 文件中的凭据。

对于拥有数千名工程师的组织来说，这可能对生产力和协作产生严重后果。

它还可能导致面向客户的宕机。当新凭据尚未传播而旧凭据已失效时，服务之间可能停止通信，从而导致应用（部分）对用户不可用。

爆炸半径

一个被泄露的秘密也会危及该秘密有权访问的所有内容。安全团队将此称为爆炸半径：通过这一个凭据可以访问的系统、数据和操作集合。

一个 AWS IAM Token可能允许威胁行为者访问该 AWS 账户上的 EC2 实例、S3 存储桶等等。

当一个被泄露的凭据使攻击者能够访问其他凭据时，这被称为横向移动。一个被泄露的 Slack 会话Token仅授予对 Slack 的访问权限。但在私信中发现的 .env 文件可以解锁整个基础设施。

中心化秘密管理可以限制爆炸半径。动态秘密限制了泄露秘密的可用时间。最小权限访问意味着只提供必要的权限，从而阻止黑客因承包商的缺陷安全实践而获得对基础设施的管理员访问权限。

合规要求

对于受监管的组织来说，秘密管理不再是可选项，这些组织涵盖的行业、公司规模和地理范围不断扩大。SOC 2、PCI DSS 4.0、GDPR、HIPAA 以及各种其他法规和合规标准，对如何授予、管理和记录对敏感系统的访问提出了各种要求。

带有审计日志的中心化保管库是满足合规要求、加强安全态势而不减慢工程团队速度的标准基础设施。

什么是秘密保管库

从架构上看，秘密保管库是一个带有 API 的加密数据库：你向它进行身份验证，请求你需要的特定秘密，接收返回的秘密，并且你的访问会被记录。

在底层，生产级保管库处理加密存储（使用保存在 HSM 或云 KMS 中的根密钥进行信封加密）、在颁发任何秘密之前验证工作负载身份的身份验证后端、细粒度的访问策略、用于不同凭据类型的秘密引擎、仅追加的审计日志，以及自动跟踪和撤销未结凭据的租约管理。

在实践中，这是平台、安全或 DevOps 团队进行与秘密管理相关工作的场所。在这里，他们添加和撤销秘密、定义策略、与第三方工具集成以及审计秘密使用情况。

开发者自身只访问保管库来查看他们有权访问的秘密。在实践中，开发者很少从保管库复制粘贴（在许多情况下，他们不应该能看到纯文本的秘密），而是选择通过 CLI 在运行时注入秘密。

秘密管理如何工作

秘密生命周期

秘密有一个可预测的生命周期。大多数安全失败发生的原因是组织管理了早期阶段（生成和存储）而忽略了后期阶段。

1. 生成：生成秘密。有时是通过在服务的 UI 中点击一个按钮，然后复制粘贴到保管库中，但理想情况下，保管库会自动生成它。
2. 存储：一个集中的、加密的保管库应该是唯一真实来源。
3. 分发：工作负载根据策略进行授权，通过 TLS 返回秘密，并记录访问。秘密绝不应该出现在聊天消息、设备存储或日志中。
4. 访问控制：最小权限策略决定了每个身份可以读取或写入什么。
5. 轮换：每个秘密的值按定义的节奏变化，或者在手动触发的轮换（通常针对事件响应）中立即变化。
   • 轮换应该是“双阶段的”：在撤销旧凭据之前暂存新凭据，以避免任何停机。
6. 撤销：使秘密失效，以移除身份（人类或非人类）或响应入侵。
7. 销毁：在满足保留要求后，从保管库中硬删除秘密。

静态秘密与动态秘密：为什么短期有效更好

静态秘密在轮换之前保持不变。大多数 API 密钥、数据库密码和证书都是静态的。它们可以管理得很好，但如果被泄露，需要主动进行轮换。

动态秘密 是为特定访问请求生成的临时秘密，生命周期很短（通常只有几分钟）。

以下是数据库凭据的示例：

1. 应用程序向保管库进行身份验证，并请求一个 Postgres 凭据。
2. 保管库使用管理角色创建一个临时数据库用户：CREATE ROLE app_abc123 LOGIN PASSWORD 'xK9…' VALID UNTIL '+15 minutes'.
3. 保管库将凭据返回给应用程序并记录租约。
4. 15 分钟后，保管库运行 DROP ROLE app_abc123。

应用程序为一个真实的数据库使用了真实的凭据，但该凭据在请求之前并不存在，并且在 15 分钟后不再有效。除非它在那 15 分钟的特定窗口内泄露，否则对攻击者来说毫无用处。

选择轮换静态秘密还是使用动态秘密

大多数组织同时使用这两种方法，以保持与遗留基础设施的兼容性，并覆盖动态秘密不实用的用例（例如，气隙环境、速率限制低的 API 等）。以下是如何决定哪种方法适用于哪种情况：

与动态秘密一样，自动轮换静态秘密也是一项复杂的技术操作。这可能需要高级的自定义逻辑或一个秘密管理工具。

在这两种情况下，共同的目标是一致的：任何人类都不应该知道生产凭据的当前值，并且任何凭据都不应超过其即时需要。

秘密管理最佳实践

OWASP Secrets Management Cheat Sheet 是这里的权威参考。以下是其中最重要的部分，以及秘密管理工具如何使它们成为可能或更容易实现。

1. 永远不要硬编码秘密

一个提交到源代码的秘密，对于对该仓库具有读取访问权限的每个人都是可访问的：包括当前和未来的员工以及承包商。在公共仓库中，是任何曾经克隆、分叉或读取过该仓库的人（包括自动凭据扫描器和 LLM 背后的训练管道）。

有各种解决方案可以在代码提交之前发现其中的秘密。你可以通过预提交Hook、CI/CD 管道扫描、IDE 插件以及针对具有已知模式的秘密的 GitHub 推送保护来强制执行这一点。

秘密扫描很重要，但正确的秘密管理策略更健壮，因为它意味着个别开发者从未知道他们正在处理的秘密，因此他们无法将其提交到 Git。

2. 集中到保管库中

秘密应该放在一个地方，进行版本控制、审计，并通过一致的 API 访问。团队知道去哪里查找，可以在一次操作中撤销访问权限，并且没有秘密会因为开发者笔记本上的 .env 文件而“继续存活”。

3. 强制执行最小权限

每个工作负载只能获取它需要的秘密，而不是为了方便而捆绑的秘密。一个前端服务不应该拥有与数据迁移作业相同的数据库凭据。一个只读的分析工作负载不需要写权限。

一个合适的秘密管理平台通过简化工作流程的每个部分并使寻找最便捷解决方案的诱惑消失，使这变得更容易。

4. 自动化轮换

静态凭据应该自动轮换。这会使得任何可能无意中泄露的秘密失效，并且如果威胁行为者获得了它，它也会变得无用。

一些团队因为担心宕机而犹豫是否要自动化轮换。现代秘密管理工具通过重叠的有效期窗口来缓解这一问题：当秘密轮换时，保管库维护两个有效的秘密版本。服务继续使用当前秘密，直到它们在下次重启或凭据刷新时获取新秘密。一旦确认新凭据已传播，旧凭据才会失效。这确保了零停机。

5. 使用动态秘密和短期凭据

凭据的生命周期越短，威胁行为者能用它造成的损害就越小。使用短 TTL 的数据库凭据、云 IAM 角色和内部服务认证。当动态秘密不可用时，具有自动轮换的短期Token是次优选择。

6. 审计所有内容

每次秘密读取、写入、轮换和撤销都必须产生一个审计事件。这应该尽可能详细，包括：

• 谁或什么访问了它（工作负载身份 + 如果适用的话，当时的值班人员）
• 从哪里访问的（源 IP、集群、区域）
• 哪个秘密（完整路径）
• 什么操作（读取/写入/轮换/撤销）
• 何时（时间戳）

这些日志对于合规性、入侵后的重建以及异常检测是必要的。

7. 分离环境

开发、预发布和生产应该使用不同的保管库命名空间或租户，并具有不同的身份。开发者的本地秘密绝不应包含生产值。

DevOps 和 CI/CD 中的秘密管理

现代软件交付链充满凭据，这在构建管道的各个系统之间的每次交接中都创造了潜在的风险面。秘密管理在这里尤其重要。

为什么 CI/CD 原生的秘密存储不够用

CI/CD 平台通常有一个原生的秘密功能：GitHub Actions Secrets、GitLab CI Variables、CircleCI Contexts 等。这些很方便，但却是孤立的。它们不能跨系统保护秘密，并且需要维护多个秘密存储，这与最佳实践相冲突。

现代模式是使用 CI/CD 平台的身份服务向你的保管库进行身份验证，并按需获取秘密：

• GitHub Actions 作业从 GitHub 的身份提供者那里获得一个短期 OIDC Token
• 该Token被交换为一个限定作用域的 AWS STS 会话、AWS GCP Workload Identity 凭据等。

CI/CD 平台中永远不存在长期有效的凭据。

Kubernetes：Base64 不是加密

Kubernetes 内置的 Secret 对象是 base64 编码的，而非加密的。任何对对象具有读取访问权限的人都可以解码 base64 字符串。默认情况下，这包括同一命名空间中的任何 Pod。在默认的集群配置中，kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d 会向任何具有适当 RBAC 权限的人返回纯文本值。

最基本的缓解措施是使用 KMS 提供商启用 etcd 静态加密。对于生产工作负载，已确立的模式有：

• External Secrets Operator（ESO）：一个 CNCF 项目，通过 CRD 将秘密从外部保管库（AWS Secrets Manager、GCP Secret Manager、Azure Key Vault、Infisical 等）同步到 Kubernetes Secret 对象中。唯一真实来源存在于你的保管库中；K8s 秘密是一个同步的副本。ESO 的上游开发目前已暂停，因此采用这种模式的团队通常会评估供应商维护的替代方案，例如 Infisical Kubernetes Operator，它提供相同的同步模型，但仍在积极开发中。
• Secrets Store CSI Driver：直接从外部存储将秘密挂载为 Pod 文件系统中的文件；支持的提供商包括 AWS、GCP、Azure、Vault 和 Infisical。
• IRSA / GKE Workload Identity / Azure AD Workload Identity：完全从集群中移除云提供商的访问密钥；Pod 通过投射的服务账户Token承担 IAM 角色。对于任何运行在托管云 Kubernetes 服务上的工作负载，这是正确的答案。
• Sealed Secrets：使用集群持有的公钥加密一个 Secret，以便加密的 YAML 可以提交到 Git；集群控制器在 apply 时解密。适合 GitOps；在轮换和动态秘密方面较弱。

Terraform 和状态文件问题

Terraform 存储资源状态，包括提供商返回的任何敏感值，存储在 terraform.tfstate 中。该文件是纯文本，这使得它成为一个潜在的攻击面。任何对你的状态后端具有读取访问权限的人都可以读取 Terraform 曾经接触过的每个数据库密码、生成的密钥和敏感输出。

有一些方法可以通过使用 KMS 提供商加密静态状态来缓解这个问题。你可以像锁定生产数据库一样严格地锁定状态后端的 IAM 访问权限。

但更干净的架构模式是使用 Terraform 来预配身份（一个 IAM 角色、一个服务账户、一个 Kubernetes 服务账户），并让运行时工作负载在启动时动态获取自己的凭据。这使敏感值完全脱离状态文件。

GitOps：秘密属于保管库，而不是 Git

GitOps 工作流（Argo CD、Flux）将 Git 视为基础设施状态的唯一真实来源。秘密不能成为 Git 中的唯一真实来源，因为它们永远不能以纯文本形式存在于那里。

正确的模式是在 Git 中存储对秘密的引用（一个指向你保管库的 ExternalSecret CRD）而将 值 存储在保管库中。Git 提交只包含地址，不包含内容，这使实际秘密脱离了 GitOps。

云秘密管理

三大主要云提供商都提供原生的秘密管理服务（AWS Secrets Manager、GCP Secret Manager 和 Azure Key Vault）。每个都有各自的复杂性，但共享相同的优点和缺点：

它们很方便，因为有很多第一方集成，并且是现有供应商的一部分，这意味着它们不需要通过额外的安全审查。

但是，特定于提供商的秘密管理器在扩展时会变得次优：第三方集成很困难，因为每个云都希望将客户留在自己的生态系统中。这使得多云秘密管理变得困难。使用多个提供商原生的秘密管理器会创建并行化的基础设施，这给安全团队带来了额外的工作，并且意味着没有统一的保管库。

此外，这些秘密管理器通常也按使用量定价，这激励了最小化秘密数量，从而抑制了动态秘密或频繁轮换等最佳实践。

每一个都有一些独特的特性：

• AWS Secrets Manager：一个简单、有弹性的 AWS 栈解决方案，提供凭据的轮换、管理和检索，具有 KMS 加密、版本控制以及与 RDS 和 Lambda 等服务原生集成等功能。
• GCP Secret Manager：可用于 Google Cloud Platform 用户，提供具有访问控制、审计日志、版本控制和轮换功能的秘密存储，可通过 API 和客户端库访问。
• Azure Key Vault：一个为 Azure 用户提供的托管服务，用于集中管理密钥、证书、连接字符串和密码，包括自动化 SSL/TLS 证书续订的能力。

何时使用第三方秘密管理工具

一旦你遇到了提供商原生秘密管理器的限制，使用专门的秘密管理工具就有意义了。这通常发生在团队希望避免未来的供应商锁定和依赖，或者一旦你从单一云栈扩展出去。

秘密管理器通常实现以下两个功能之一：

• 取代 AWS、GCP 或 Azure 的原生解决方案，并直接在那里管理秘密。
• 与提供商原生解决方案集成，在一个保管库中操作秘密管理，但不跳过你的云栈的安全基础设施。

使用像 Infisical 这样的秘密管理器可以避免因集成覆盖不均而产生的不良变通方案和自定义集成，并将所有环境的秘密管理集中到一个工具中。

选择秘密管理工具

秘密管理工具包括云原生服务、开源平台/SaaS 工具和闭源 SaaS 产品。选择正确的工具需要明确几个比任何功能清单都更重要的维度。

秘密管理工具的四个类别

在评估具体产品之前，了解你正在查看的工具类型会有所帮助：

秘密管理也被认为是特权访问管理（PAM）的四大核心能力之一，PAM 将类似的控制和日志记录扩展到人类特权用户和紧急访问场景。对于大多数以开发者为中心的团队来说，PAM 和秘密管理是不同的问题，但工具有重叠。

选择秘密管理工具时最重要的问题

1. 它是否支持你实际使用的系统的动态秘密？
2. 策略有多精细？只有 RBAC，还是也有 ABAC 或策略即代码？能否按环境、路径或工作负载属性进行限定？
3. 审计日志捕获了什么？
4. 针对你使用的每个平台、系统和服务的集成情况如何？
5. 开发者体验如何？开发者能否在不提交工单的情况下管理秘密？是否有清晰的 UI、CLI、环境分离和本地开发工作流？
6. 它是否处理除了秘密管理之外的其他事情（例如 PAM、PKI 等）？理想情况下，你希望避免为你的安全栈购买多个平台。
7. 你可以自托管吗？对于有数据驻留要求的受监管行业，这通常很重要。
8. 总拥有成本是多少？任何给工程团队带来额外压力（或需要额外招聘）的事情都会增加成本，即使它不在供应商发票的明细项目上。

主要选项

HashiCorp Vault 是最早的秘密管理解决方案之一，其提供商 HashiCorp（HCP）于 2025 年被 IBM 收购。它是一个用于安全存储和访问秘密及其他敏感数据（例如访问Token、API 密钥、加密密钥、密码、证书）的全面工具。

Vault 的局限性在运营它的团队中已有充分记录：

• 它是一组构建块，而不是一个成品。
• 大多数组织需要专门的平台工程师来部署、配置、升级和操作它。
• 它的用户体验是为操作员设计的，而不是为开发者。
• 其 SaaS 产品 HCP Vault Secrets 在 2025 年中期停止服务，这降低了它对希望获得托管路径的团队的吸引力。

云原生工具（AWS Secrets Manager、GCP Secret Manager、Azure Key Vault）是需求简单的单一云团队的正确起点。它们的核心优势是与该云生态系统的深度原生集成，核心缺点则是局限于同一生态系统。

Doppler 是一个完全闭源的秘密管理解决方案。Doppler 面向开发者，提供一个 UI 仪表板，开发者可以在其中修改静态和动态秘密值、设置权限、监控访问日志等。额外的秘密共享功能使得内部共享更容易。

但 Doppler 也有明显的缺点：

• 它仅作为托管云服务存在，因为它是闭源的。Doppler 不能自托管。
• 复杂的设置（如多租户或多云设置）很困难，因为它只提供一个组织层。
• 该平台仅涵盖秘密管理，这意味着特权访问管理或证书管理需要单独的供应商。

Infisical 是一个开源的数字身份安全平台，专注于开发者和工程团队。大多数团队采用 Infisical 是为了获得一流的秘密管理，包括 针对 AI 代理的专用保管库，但它也具有 证书管理 (PKI)、特权访问管理 (PAM)、秘密扫描 等功能。

这使其成为中小型市场团队的一体化解决方案，以及支持大型企业复杂性和合规性要求的理想选择。

Infisical 提供了一套端到端的工具，涵盖秘密管理的各个方面：从安全的版本控制秘密存储，到秘密轮换，到跨基础设施的集成，再到秘密扫描和泄漏预防。

Infisical 最重要的功能包括：

• 一个统一的仪表板，供开发者根据其权限访问和修改秘密，具有细粒度的角色和审计日志。
• 跨基础设施（Docker、Kubernetes、Terraform）和第三方服务（GitHub Actions、Vercel、CircleCI）的自动集成。
• 用于开发者入职和离职的秘密工作流、审批流以及跨环境的合规变更。
• 在发生入侵或潜在漏洞时自动进行秘密轮换。
• 一个用于将秘密注入为环境变量的 Infisical CLI，以及用于其他访问模式的 SDK 和 API。
• 持续的秘密扫描、监控和泄漏预防，并集成到 Git。

自托管与云托管 SaaS

SaaS 提供最小的运营负担、更快的上手速度，以及供应商管理的可用性和补丁。它会在你的安全模型中引入一个第三方数据托管方，这对某些组织来说是可以接受的，但对某些组织来说是一个硬约束。它还限制了你对底层基础设施的定制程度。

自托管 给你完全的数据主权，适合气隙和受监管的工作负载，并且没有按席位计费的云依赖。你需要自己运营它：高可用性配置、备份、升级、监控，以及伴随 Tier-0 基础设施而来的值班轮换。

对于数据驻留是硬性要求的组织（例如医疗保健、金融服务、国防），可自托管的平台是唯一可行的道路。

何时从当前设置迁移

表明是时候投资专用秘密管理的信号：

• 每周花费超过十分钟手动管理秘密
• 在过去十二个月内，一次秘密泄露导致了一次持续数天的轮换事件
• 你正在使用 .env 文件来管理你的秘密
• 你无法在一分钟内回答“谁或什么在过去 90 天内获取了这个秘密”
• SOC 2、ISO 27001 或 PCI DSS 审计中关于轮换或访问日志的问题正在用电子表格来回答
• 超过 10% 的微服务拥有没有轮换计划的静态长期凭据
• 你正在转向多云，而你的秘密被孤立在一个提供商的本地工具中

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