本文结构In This Post
一、长期密钥的根本问题I. Core Problem of Long-Lived Keys
长期密钥通常散落在配置文件、CI 日志和脚本仓库中。只要一个环节泄露，攻击者就可能长期潜伏并横向移动。Long-lived keys often leak through configs, CI logs, and script repositories. A single exposure enables persistent compromise and lateral movement.
更严重的是，很多团队不知道哪些服务还在使用旧密钥，导致轮换困难、回收失败。Worse, teams often cannot tell which services still depend on old keys, making rotation and revocation unreliable.
二、短时凭证模式II. Short-Lived Credential Pattern
推荐模式是：工作负载先通过可信身份（如服务账户或工作负载身份）获得短时 Token，再用 Token 调用目标 API。Token 过期后自动失效，减少暴露窗口。Recommended pattern: workloads authenticate using trusted workload identity, obtain short-lived tokens, then call APIs. Token expiry naturally limits blast radius.
对高敏接口再叠加策略限制，例如调用频率、来源网络、上下文风险评分。For high-risk APIs, add policy constraints such as rate limits, source network checks, and contextual risk scoring.
三、运行与审计要点III. Operations and Audit Essentials
机器身份治理不能只看签发成功率，还要监控异常请求、失败重试模式和跨租户访问。每次凭证签发都应带有可追溯的工作负载标识。Machine identity governance must track anomaly patterns, retry storms, and cross-tenant access attempts, not just issuance success. Every credential issuance needs traceable workload identity.
四、迁移路径IV. Migration Path
建议按优先级分批替换：先覆盖生产写权限接口，再覆盖读权限接口，最后清理历史长期密钥。每一批都应附带回滚与应急策略。Migrate in waves: production write APIs first, read APIs next, legacy keys last. Each wave must include rollback and incident response runbooks.