本文从工程视角剖析凭据管理系统（Secret Management System）的三大支柱能力——统一加密存储、自动轮转、全程审计，并给出密钥与凭据分离的实现思路，适合需要在多云环境下治理数据库与中间件凭据的架构师与运维工程师。
1. 问题定义
凭据（credential）指一切用于身份鉴别的机密：数据库密码、API Key、中间件口令、云账号密钥。传统的分散管理模式存在三个结构性缺陷：
- 密钥与凭据同处一地：密码明文或弱加密存放在与应用相同的配置文件，泄露即失守。
- 轮转成本高：改一次密码要改配置、发版本、重启服务，于是"能用就不改"。
- 使用不可见：谁在什么时候用了哪个数据库密码，无人知晓。
凭据管理系统的本质，是把"凭据的存储、分发、生命周期、审计"从业务代码里抽象出来，变成独立的基础设施。
2. 架构模型
应用 ──(身份认证)──▶ 凭据管理系统 ──(临时凭据, TTL)──▶ 数据库/中间件
│
├── 加密存储（密文）
├── 密钥托管（KSP，不可导出）
└── 审计日志（append-only）
核心约束：应用不直接持有长期密码，只持有运行时由系统签发的、带有效期的临时凭据。
3. 统一加密存储与密钥分离
凭据明文在写入前加密，系统只保存密文。加解密密钥由独立的密钥管理模块（KSP）托管，密钥不可导出、操作有审计。即使凭据库整体泄露，攻击者拿到的也只是密文。
明文 ──[主密钥 K，托管于 KSP]──▶ 密文
算法层面同时支持 AES-256 与国际算法与国密 SM4，满足不同合规域要求。
4. 自动轮转
轮转是凭据管理中最容易被忽视却最关键的能力。一个健壮的轮转机制需要：
- 可配置的轮转周期（推荐 ≤90 天）。
- 新旧密码"双写共存期"，避免轮转瞬间连接失败。
- 轮转失败实时告警。
- 完整轮转历史，作为合规证明。
cm.configure_rotation(
credential_id="rds-order-db",
rotation_period=90,
dual_write_period=3, # 新旧密码共存 3 天
notify_before=7,
)
5. 动态临时凭据
每次凭据获取返回带 TTL 的临时凭据（典型 ≤1 小时），用完即销毁。这把"长期密码泄露"的风险转化为"短时令牌泄露"的低影响事件。
6. 全程审计
审计日志至少包含：时间戳、调用方身份、来源 IP、目标资源、操作结果、凭据 TTL。日志防篡改、可归档，可供安全运营与合规核查。
{
"ts": "2026-07-19T10:23:45Z",
"app": "order-service",
"cred": "rds-order-db",
"src_ip": "10.1.2.34",
"action": "GET_CREDENTIAL",
"result": "SUCCESS",
"ttl": 3600
}
7. 与特权访问管理的边界
凭据管理系统负责"机器/服务到资源"的凭据治理；特权账号管理（如远程桌面管理 RDM）负责"人到服务器"的权限管控。两者职责不同但互补：前者消除硬编码密码，后者落实人账分离与操作审计。在等保 2.0 框架下，二者共同覆盖身份鉴别与访问控制条款。
8. 工程落地建议
- 先盘点，再迁移：建立全量凭据清单。
- 密钥独立托管，严守密钥与凭据分离。
- 轮转从低风险凭据开始，验证双写过渡。
- 业务接入走 SDK，杜绝新硬编码产生。
- 审计日志接入统一 SIEM，设置异常告警。
本文为技术实现分析，所涉加密、轮转、审计能力可结合硬件密钥管理模块与国密算法落地。
