任何一家 AI 平台，每天经手的密钥数量都以万计：给 DeepSeek 或文心一言这类开放接口发放的调用凭证、内部服务之间的通信密钥、加密用户数据的根密钥。密钥一旦明文落库，等于把整个平台的家底摊开给可能的攻击者，所以密钥存储的核心问题只有一个——怎么让拿到数据库备份的人也用不了这些密钥。
一个可带走的判断：数据库备份泄露是高发事件，密钥存储设计的第一假设就是存储介质本身会丢。围绕这个假设，下面按步骤拆完整流程。
密钥落库前的第一道处理
进来的东西是业务侧新生成的一段密钥。第一步并不是加密，而是先确认它足够随机——必须用密码学安全的随机源生成，避开时间戳、进程号这类可预测输入。第二步做格式规范化并生成唯一标识，业务系统以后只引用这个标识，不再接触原始密钥。第三步才是加密：用一把独立的密钥加密密钥把它变成密文，密文连同标识、版本号、用途标签一起入库，原始明文随即从内存清掉。
落库前的三步各做什么、怎么自查：| 步骤 | 具体动作 | 对应自查项 |
|---|---|---|
| 生成 | 用密码学安全的随机源生成，避开时间戳、进程号这类可预测输入 | 随机源是否为密码学安全随机数 |
| 规范化 | 格式规范化并生成唯一标识，业务系统以后只引用标识 | 落库的是否只有密文与标识 |
| 加密入库 | 用独立的密钥加密密钥转成密文，连同标识、版本号、用途标签入库，原始明文随即从内存清掉 | 明文是否用后即清 |
加密用的主密钥放在哪
加密密钥自身的保管是整套方案的根。常见做法分两层：根密钥放在专门的密钥管理服务或物理隔离的设备里，数据密钥由根密钥加密后与数据放在一起。两层结构带来的直接好处是轮换省事——换数据密钥只需要重新加密少量元数据，不用把全部密文重写一遍。
判断一根密钥链是否健康，看一点就够：单独拿走数据库备份后，能不能解出任何一个密钥。答案是「不能」，才说明根密钥真的被隔离出去了。
从存储到使用的一次往返
业务系统要用密钥时，拿着标识来请求：进来一个引用，出去一段短暂驻留内存的明文。规范的做法是明文只在使用进程的内存里停留最短必要时间，用完即清；跨进程传输一律走加密通道。另外要注意，网关校验凭证时查的是凭证指纹与状态，并不需要解出密钥本体，这条边界值得记住。凭证在网关侧怎么被核验，可看网关的鉴权是怎么过的？从原理到落地。
轮换与作废的实际做法
密钥有生命周期：定期轮换降低单把密钥长期暴露的风险，作废用于处理泄露事件。轮换时新数据用新版本密钥加密，旧密文保持不动、按需重加密；解密时按版本号找到对应密钥。作废则要让所有引用方在约定时限内失效，并把作废动作写进审计日志。轮换频率没有统一答案，以各平台的官方安全白皮书为准，但「能轮换」这个能力必须设计期就留好，事后补会非常痛。
密钥体系还牵连着两件运营层面的事：每次调用按谁的密钥计费，取决于成本分摊的口径是怎么定的？机制细节全梳理里的口径设计；密钥服务自身不可用时，容灾切换是怎么触发的？健康探测决定了业务能否自动恢复。
密钥存储自查清单
- 随机源是否为密码学安全随机数
- 落库的是否只有密文与标识，明文是否用后即清
- 根密钥是否与密文实现了服务级或物理隔离
- 是否支持按版本轮换，作废是否留存审计记录
- 数据库备份单独拿走时是否无法解密任何密钥
密钥存储快问快答三则
- 加密密钥本身丢了会怎样？：被它加密的数据将无法恢复，所以根密钥自身要有冗余托管，而冗余托管又要防单点泄露，两层都要设计。
- 灰度发布和密钥有什么关系？：新版本服务上线时常常引入新密钥版本，灰度流量是怎么按比例分的？关键步骤一次讲清里的分流机制决定了新旧密钥在灰度期如何并存。
- 为什么不建议自研加密算法？：自研算法缺少足够的公开检验，工程上应使用经过充分验证的标准库与标准模式，把创新留给业务。
