Secrets 管理基础概念：什么是 Secrets？生命周期

好，咱们直接切入正题。Secrets 这个词，翻译过来就是“秘密”。但在咱们 API 和系统架构里，它可不是什么神秘的东西。说白了，Secrets 就是那些你不能让别人知道的数据。比如数据库密码、、TLS 私钥、OAuth 令牌……只要泄漏了会让系统出事的，都算。

我记得刚入行那会儿，把数据库密码硬编码在代码里是常态。后来有一次，项目代码不小心被上传到了公开仓库……嗯，那天晚上我们全组都在改密码。从那以后，我对 Secrets 的定义就特别在意了。

Secrets 的种类

实际工作里，你遇到的 Secrets 远不止密码这么简单。来，我列个清单。你看过一遍就明白了。

类型	常见例子	泄漏风险
静态凭证	数据库密码、SSH 密钥、API 令牌	长期有效，一旦泄漏，攻击者可持久访问
动态令牌	OAuth 2.0 access_、JWT	有时效，但短窗口内可被滥用
加密密钥	AES 密钥、RSA 私钥、TLS certificate	可解密所有历史通信数据
配置敏感项	连接字符串、服务账号凭据、第三方 secret	可能被用于横向移动

Secrets 的生命周期

聊完“是什么”，咱们看看“怎么管”。任何一个 Secrets，都有完整的生命周期。你想想看，就算你把密码存在安全的地方，如果从来不换，那跟没存有什么区别？

我把它分成 六个阶段。下面这张图，你看完就能记住。

各阶段的关键动作

光有图还不够，得把每个阶段该干什么说清楚。我结合自己踩过的坑，给你拆开讲。

① 生成

Secrets 必须用专业的随机数生成器造出来。别自己手动敲密码，也别用弱随机函数。我在项目里见过用 new Random().Next() 生成 的……结果是可预测的，攻击者一猜就中。

• 使用密码学安全随机数（如 /dev/urandom、secrets._hex）
• 设置足够的熵值（推荐 128 位以上）
• 避免使用可预测的种子（如时间戳、PID）

② 存储

存储是 Secrets 管理最核心的环节。别指望代码仓库能把秘密藏住。Git 历史里删掉密码？不，它永远留在历史里了。

正确的做法：

• 使用专用的 Secrets 存储服务（Vault、AWS Secrets Manager、Azure Key Vault）
• 存储时必须加密，并且使用强加密算法（AES-256-GCM）
• 严格控制访问权限：最小权限原则 + 审计日志
• 支持版本管理和不可变记录

③ 分发

Secrets 需要被合法消费者获取。但分发过程很容易出问题。我建议不要把 Secrets 作为环境变量明文传递，因为环境变量在进程内存中很容易被 dump。

• 使用 TLS 传输加密
• 尽量使用临时令牌（如 Vault 的动态 Secret）代替静态分发
• 分发时带上使用期限和范围约束

④ 使用

应用程序使用 Secrets 时，要确保只在运行时内存中停留，不要写日志，不要打印到控制台。我在一个金融项目中遇到过：开发人员为了方便调试，把数据库密码直接打在了日志里，结果生产日志被导出后，密码就泄漏了。教训深刻。

• 使用 after-bind 或 sidecar 模式注入
• 对 Secrets 做内存保护（如 mlock 防止换出到磁盘）
• 用完及时清理内存引用

⑤ 轮换

轮换就是定期更换 Secrets。为什么要换？因为即使你没泄漏，攻击者可能通过其他方式获得了它。你想想看，一个密码用了三年没换过，风险有多大？

轮换策略	适用场景	轮换频率
定时轮换	静态密码、数据库凭据	30–90 天一次
使用后轮换	一次性令牌、短时效	每次使用后自动轮换
事件驱动轮换	检测到泄漏或可疑行为	立即轮换

⑥ 撤销

Secrets 被废弃或泄露后，必须立即撤销。撤销不是简单地删除，而是要让它们失效。比如吊销证书、销毁密钥材料、更新访问控制列表。

• 撤销后要验证所有依赖方是否已经移除该 Secret
• 保留撤销记录以用于审计
• 某些场景下需要保留撤销前的 Secret 的哈希，以便后续对比排查

生命周期管理的核心原则

说了这么多，其实核心就四条。你记下来，做设计时时常提醒自己。

• 不可逆性：Secrets 一旦写入，不应被明文读出（除了授权的应用运行时）
• 时效性：每个 Secrets 必须有生命周期，不能永久有效
• 可审计性：每次生成、使用、轮换、撤销都要有日志
• 自动化：尽可能用工具自动化管理，减少人工干预