03 静态凭据 vs 动态凭据：优缺点对比与场景选择

凭据怎么管，说到底就两条路：一种写死不动，一种随时换。我刚开始做后端时，觉得这有什么好纠结的，能连上数据库不就行了吗？后来出过几次事故，才明白选错类型，后面全是坑。

这一章咱们就把两种凭据拉出来遛遛。不搞虚的，直接对比优缺点，聊聊什么场景该用哪个。

静态凭据：最熟悉的老朋友

静态凭据，说白了就是从不改变的那一类。比如写在配置文件里的数据库密码、代码里硬编码的、环境变量里的访问令牌。你部署一次，它就待在那，直到你手动改掉。

这种模式在早期项目里太常见了。我记得刚开始做微服务时，图省事把所有地方都配了同一个数据库密码。结果后来有一次排查线上问题，发现业务日志里居然打印了明文密码——那是我自己为了调试加的log，忘了删。当时冷汗就下来了。

优点

• 实现简单：不用额外组件，写好就能跑。
• 调试方便：出问题时凭据不变，复现路径清晰。
• 延迟低：不需要临时去请求凭证，直接拿来用。

缺点

• 泄露就是灾难：一旦被dump出来，只要没人改，黑客可以一直用。
• 轮换成本高：改一个密码，要通知所有依赖方，还得重启服务。我经历过一次轮换，改了40多个配置文件，总担心漏掉哪个。
• 审计困难：很难区分某个操作是谁用静态凭据做的——因为大家都共享同一个秘钥。

维度	静态凭据
生命周期	长期，通常数月至数年
泄露影响	大，一旦泄露，可被持续利用
运维负担	高，轮换需要停机或灰度
合规性	弱，难以满足SOC2等频繁轮换要求

动态凭据：用完就作废

动态凭据是另一个极端。它不是固定的，而是每次需要时才向一个凭据中心请求。用过就过期，下次再来一次。最常见的例子是AWS的STS临时令牌，或者Vault动态生成的数据库密码。

我几年前做一个内部运维平台时，全面转向了动态凭据。每个容器启动时，都会向Vault请求一个短期数据库账号。用完了，那个账号就自动被Vault吊销了。刚开始团队里有人反对，觉得多了一步网络交互，增加了延迟。但后来生产环境出过一次数据库密码泄露事件——我们查日志，发现那个临时账号只活了15分钟，等攻击者想复用的时候，早就失效了。嗯，从那以后，反对声就消失了。

优点

• 泄露窗口短：凭据有效期可控，通常几分钟到几小时。攻击者拿到了也是个废品。
• 自动化轮换：不需要人参与，系统自动处理过期和续期。
• 细粒度控制：可以为每个请求或每次调用，生成不同权限的临时凭据。

缺点

• 架构复杂：需要搭建或集成凭据中心（如Vault、AWS Secrets Manager）。
• 依赖可用性：如果凭据中心挂了，新的服务可能无法获取凭据启动。
• 调试困难：凭据说没就没，想重现一个线上问题，可能需要实时捕获。

维度	动态凭据
生成方式	按需生成，从凭据中心获取
生命周期	短期，通常分钟到小时级
轮换	自动，无需人工介入
泄露影响	小，临时凭证抵达后迅速失效
运维负担	中等，初期搭建成本较高

核心差异对比

我整理了一张对比表。你一看就清楚，两者在关键维度上的差别有多大。

对比维度	静态凭据	动态凭据
生命周期	长期固定	临时、可配置
泄露风险	高，一旦泄露持续可用	低，泄露后很快失效
运维负担	低配置，高维护（轮换困难）	高配置，低维护（自动轮换）
合规性	难以满足频繁轮换要求	天然适配短期凭证审计
调试难度	低，凭据固定	中等，需考虑时效
实现成本	低	中到高
典型场景	传统单体、开发环境、外网访问	云原生、微服务、自动化流水线

怎么选？我的决策框架

你可能会问：我到底该用哪种？我的经验是，没有银弹。你得看具体场景。

选静态凭据的场景

• 开发环境：改得频繁，不值得搭一套凭据中心。我通常就用固定的Dev账户，但会在季度末统一轮换一次。
• 遗留系统对接：老系统不支持动态凭据协议，只能写死。这时候我会在外层加一层代理，由代理来做凭据中转。
• 外部第三方强依赖：对方只给你一个固定，那没办法，只能静态。但要设置严格的访问来源白名单。
• 离线或低延迟场景：比如嵌入式设备、金融交易系统，每次请求都要去拿临时凭据，延迟确实扛不住。

选动态凭据的场景

• 云原生架构：Kubernetes集群里，Pod随时扩缩，每个Pod都应该用临时身份。
• 数据库访问：应用层对数据库的访问，我强烈建议用短期账号。即使应用被攻破，数据库密码不会泄露。
• 高安全合规环境：金融、医疗、政务等，审计要求凭证必须频繁轮换，动态凭据是最省心的方案。
• CI/CD流水线：每次构建、部署，都应该使用临时令牌，不要共享长期。

混合模式

现实中，我做过的大多数项目都是混合的。核心服务用动态凭据，边缘模块用静态凭据。比如订单服务用Vault动态密码读取数据库，而监控脚本用固定的只读。

嗯，选型的关键就一句话：能动态的动态，必须静态的做好隔离和轮换计划。