密钥管理系统合规要求
密钥管理系统合规要求里最容易被判不符合的一条，不是算法选得对不对，而是密钥从生成到销毁的每一步能不能拿出证据。
整改单摘录（某三级信息系统密码应用安全性评估报告 · 已匿名化） [管理制度] 应根据密码应用方案建立相应密钥管理规则 —— 未提供 [管理制度] 应具备密码应用安全管理制度，含密钥管理 —— 部分符合 [设备和计算安全] 应采用密码技术对登录设备的用户进行身份鉴别 —— 部分符合三行里两行落在管理面，一行落在登录鉴别面。系统确实做了加密，密钥也确实存在，被卡的不是"有没有加密"，而是"拿不出过程证据"。
全文结构：
- 现场：密评整改单上那一行字
- 归因：密钥"有没有"与"管得对不对"是两件事
- 密钥管理系统国家标准：从 GM／T 0054-2018 到 GB／T 39786-2021
- 四个技术层面对密钥管理系统提出的硬指标
- 密钥管理系统登录认证：管理员侧与应用侧两条线
- 密钥全生命周期八个环节与各自举证材料
- 密钥管理系统白皮书该怎么读
- 部署形态、对接方式与示例命令
- 常见问题（FAQ）
- 三路线对比表
- 验收清单
- 相关阅读
一、现场：密评整改单上那一行字（密钥管理系统合规要求的边界）
1.1 三类最常见的"不符合"表述
翻过几十份密码应用安全性评估报告之后会发现，落到密钥管理上的问题高度集中在三类表述：
| 报告里的原话形态 | 实际意味着什么 | 补材料的难度 |
|---|---|---|
| "未提供密钥管理规则" | 密钥全生命周期没有成文规定，只有口头约定或开发文档里的片段 | 低，补制度 + 补记录 |
| "密钥未集中管理" | 密钥散落在各应用的配置文件、环境变量、代码仓库里 | 中，要改造接入 |
| "无法提供密钥操作审计记录" | 谁在什么时候用了哪把密钥、做了什么运算，平台查不出来 | 高，要重建日志链 |
第三类最难补。制度可以补写，接入可以排期，但历史审计记录是时间函数——没有就是没有，只能从改造完成之日起重新累积。
1.2 为什么"加密都做了"还是被判不符合
密码应用安全性评估的判定框架是三个词：合规性、正确性、有效性。
- 合规性看的是：用的算法、协议、密钥管理方式，是否符合法律法规和国家、行业标准；密码产品是否经核准或认证合格。
- 正确性看的是：配置和使用是否正确，安全性是否满足要求。
- 有效性看的是：密码保障系统在实际运行中是否真的起了作用。
很多团队把精力全投在"正确性"上——算法选 SM4、传输走国密 SSL、存储做字段加密——但在"合规性"这一层，密钥管理属于管理制度里的硬条款，且要求"应"级（不是"宜"）。用大白话说：密钥管理规则不是加分项，是必答项。
1.3 一个可操作的自查起点
在动任何采购和改造之前，先用一页纸回答下面四个问题，答不上来的就是要整改的部分：
- 系统里一共有多少把密钥？分别属于哪个业务、哪个等级？
- 每把密钥由谁生成、存在哪里、什么时候轮换、什么时候销毁？
- 密钥的生成、导出、启用、停用、销毁，各有什么审批和记录？
- 管理员进入密钥管理平台，用的是什么身份鉴别方式？
最后一个问题直接对应整改单上"设备和计算安全—身份鉴别"那一行。
二、归因：密钥"有没有"与"管得对不对"是两件事
2.1 散养密钥的四种典型形态
密钥散落的形态比想象中稳定，几乎每家企业都能对上号：
- 配置文件型：
application.yml里躺着明文的secret.key，随代码一起进仓库、一起进镜像、一起进备份。 - 环境变量型：进 K8s ConfigMap 或 Deployment 的 env，运维在控制台上看得到明文。
- 数据库自管型：加密列用的主密钥存在同一库的另一张表里，权限没做隔离。
- 云上默认型：直接用云厂商 KMS 的默认主密钥，没有做密钥归属和轮换策略设计。
这四种形态的共同点是：密钥的生命周期不受控。谁都能读、改了没人知道、丢了没法定位影响面。
2.2 集中管理之后多出来的三件事
把密钥收进统一的密钥管理系统，表面上解决的是"散"，实质是多出三件原来做不到的事：
- 可举证：每一次密钥操作都留下带时间、带操作者身份、带前后状态的记录。
- 可收敛：轮换、吊销、销毁从一个入口下发，不必逐个应用改配置。
- 可分级：不同业务、不同数据等级用不同密钥，密钥之间按层级隔离，一把出问题不牵连全局。
这三件事正好对应上一节那三类"不符合"表述的解法。
2.3 分层密钥结构是落地的最小骨架
工程上最常用的是三层结构：
- 根密钥（KEK）：在密码模块内部生成并保存，不以明文形式离开模块边界，只用来保护工作密钥。
- 工作密钥（DEK）：由根密钥加密保存，真正参与业务数据的加解密运算。
- 会话密钥：按需临时生成，用后即毁，不落盘。
业务数据用 DEK 加密，DEK 用 KEK 加密后与密文同存，这就是常说的信封加密。它的价值在于：轮换时只需重新加密 DEK，不必重写整库数据。
三、密钥管理系统国家标准：从 GM／T 0054-2018 到 GB／T 39786-2021
3.1 从密钥管理系统合规要求反推：标准该怎么成对引用
做合规对标时，至少要知道四份文件的分工：
| 标准 | 名称 | 作用 |
|---|---|---|
| GM／T 0054-2018 | 信息系统密码应用基本要求 | 行业标准，早期密评的主要依据 |
| GB／T 39786-2021 | 信息安全技术 信息系统密码应用基本要求 | 由前者上升为国标，2021-10-01 实施，现行为主 |
| GB／T 43206-2023 | 信息安全技术 信息系统密码应用测评要求 | 测评侧口径，判定符合／部分符合／不符合 |
| GB／T 37092-2018 | 信息安全技术 密码模块安全要求 | 定义密码模块四个安全等级 |
写方案时把 GB／T 39786-2021 作为要求侧、GB／T 43206-2023 作为测评侧成对引用，是最不容易被挑刺的组合。
3.2 GB／T 39786-2021 的四加四结构
这份标准把要求拆成四个技术层面加四个管理方面：
- 四个技术层面：物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全。
- 四个管理方面：管理制度、人员管理、建设运行、应急处置。
密钥管理条款主要落在管理方面，同时在四个技术层面各有一条"身份鉴别"要求与之呼应。这就是为什么整改单上会同时出现"管理制度"和"登录鉴别"两类问题。
3.3 管理方面对密钥的具体要求
在第三级别指标中，与密钥直接相关的条款可以概括为三条：
- 应具备密码应用安全管理制度，包括密码人员管理、密钥管理、建设运行、应急处置、密码软硬件及介质管理等制度。
- 应根据密码应用方案建立相应密钥管理规则。
- 应对管理人员或操作人员执行的日常管理操作建立操作规程，并留存执行记录。
三条连用，其实就在说一件事：密钥管理要有制度、有规则、有记录。制度回答"应当怎么做"，规则回答"本系统具体怎么做"，记录回答"做没做"。
3.4 密码模块等级怎么选
GB／T 37092-2018 为密码模块定义了四个递增的安全等级。选型时不必一味往高走，而是看三点：
- 密钥是否需要在模块内部完成全部生成与运算（关系到是否要求"密钥不出模块"）；
- 部署环境是否有物理访问控制条件；
- 测评结论中该系统的密码模块等级判定基线。
实践中，三级及以上系统普遍要求密钥的生成、存储、运算在经认证的密码模块内完成，模块等级通常不低于二级。
四、四个技术层面对密钥管理系统提出的硬指标
4.1 物理和环境安全层
这一层对密钥管理系统的要求集中在机房与环境：密码设备所在区域应有访问控制与进出记录，电子门禁与视频记录的存储完整性应用密码技术保护。落到实施上，就是把密码机、密钥管理平台服务器放进受控区域，并把门禁与监控日志纳入完整性保护范围。
4.2 网络和通信安全层
密钥在节点之间流转时，通信实体要做双向身份鉴别，重要数据的传输机密性与完整性要用密码技术保障。对密钥管理系统而言，这意味着管理通道、同步通道、备份通道都要独立加固，不能与普通运维流量混在同一平面。
4.3 设备和计算安全层
这一层是整改单的高发区，核心两条：
- 应采用密码技术对登录设备的用户进行身份鉴别，保证用户身份的真实性。
- 远程管理设备时，应采用密码技术建立安全的信息传输通道。
翻译成落地动作：管理员登录密钥管理平台不能用静态口令单因素，远程登录要走加密通道，重要日志要做完整性保护。
4.4 应用和数据安全层
业务系统调用密钥服务时，同样要做身份鉴别；重要数据在传输与存储环节的机密性是"应"级要求。这里的关键是应用侧也要有身份，不能只靠网络位置隐式授权。
五、密钥管理系统登录认证：管理员侧与应用侧两条线
5.1 管理员侧：三权分立加双因素
密钥管理平台的权限设计，行业通行的做法是管理员、密钥管理员、审计管理员三权分立：
| 角色 | 能做什么 | 不能做什么 |
|---|---|---|
| 系统管理员 | 建账号、配策略、管节点 | 看不到密钥明文，不能导出根密钥 |
| 密钥管理员 | 生成、启用、轮换、吊销密钥 | 改不了自己的权限，删不掉审计日志 |
| 审计管理员 | 查看全部操作日志 | 做不了任何写操作 |
三权分立解决"一个人就能干完全流程"的问题，双因素解决"账号口令被冒用"的问题。管理员登录叠加 UKEY、动态口令或指纹因子，是最容易落地的组合。
5.2 应用侧：让调用方也有可验证身份
应用调用密钥服务常见三种凭证：
- 应用标识 + 应用密钥：最轻量，适合内部服务，但凭证本身要能被安全分发与轮换。
- 双向 TLS 证书：服务端与客户端互相验身份，适合跨网络边界调用。
- 签名挑战：客户端用私钥对服务端下发的随机数签名，服务端验签，私钥不出客户端安全芯片。
第三种安全性最高，也是无法安全保管长期凭证场景下常用的形态。
5.3 两条线的共同点：都要留证据
无论管理员还是应用，调用密钥服务时都应产生可审计的事件。一条合格的审计记录至少包含：时间、主体身份、操作类型、密钥标识、结果状态、来源地址。缺了任何一项，事后追溯都会出现断点。
六、密钥全生命周期八个环节与各自举证材料
6.1 八个环节与证据对照
| 环节 | 关键控制点 | 需要留存的证据 |
|---|---|---|
| 生成 | 在密码模块内生成，随机数质量合格 | 生成记录、模块证书 |
| 存储 | 不以明文形式离开模块，分级隔离 | 存储策略、权限矩阵 |
| 分发 | 加密通道下发，接收方身份可验 | 分发审批单、通道配置 |
| 使用 | 用途绑定，越权调用被拒 | 调用日志、拒绝记录 |
| 更新 | 定期轮换，新旧版本并存期可控 | 轮换记录、版本清单 |
| 备份 | 多分量备份，分人保管 | 备份清单、分量保管记录 |
| 恢复 | 恢复需多人在场，过程留痕 | 恢复审批、到场记录 |
| 销毁 | 销毁不可逆，关联数据同步处置 | 销毁审批、执行回执 |
6.2 轮换周期怎么定
轮换不是越频繁越好。常见做法是按密钥类型分层：
- 根密钥：以年为单位，且通常与密码模块生命周期绑定。
- 工作密钥：以季度或月为单位，重要数据密钥可更短。
- 会话密钥：单次会话或极短有效期，用后即毁。
定周期时同时要明确两个参数：新旧密钥的并存时长、旧密钥解密历史数据的保留时长。这两个参数没定，轮换就会变成事故。
6.3 应急处置：钥匙丢了怎么办
应急处置制度里必须写清三件事：
- 密钥疑似失控时的判定标准与上报路径；
- 吊销与重建的操作顺序，以及受影响数据的重新加密方案；
- 事后复盘与制度修订的时限。
安当的 KSP 密钥管理系统在这类场景中通常配合 HSM 使用：根密钥在密码模块内生成与保存，应用只拿到运算结果或经加密的工作密钥，重建时按多分量备份在多人到场条件下完成，全过程留痕。
七、密钥管理系统白皮书该怎么读
7.1 白皮书里必须能查证的四类内容
一份能用于选型的密钥管理系统白皮书，至少要给出四类可查证信息：
- 产品资质：是否取得商用密码产品认证，对应哪份标准（例如 GM／T 0051 对称密钥管理技术规范、GM／T 0028 密码模块安全技术要求）。
- 算法清单：国密与国际算法的支持范围，是否含 SM2／SM3／SM4 及 FPE 等特化算法。
- 架构分层：业务层、加密组件层、密钥核心层、密码模块层的职责划分。
- 接口与部署：SDK 语言、REST 接口、部署形态、高可用与备份方案。
7.2 把白皮书能力翻译成验收条款
读白皮书最有效的办法，是边读边把每一条能力写成一句验收条款。例如：
| 白皮书表述 | 翻译后的验收条款 |
|---|---|
| "密钥在密码模块内生成与存储" | 现场演示在模块内生成密钥，并展示无法通过任何接口导出明文 |
| "支持密钥自动轮换" | 配置一条轮换策略，验证到期自动执行且业务无中断 |
| "全量操作审计" | 随机抽取一次历史操作，能从日志还原操作者、时间、对象、结果 |
7.3 三个容易踩空的承诺
- "支持国密算法"——要问清是算法库支持，还是整套链路（证书、传输、存储、签名）都走国密。
- "高可用部署"——要问清节点间密钥同步是实时还是准实时，主备切换时是否丢请求。
- "对接任意业务系统"——要问清提供的是 SDK、REST 接口还是两者都有，改造量多大。
八、部署形态、对接方式与示例命令
8.1 三种部署形态的取舍
| 形态 | 适用场景 | 主要顾虑 |
|---|---|---|
| 本地私有化 | 数据不出内网、合规要求高的系统 | 需要自备密码模块与容灾 |
| 私有云／专有云 | 已建成云平台，希望统一密钥服务 | 平台与密码模块的信任边界要划清 |
| 多云统一管理 | 业务分布在多个云上，需统一策略 | 跨云密钥同步与归属策略复杂 |
安当的 CKMS 面向多云密钥管理场景，做 BYOK 与信封加密的承接；需要强合规与本地运维的场景，则由安当的 KSP 配合 HSM 落地。两者的密钥底座是同一套，差别在部署位置与纳管范围。
8.2 接口调用示例（占位）
下面的命令仅用于说明调用形态，地址与凭证一律用占位符表示，实际部署时替换为本环境的值：
# 1) 取访问令牌（占位域名与占位令牌） curl -sS -X POST "$CKMS_API/auth/token" \ -H "Content-Type: application/json" \ -d '{"app_id":"demo-app","app_secret":"$APP_SECRET"}' \ -o token.json TOKEN=$(jq -r '.access_token' token.json) # 2) 创建一把工作密钥，指定用途与轮换周期 curl -sS -X POST "$CKMS_API/keys" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"alias":"order-db-dek","alg":"SM4","usage":"ENCRYPT_DECRYPT","rotate_days":90}' # 3) 申请用该密钥做信封加密（数据密钥由服务端返回密文与明文各一份） curl -sS -X POST "$CKMS_API/keys/order-db-dek/envelope" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"aad":"order-table:2026Q4"}'8.3 三条工程提醒
- 应用侧只应拿到经加密的工作密钥或运算结果，不应长期缓存明文密钥。
- 令牌有效期要短，且按应用粒度签发，避免一个令牌打通全部密钥。
- 调用失败要区分"鉴权失败""配额超限""密钥状态不可用"三类，前两类不能靠重试解决。
九、常见问题（FAQ）
Q：密钥管理系统合规要求里，最先该补的是哪一份材料？
A：先补密钥管理规则，再补操作记录。密钥管理规则是标准的"应"级条款，一份说清生成、存储、分发、使用、更新、销毁、备份恢复、应急八个环节责任人与审批路径的文件，能直接消掉整改单上的主项。
Q：密钥管理系统国家标准目前以哪一份为准？
A：要求侧以 GB／T 39786-2021 为准，测评侧以 GB／T 43206-2023 为准。GM／T 0054-2018 是前者的前身，可作为背景理解，写方案时直接引国标更稳妥，密码模块等级另看 GB／T 37092-2018。
Q：密钥管理系统登录认证这一项，测评时一般看什么？
A：主要看管理员登录是否采用密码技术做身份鉴别，以及是否留存鉴别日志。单因素静态口令通常判不符合，叠加 UKEY、动态口令或生物因子的双因素方案，配合完整的登录审计，是常见达标形态。
Q：读密钥管理系统白皮书时，怎么判断厂商说的是真能做到？
A：把每一条能力翻成可演示的验收动作再看。说密钥不出模块，就要求现场演示无法导出明文；说自动轮换，就要求配置策略后观察一次完整轮换，并验证业务无中断。
Q：密钥管理系统合规要求对小型系统是不是可以放宽？
A：要求随系统等级递进，等级越低条款越松，但密钥管理规则与操作记录这两项在低等级也有对应条款。规模小可以减少投入形态（例如用轻量密钥服务替代独立密码模块），不宜直接跳过制度与记录这两件事，因为测评时这两项属于有明确条款的必查内容。
十、三种落地方式的对比
| 维度 | 自研密钥管理模块 | 云厂商密钥服务 | 专用密钥管理系统 |
|---|---|---|---|
| 密码模块认证 | 通常无 | 云侧提供，等级依云服务而定 | 可对接经认证的密码模块 |
| 密钥归属 | 完全自有 | 与云平台绑定 | 自有，可跨云 |
| 生命周期举证 | 需自建审计 | 依赖云审计能力 | 内置全量操作审计 |
| 改造量 | 大 | 中 | 中，接口标准化 |
| 适用系统 | 非合规场景的轻量需求 | 全量在单一云上 | 三级及以上、多云或本地环境 |
十一、密钥管理系统合规验收清单
| # | 检查项 | 判定标准 | 状态 |
|---|---|---|---|
| 1 | 密钥管理规则成文 | 覆盖八个环节，责任人与审批路径明确 | ☐ |
| 2 | 密钥集中管理 | 无明文密钥散落在配置、环境变量、代码仓库 | ☐ |
| 3 | 密钥在模块内生成 | 生成记录可查，无法导出明文 | ☐ |
| 4 | 管理员双因素登录 | 静态口令之外叠加硬件或生物因子 | ☐ |
| 5 | 三权分立 | 管理员、密钥管理员、审计管理员权限互斥 | ☐ |
| 6 | 应用侧身份鉴别 | 每次调用携带可验证身份，越权调用被拒 | ☐ |
| 7 | 操作审计完整 | 时间、主体、操作、对象、结果、来源六要素齐备 | ☐ |
| 8 | 轮换策略生效 | 按密钥分层配置周期，并存期与保留期已定义 | ☐ |
| 9 | 备份与恢复可演练 | 多分量备份分人保管，恢复演练有记录 | ☐ |
| 10 | 应急处置有预案 | 失控判定、吊销重建、复盘时限均已明确 | ☐ |
| 11 | 密码模块等级达标 | 模块证书在有效期内，等级满足系统基线 | ☐ |
| 12 | 标准成对引用 | 要求侧与测评侧标准同时在方案中体现 | ☐ |
十二、相关阅读
- 密钥管理系统合规要求：运营商密钥管理落地指南（SIM 卡防护与云上 BYOK 托管选型）
- 密钥管理系统合规要求中的密钥注入环节：ETC 不停车收费的 OBU 与路侧设备分发
- 密钥管理系统合规要求与密评的关系：密评和等保到底有什么区别
- 重要数据加密与密钥管理怎么自查：数据安全风险评估办法落地解读
- 智能燃气表密钥安全分发：从产线注入到运营期分发的全链路
文章作者：安当加密技术负责人