密钥管理系统合规要求-创锋一号

密钥管理系统合规要求

密钥管理系统合规要求里最容易被判不符合的一条，不是算法选得对不对，而是密钥从生成到销毁的每一步能不能拿出证据。

整改单摘录（某三级信息系统密码应用安全性评估报告 · 已匿名化） [管理制度] 应根据密码应用方案建立相应密钥管理规则 —— 未提供 [管理制度] 应具备密码应用安全管理制度，含密钥管理 —— 部分符合 [设备和计算安全] 应采用密码技术对登录设备的用户进行身份鉴别 —— 部分符合

三行里两行落在管理面，一行落在登录鉴别面。系统确实做了加密，密钥也确实存在，被卡的不是"有没有加密"，而是"拿不出过程证据"。

全文结构：

现场：密评整改单上那一行字
归因：密钥"有没有"与"管得对不对"是两件事
密钥管理系统国家标准：从 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 与路侧设备分发
密钥管理系统合规要求与密评的关系：密评和等保到底有什么区别
重要数据加密与密钥管理怎么自查：数据安全风险评估办法落地解读
智能燃气表密钥安全分发：从产线注入到运营期分发的全链路

文章作者：安当加密技术负责人

企业官网建设流程全解析