「零长期密钥」在2026年成为现实目标
- 年，在云原生环境中持有永久 API Key 已被视为「遗留运营」。永久密钥长期存储于文件或环境变量中，泄露途径多样——代码误提交、CI 日志暴露、离职员工的私人备份残留等。GitGuardian 与 Truffle Security 于2025年末联合发布的调查报告显示，GitHub 公开仓库中存在的有效 API Key 数量每年超过1,300万个，仅 AWS Access Key 一项就检测到210万个。
从结构层面改善这一状况，需要将密钥管理平台与 Workload Identity 相结合。密钥管理实现「在需要时动态颁发短期令牌，使用后自动失效」的运营模式；Workload Identity 则实现「无需持有永久密钥即可调用云 API」的设计。两者整合后，「任何地方均不存在长寿命密钥」的目标，已可在全组织范围内实现。
密钥管理平台对比
HashiCorp Vault 持续保持企业级事实标准地位。其优势在于动态密钥功能——针对数据库、云 API、SSH、PKI，原生提供「在请求时生成新凭证，TTL 到期后自动失效」的机制。以 PostgreSQL 为例，「每次应用登录时创建短期用户，5分钟后删除」可通过寥寥数行策略配置实现。弱点在于运营成本——高可用配置、审计日志、Auto-unseal 的维护需要专职平台团队。HCP Vault 的采用数量在2026年呈增长趋势。
AWS Secrets Manager 是 AWS 原生环境的首选。可通过 IAM 角色实现细粒度读取权限控制，与 RDS、DocumentDB、Redshift 的轮换整合为标准功能。弱点在于多云场景——集中管理 GCP、Azure 的凭证需要自行构建接入流水线。
Doppler 是以开发者体验为重心的 SaaS，在初创企业与中型企业中迅速扩大市场份额。通过 CLI 一条命令即可同步本地、CI、生产环境的密钥，与 GitHub Actions、Vercel、Heroku 的集成配置极为简便。缺点是动态密钥功能较弱，作为真正的短期令牌颁发基础设施不及 Vault。2026年「开发环境用 Doppler、生产环境用 Vault」的并用构成也不在少数。Infisical、1Password Secrets Automation、Bitwarden Secrets Manager 也成为不可忽视的存在。
SPIFFE/SPIRE：Workload Identity 的标准
在 Workload Identity 领域，SPIFFE 与 SPIRE 已分别作为标准规范与参考实现确立地位。SPIFFE 的核心理念是「为所有工作负载分配以 SVID（SPIFFE Verifiable Identity Document）——即基于 X.509 证书的唯一 ID，通过该 ID 进行双向认证与短期密钥颁发」。
SPIRE 是 Kubernetes 原生实现，采用 Server（证书颁发机构）与 Agent（各节点常驻）的构成。Agent 检查 Pod 的运行时属性（Service Account、Namespace、Image Hash），若存在匹配的 Registration Entry，则向 Pod 颁发附带 SPIFFE ID 的 SVID。应用通过 Workload API 获取 SVID，用于与其他服务的 mTLS 通信或 JWT-SVID。SPIFFE 的价值在于能够构建「跨越云环境、本地数据中心、混合环境的统一身份层」，在多云与边缘混合环境中的采用正在扩大。日本方面，NTT Communications、LINE Yahoo、Mercari 已公开宣布采用。
Workload Identity Federation
GCP 的 WIF（Workload Identity Federation）接收 OIDC / SAML Assertion 并进行向对应 Service Account 的令牌交换。过去从 GitHub Actions 操作 GCP 时，需将 Service Account Key JSON 存放于 GitHub Secrets，使用 WIF 后，可由 GCP 侧直接验证 OIDC 令牌并获取临时访问令牌。永久密钥从仓库运营中消除——这是零信任的典型应用案例。Azure Workload Identity 向 AKS 工作负载颁发来自 Entra ID 的联合凭证，AWS 则通过 IAM Roles Anywhere 与 IAM OIDC Provider 实现与 WIF 等效的功能。
WIF 设计的关键在于「信任边界的描述」。若允许类似 `repo:my-org/*:ref:refs/heads/*` 这样宽泛的匹配，将形成来自 Fork 仓库的滥用或拥有 branch 创建权限的攻击者的提权路径。推荐将组织名 + 仓库名 + 环境名 + 分支名全部纳入匹配条件。
Secretless Broker：从应用完全隐藏密钥
CyberArk 的 Conjur Secretless Broker 提供从应用进程「完全隐藏密钥的存在」的设计。传统方式下，应用通过 Vault 客户端获取密钥并在内存中持有后再连接数据库，此期间密钥可能因 core dump 而暴露。Secretless Broker 作为应用与数据库/API 之间的本地代理运行，应用以明文方式连接 `localhost:5432`，代理则使用 SPIFFE ID 自我认证，从 Vault 获取密钥并代理完成下游连接与认证。与 Kubernetes Sidecar 模式契合度高，与 Istio、Linkerd 联动的实现在2026年日益增多。
AI Agent 时代的 NHI
- 年，AI Agent 作为密钥管理与 Workload Identity 的新兴主要客体急剧浮现。通过 LangChain、AutoGen、CrewAI、Anthropic MCP 服务器，跨 Slack、Jira、GitHub、内部 API 进行横向操作。在朴素实现下，往往会将开发者个人的 PAT 写入环境变量，从 NHI（Non-Human Identity）原则来看已属失控，同时满足「无法审计、权限过度、离职时权限剥夺遗漏」三大隐患。
标准架构如下：Agent 实体（Pod / Serverless）获取 SPIFFE ID 并向 Vault 证明自身身份；Vault 通过动态密钥引擎颁发联动 SaaS 的短期令牌，任务完成时失效；审计日志记录「哪个 SPIFFE ID 通过哪个密钥对哪个资源进行了操作」。
关键在于「OAuth for Agents」规范的动向。2026年在 IETF 讨论中的草案，正试图标准化 Agent 以用户代理（on-behalf-of）方式运作时的授权流程、权限范围表达与审计字段。Okta、Auth0、Cloudflare 已提供先行实现，支持颁发包含 `actor` claim 与 `on_behalf_of` claim 的令牌。在组织内部运营 MCP 服务器时，建议为每台 MCP 服务器颁发 NHI 并以 SPIFFE ID 进行识别。
实施优先级与迁移步骤
优先级以「泄露时的影响范围 × 暴露机会的频率」为标准确定。第1阶段：将 CI/CD 的永久密钥替换为 WIF——仅将 GitHub Actions 至 AWS / GCP / Azure 切换为基于 OIDC，即可消除大部分 CI Secrets。第2阶段：将应用数据库连接迁移至动态密钥。第3阶段：引入 SPIFFE/SPIRE，将微服务间通信迁移至基于 SVID 的 mTLS。第4阶段：设计 AI Agent NHI，将 Agent 运营基础设施整合为受益于上述所有机制的形态。
Vault 故障的影响尤为严重，高可用配置为必须，同时还需文档化「Vault 完全停机时的紧急通道」。零信任不应意味着「零可用性」，故障时不停业务的例外路径设计，恰恰是成熟度的体现。「零长期密钥」在技术上已进入可实现的时代。阻碍实现的，不是技术的缺失，而是运营组织的设计、与开发流程的融合，以及与经营层的共识建立这三个方面。