短时凭据是怎么用的
短时凭据（JIT，just-in-time）指按需签发、到期自动失效的凭据：临时安全令牌、动态数据库账号、短期客户端证书都属此类。它替换掉的是长期静态密钥——泄露窗口从「直到被发现」缩短到「几分钟到几小时」。落地前提是有一套身份系统与签发服务：请求方先证明自己是谁，服务再按策略签发带时限的凭据。三个容易被忽略的细节是时钟一致性（时间偏差会让凭据提前失效或延长有效）、续期失败的兜底、以及依赖链梳理。
基本信息
| 常见形态 | STS 临时凭据、动态数据库账号、短期客户端证书 |
|---|---|
| 优势 | 泄露窗口受限，推动自动化并天然产生审计记录 |
| 前提条件 | 身份系统与签发服务，以及各系统支持动态凭据 |
| 注意事项 | 时钟一致性、续期失败兜底、依赖链梳理 |
| 权限原则 | 有效期短不等于权限小，仍需最小权限 |
| 适用判断 | 凭据被拿到后能造成的损失越大越值得改成短时凭据 |
典型使用场景
- 服务间调用：工作负载身份换取短期令牌，取消长期共享密钥。
- 数据库访问：动态账号按需创建，会话结束即回收。
- 运维登录：临时提升权限并限定时长，操作留痕。
- CI/CD：流水线按次获取凭据，构建缓存里不留长期密钥。
- 第三方接入：给合作方发放短期凭据，到期自动失效。
流程示意
流程示意
身份认证（人或工作负载）-> 凭据服务签发（TTL）
-> 使用凭据访问目标系统 -> 到期自动失效或主动吊销
# 关键设计点：TTL 要短到有意义、续期要有重试与告警、时钟要同步
# 凭据不应被写入磁盘或日志，内存中使用完毕即丢弃落地检查项
| 检查项 | 风险 | 做法 |
|---|---|---|
| TTL 设置 | 过长则失去短时优势 | 按业务实际时长设定并留余量 |
| 时钟同步 | 偏差导致提前失效或延长有效 | 统一使用可靠时间源 |
| 续期机制 | 续期失败导致业务中断 | 重试加重载加告警 |
| 依赖链 | 部分系统不支持动态凭据 | 提前梳理并改造或保留过渡方案 |
| 权限范围 | 凭据短但权限大 | 配合最小权限原则设计 |
短时凭据不能替代权限最小化：有效期再短，权限过宽仍会放大风险，两者必须一起设计。