安当KSP：密评合规落地，密钥管理这一块的证据材料到底怎么备

一、密评季的真实痛点：技术做完了，材料却拿不出来

每年密评季，都会出现一类高度相似的场景：系统该上的国密算法都上了，传输链路换成了国密套件，存储加密也做了，密码产品采购合同、检测报告、型号证书一摞一摞摆在桌上。结果测评员问了一句"你们的密钥在哪儿生成、存放在哪儿、谁有权导出、什么时候轮换过、轮换记录给我看一下"，全场安静。

很多团队在百度搜索"密评整改方案"时，真正想确认的其实不是"要不要买密码机"，而是**“我们做的这些事，怎么变成测评员认可的证据”。这两件事差别极大：前者是采购问题，后者是工程与治理问题。密评不是考你有没有密码技术，而是考你这套密码技术在真实系统里是否按规矩运行**，以及你能否证明它一直在按规矩运行。

尤其在等保2.0与密评并行的单位，往往会出现一种错觉：等保过了，密评应该差不多。实际上等保关注的是访问控制、身份鉴别、审计、剩余信息保护等通用安全要求，而密评关注的是密码应用的合规性、正确性、有效性。前者问"有没有锁"，后者问"锁芯是不是符合国家密码标准、钥匙是不是统一配发管理、谁配过钥匙有没有记录"。密钥管理恰恰是这两套体系交叉最深、也最容易丢分的地方。

先给出本文的核心判断：在密评的四个技术层面里，密钥管理是唯一一个"既是独立指标、又渗透到其他三个层面"的维度。算法合规不合规，要看你用的密钥是不是合规算法生成的；技术合规不合规，要看密钥是不是用在正确的位置上；产品合规不合规，要看密钥是不是在合规产品内部产生和保护。所以密钥管理做扎实了，四个层面一起受益；密钥管理做虚了，四处漏风。

二、先把密评到底评什么讲清楚：四个技术层面

密评的技术评估通常被归纳为四个层面，行业内常简称为"四个技术"。理解这四个层面的边界，是准备材料的前提。

2.1 密码算法合规性

这一层回答的是"用什么算法"。核心是判断系统中实际使用的算法是否属于国家密码管理部门批准的算法，即 SM2（非对称加密与签名）、SM3（哈希）、SM4（对称加密）、SM9（标识密码）、ZUC（序列密码）等，以及在国际算法互通场景下是否做了正确的过渡与标识。

测评员在这一层的典型动作是：抓包看握手套件、看代码或配置文件里写死的算法标识、看密码产品的算法支持清单、看随机数检测报告。常见的翻车点是"配置里写的是国密，实际跑的是国际算法"，或者"签名用了 SM2，但摘要还是用了不合规的哈希组合"，以及"随机数发生器没有检测报告"。

2.2 密码技术合规性

这一层回答的是"算法用得对不对"。即便算法合规，如果用法错了，一样判不符合。这一层关注密码技术的应用场景与实现正确性，比如：

• 身份鉴别用的是签名验签还是简单的哈希比对，挑战值是否新鲜、是否防重放；
• 传输加密是单向认证还是双向认证，证书链是否完整校验，是否校验了吊销状态；
• 存储加密的密钥是否与数据分离存放，是否做到了一数一密或一域一密；
• 完整性保护用的是签名还是带密钥的消息鉴别码，是否覆盖了全部关键字段；
• 数字签名的私钥是否在合规产品内部产生且不可导出。

这一层的证据主要来自设计文档、接口调用记录、抓包分析、代码走查。很多单位在这里失分，是因为开发团队"自己实现了一套加密"，而这套实现没有经过密码产品保护，密钥以明文形式在内存或配置文件中出现。

2.3 密码产品合规性

这一层回答的是"承载密码的东西合不合规"。核心是系统中使用的密码产品（服务器密码机、签名验签服务器、智能密码钥匙、动态口令系统、证书认证系统等）是否取得了国家密码管理部门颁发的型号证书，是否在有效期内，型号、版本与现场实际部署是否一致。

这一层最常见的失分形态是三件套：

1. 采购了合规产品，但业务系统里那套加密逻辑实际上没调它，只是"买来放着"；
2. 证书上的型号与现场设备铭牌不一致，或软件版本与送检版本不一致；
3. 密码产品的密钥被导出到应用服务器上，形成了"合规壳 + 不合规内核"。

2.4 密钥管理安全性

这一层回答的是"密钥本身管得安不安全"。它是本文的主线，也是独立于前三层单独计分的一大块。条款关注密钥在其生命周期各环节的管理安全性，包括：生成、存储、分发、导入与导出、使用、备份与恢复、更新（轮换）、归档、销毁，以及贯穿全程的审计。

需要特别强调的是，密钥管理不是一个"有密码机就自动满足"的项。密码机只解决了"密钥在哪里产生、在哪里运算"，它解决不了"谁有权发起一次密钥生成请求"“这次请求有没有被批准和记录”“密钥在密码机之外流转时是否被保护”“备份组件由谁保管”。这些恰恰是测评员追问最深的部分。

把四个层面放在一起看，可以得到一张对照表：

三、密钥管理为什么是独立分量：它贯穿全生命周期的九个环节

把密钥管理拆成环节来看，每个环节都有明确的测评关注点和可交付证据。下面按生命周期顺序展开，这也是后面做台账和日志设计的骨架。

生成：密钥必须由合规密码产品内部产生，随机源需通过随机性检测，密钥长度符合算法规范。证据是"密钥生成记录"，包含生成时间、生成方式、算法标识、长度、用途、责任人。

存储：密钥不得以明文形式出现在密码产品之外的任何位置。在密码产品内部，密钥通常以分层密钥结构保护，根密钥由多分量机制保护。证据是"密钥存储保护说明 + 产品检测报告相关章节"。

分发：密钥从产生地到使用地的传输必须加密且完整性保护，接收方需验证。证据是"分发协议说明 + 分发记录"。

导入与导出：这是高危环节。对称密钥的导出必须以加密形式进行，公钥可以明文导出但需保证完整性，私钥原则上不可导出。证据是"导入导出审批单 + 操作日志"。

使用：密钥用途要绑定，一把密钥不能既做加密又做签名；密钥的使用要有访问控制。证据是"密钥用途属性表 + 调用鉴权日志"。

备份与恢复：备份密钥必须与生产密钥在权限、物理位置、保管人上分离；恢复操作要有审批与记录。证据是"备份策略文件 + 备份组件保管登记 + 恢复演练记录"。

更新与轮换：要有明确的轮换周期，并在到期、疑似泄露、算法强度不足时触发立即轮换。证据是"轮换策略 + 轮换历史记录"。

归档：历史密钥用于解密历史数据时，需安全归档，归档密钥同样受控。证据是"归档清单 + 归档密钥访问控制记录"。

销毁：密钥生命周期结束或泄露时必须销毁，销毁要彻底的、不可恢复，且要有销毁记录与见证。证据是"销毁审批 + 销毁记录 + 见证人签字"。

审计：以上每一个动作都要有不可篡改的日志，日志要能被审计员独立查看，且管理员不能修改审计日志。

这九个环节里，最容易做的是"生成"和"存储"（买了密码机就基本解决了），最难做的是"备份恢复"“轮换”“销毁"和"审计”，因为这几项需要制度、流程和人的参与，属于"组织性证据"，临时补是补不出来的。

四、密钥管理的六个高频失分点

结合常见测评结果，下面六个失分点出现频率最高。每一项都给出测评员的发现路径、判定后果和补救难度，便于你自查时排优先级。

4.1 密钥生成的随机数不合格

表现：密钥由应用自己用编程语言的随机函数生成，或者由不符合要求的噪声源产生。

测评员怎么发现：查看随机数检测报告、检查密钥生成代码路径、检查是否调用了密码产品的生成接口。

后果：直接判定算法层面不合规，甚至牵连整条加密链路。

补救难度：中。需要改造生成路径，把密钥生成收敛到密码产品内部，并对存量密钥做轮换。

4.2 密钥明文存储

表现：密钥写在配置文件、环境变量、代码常量、数据库表中，或者备份文件里。

测评员怎么发现：grep 式扫描配置文件、检查数据库表结构、查看备份介质、查看日志是否打印了密钥。

后果：密钥管理层面直接不符合，且属于高危风险项，通常会被写进"高风险问题"清单。

补救难度：中高。需要改造应用接入方式，把密钥改为从密钥管理系统按需获取或由密钥管理系统代管，同时清理历史明文痕迹并轮换密钥。

4.3 密钥权限未做分离

表现：一个人既是密钥管理员又是审计员，或者一个账号拥有"生成 + 导出 + 删除 + 清日志"的全部权限。

测评员怎么发现：查看角色与权限矩阵、现场要求演示一次高危操作、检查是否存在超级管理员账号。

后果：密钥管理层面不符合，且是重复出现的管理类问题。

补救难度：低到中。本质是配置与制度问题，但需要重新划分角色、调整流程，且要说服业务部门接受"流程变长"。

4.4 没有轮换与销毁记录

表现：密钥上线后再没换过；或者换过但没有任何书面或系统记录；旧密钥既不归档也不销毁。

测评员怎么发现：要求导出近一年的密钥操作记录，看有没有轮换、销毁事件；对比密钥创建时间与系统上线时间。

后果：判"管理制度未落实"，扣分且难以申辩。

补救难度：低。补流程、补记录、设自动提醒即可，但历史缺失无法伪造，只能从整改之日起建立连续记录。

4.5 备份密钥与生产密钥同权

表现：备份组件和生产密钥放在同一台服务器、同一个账号下；备份由同一个人保管；备份恢复无需审批。

测评员怎么发现：询问备份策略、查看备份存储位置、要求演示一次恢复、检查保管人登记。

后果：备份体系形同虚设，判不符合，常与权限分离问题叠加。

补救难度：中。需要物理或逻辑上分离、引入分量保管机制。

4.6 缺少审计或审计可被篡改

表现：日志只记成功不记失败；日志没有防篡改保护；管理员可删除自己的操作日志；审计日志无人定期查看。

测评员怎么发现：查看日志存储方式、尝试用管理员账号修改或删除日志、询问审计员由谁担任、查看审计报告。

后果：整条证据链被质疑，前面做的证据可信度全部打折。

补救难度：中。需要引入日志签名或只追加存储、独立审计角色、定期审计报告机制。

把这六项整理成一张自查表：

注意最后一列"能否临时补"：真正拖累整改周期的，恰恰是那些补不出来的项。所以整改优先级不能按"难度低先做"来排，而应该按"补不出来的先开始"来排。

五、用一套密钥管理系统把证据做全：五个可交付的证据包

如果你的密钥分散在各个应用、各个密码机、各个运维人员手里，那么每个系统都要单独证明一遍，成本极高。把密钥收敛到统一的密钥管理系统（KMS）上，最大的价值不是"更安全"这个抽象结论，而是把证据生产的责任从 N 个应用团队收敛到一个平台。

以安当KSP为例，这类平台在密评材料准备上的价值，可以拆成五个可交付的"证据包"。

5.1 证据包一：密钥台账与系统资产对应表

这是整套材料的目录。测评员第一件事通常是问"你们系统里一共用了多少把密钥"，答不上来，后面就被动。

一份合格的台账至少要能回答：这把密钥叫什么、属于哪个业务系统、保护的是哪类数据、算法是什么、长度多少、用途是什么、什么时候生成、什么时候该轮换、当前状态是什么、保管责任人是谁、在哪台密码产品里。

更进一步，还需要一份密钥与系统资产的对应表：左边是信息系统资产清单（等保定级对象、业务系统、数据库、接口），右边是这些资产使用的密钥编号。这张表把"密评对象"和"密钥"对上了，测评员才能按系统逐项核查。

5.2 证据包二：全生命周期操作日志

日志要覆盖前面说的九个环节，且要能被按密钥编号、按操作人、按时间区间三种维度检索导出。关键要求是：

• 成功与失败都要记录，失败更要记录；
• 记录要包含"谁、何时、对哪把密钥、做了什么操作、结果如何、从哪个终端发起"；
• 日志本身要防篡改，通常采用只追加存储 + 完整性校验；
• 日志要能被独立审计角色导出，管理员无权修改。

测评现场最常见的演示是：测评员随机指定一把密钥，让你导出它从生成到现在的全部操作记录。如果你需要找三个人去三个系统里翻日志，印象分就没了。

5.3 证据包三：三权分立的角色与授权矩阵

密钥管理系统要能把"管理员、审计员、操作员"三条权限线真正拆开，而且要在系统层面强制，不能只写在制度里。落地形态见下一节。

5.4 证据包四：密码产品资质与算法合规证明

包括密码产品型号证书、检测报告、固件版本、设备铭牌照片、部署拓扑图，以及密钥管理系统自身通过的相关标准检测证明（如密钥管理系统相关国家/行业标准符合性）。同时要提供系统中实际使用的算法清单，与产品能力清单做一次交叉核对。这一包的关键是"证书上的型号版本"与"现场跑的东西"必须一致，测评员一定会核。

5.5 证据包五：策略文件与运行记录

包括密钥管理策略（生成策略、长度策略、用途策略、轮换周期、备份策略、销毁策略）、密钥应急预案、密钥安全事件处置流程，以及这些策略被执行过的记录（轮换记录、备份演练记录、销毁审批单、审计报告）。

第五包最容易被忽略，但它是区分"制度健全"和"制度执行"的关键。只有文件没有记录，测评员会判"未落实"。

六、三权分立的落地形态：不是三个人，是三条权限线

“三员分离"是密评和等保里反复出现的词，但很多单位理解成"设三个账号”，这是不够的。真正的三权分立要求任意一个人无法独立完成一次高危密钥操作，且审计线独立于管理线。

6.1 三个角色的职责边界

管理员：负责系统配置、服务运行、账号创建与角色分配。关键点：管理员不能查看密钥明文、不能发起密钥业务操作、不能查看或修改审计日志。管理员管的是"系统"而不是"密钥"。

操作员：负责日常密钥业务操作，如生成申请、分发、导入导出申请、轮换、销毁申请。关键点：操作员不能审批自己的操作，且不能修改系统配置。

审计员：负责审计日志的查看、导出、审计报告的出具。关键点：审计员不能执行任何业务操作，也不能被管理员删除其审计权限；反过来，审计员也不能修改系统配置。

6.2 高危操作需要"多人到场"

除了角色分离，真正的高危动作还要叠加多分量机制。最典型的场景是根密钥的保护：根密钥不是以完整形式存放在任何一处，而是拆成若干个分量，分别由不同的人保管。要启用根密钥，需要达到规定数量的分量持有者同时到场、各自输入自己的分量，系统内部合成后短暂使用，使用完毕立即清除内存中的合成结果。

这个机制的意义在于：内鬼风险被降到最低，同时"谁参与过一次根密钥启用"这件事天然留下了多份独立记录。测评员非常认可这种设计，因为它同时解决了"权限分离"和"证据留痕"两个诉求。

6.3 角色 × 动作矩阵

下面这张表可以直接作为授权矩阵的设计蓝本：

这张表的价值在于可核查：测评员可以现场让你演示"用管理员账号尝试删除一条审计日志"，系统直接拒绝，比任何口头说明都有说服力。

七、密钥台账的字段设计：一张表怎么填

给一个可直接套用的台账字段设计。字段不求多，但求能支撑测评员追问。

配套的系统资产对应表则把"所属系统"这一列展开：系统名称、定级情况、部署位置、涉及的数据类别、使用的密码技术（传输加密/存储加密/身份鉴别/完整性/不可否认）、对应的密钥编号列表、对应密码产品。两张表通过密钥编号关联，测评员无论从"系统"还是从"密钥"切入，都能查到。

八、测评现场：会查什么、怎么问、怎么答

这一节给一组高频问答示例，句式可以直接用于现场应答。注意原则：先说制度与依据，再说系统实现，最后拿出记录。不要只回答"我们做了"，要给"谁能证明"和"记录在哪"。

问：你们系统里一共用了多少把密钥？
答：我们建立了统一密钥台账，当前在册密钥共 N 把，覆盖 X 个业务系统。台账字段包含算法、长度、用途、责任人、轮换周期与状态。可以按系统导出，也可以按密钥编号导出。这是按订单管理系统筛选后的清单。

问：密钥在哪里生成的？用什么随机源？
答：全部密钥在密码机内部生成，应用侧只调用生成接口、只拿回密钥句柄或公钥，不接触密钥明文。随机源是密码机内置的物理噪声源，随机性检测报告在证据包四里。这是生成记录，含时间、算法、长度、操作人。

问：密钥会不会以明文出现在应用服务器？
答：不会。应用侧通过接口调用密码服务，密钥不出密码产品边界。我们做了配置扫描检查，配置文件与环境变量中不存放密钥材料。这是扫描检查记录。

问：谁能导出密钥？
答：没有人能导出对称密钥明文。公钥允许导出，用于分发给验签方，导出需审批并留痕。导出动作由操作员发起、管理员审批，审计员可查。这是导出审批记录与操作日志。

问：密钥多久轮换一次？上次轮换是什么时候？
答：按密钥分级设定周期，根密钥与 KEK 按年、数据加密密钥按季度或按量触发。到期系统自动提醒。这是最新一次轮换记录，含旧密钥归档方式与新密钥启用时间。

问：密钥备份怎么管？能演示一次恢复吗？
答：备份采用分量机制，分量由不同保管人分别持有，与生产密钥在存储位置和权限上分离。恢复需发起申请、审批、多分量到场。这是备份保管登记和恢复演练记录，演练每半年一次。可以现场演示恢复流程。

问：有人离职了，他的权限怎么回收？
答：账号与角色由管理员统一回收，回收动作留痕。该人员此前发起的所有密钥操作记录保留在审计日志中，可按人员导出。这是该人员权限回收记录与历史操作记录。

问：审计日志会不会被管理员删掉？
答：不会。日志只追加存储，系统层面不提供删除接口，管理员账号无审计查看权限。审计由独立审计员负责，定期出具审计报告。可以用管理员账号现场演示，系统拒绝。

问：如果密钥泄露了怎么办？
答：我们有密钥安全事件处置流程，包含发现上报、影响评估、密钥吊销或销毁、数据重加密、追溯与改进五个环节，并定期演练。这是流程文件和最近一次演练记录。

现场演示建议提前排练四项：随机指定密钥导出全生命周期记录；用管理员账号尝试删除审计日志（预期失败）；演示一次密钥轮换；演示一次备份恢复。这四项打通，测评员的信任度会明显提升。

九、整改优先级排序与典型周期

整改不能平均分力。建议按"补不出来的先动"和"影响面大的先动"两个维度排序。

一个典型的整体整改进度，可以按四个阶段推进：

第一阶段，差距分析与资产梳理（2–4 周）：确定密评对象范围、梳理信息系统资产、盘点现有密钥、形成差距清单与风险分级。

第二阶段，技术整改（6–10 周）：收敛密钥生成与存储路径、清理明文密钥、接入统一密钥管理系统、改造应用调用方式、部署日志防篡改。这个阶段是工程量主体。

第三阶段，制度与流程落地（4–6 周）：建立角色与授权矩阵、制定密钥管理策略与应急预案、完成一次备份恢复演练、一次密钥轮换、一次销毁演练，形成连续记录。

第四阶段，自查与预评估（2–4 周）：按测评指标逐项自查，组织一次内部预评估或请第三方做差距复查，补齐材料，再进入正式测评。

需要提醒的是，第三阶段的记录类证据必须有时间跨度。测评员看到"所有记录都集中在测评前两周"，可信度会打折扣。所以最省时间的做法是：技术整改启动的同时，就把制度与记录流程开起来，让记录自然沉淀两三个月。

十、落地步骤：从差距分析到复评的七步

下面给一条可直接执行的主线，其中第三步是材料体系能否成型的关键。

第一步，定边界：明确本次密评对象包含哪些系统、哪些数据流、哪些外部接口。边界不清，后面所有材料都会失焦。

第二步，盘密钥：对边界内的系统进行全量密钥盘点，包括配置文件里的、代码里的、数据库里的、密码机里的、证书里的。盘点结果直接进台账。

第三步，收敛到统一平台：把密钥的生成、存储、使用、轮换、销毁全部收敛到一个密钥管理系统，应用侧不再自己持有密钥材料。以安当KSP为例，这类平台提供 RESTful 及多语言接口，业务侧改造量通常集中在"把本地密钥换成接口调用"这一段，配合八大加密组件可以按场景选择接入深度。

第四步，划权限：按第六节的矩阵建立管理员、审计员、操作员三类角色，配置高危操作的多人审批与分量机制。

第五步，定策略并跑起来：设定分级轮换周期、备份策略、销毁条件、到期提醒，并确保系统自动执行或至少自动提醒加人工确认。

第六步，建材料体系：按第五节的五个证据包整理成册，台账与资产对应表作为目录，其余材料按编号索引。

第七步，预评估与复评：邀请第三方或内部安全团队按测评指标做一次预评估，针对发现的差距补正，再进入正式测评。

在第三步的接入改造上，一个常见的技术判断是：不要试图一次性把所有系统接进来。优先接三类：一是涉及重要数据存储加密的；二是涉及身份鉴别与签名的；三是对外接口中承担完整性保护职责的。这三类覆盖后，密评的主要得分点基本落袋，其余系统可以二期推进。

十一、材料清单（可直接照着准备）

最后给一份完整的材料清单，按制度类、技术类、运行记录类三组组织。

制度类

• 密码应用方案与密评相关设计文档
• 密钥管理策略（生成、长度、用途、轮换、备份、销毁）
• 密钥管理岗位职责说明与三员分离制度
• 密钥安全事件应急预案与处置流程
• 密码产品使用与运维管理制度
• 人员保密与离岗交接制度

技术类

• 密码产品型号证书、检测报告、固件版本、设备铭牌照片
• 密钥管理系统相关检测证明与部署拓扑图
• 系统中实际使用的算法清单与用途说明
• 随机数检测报告
• 密钥分层结构与保护机制说明（含分量机制说明）
• 应用调用密码服务的接口说明与调用点清单
• 日志防篡改机制说明
• 备份与恢复技术方案

运行记录类

• 密钥台账与系统资产对应表
• 密钥全生命周期操作日志样本（按密钥、按人、按时间三种维度）
• 密钥导入导出审批单与操作记录
• 密钥轮换历史记录
• 密钥备份保管登记与恢复演练记录
• 密钥销毁审批与销毁记录（含见证人）
• 审计报告（周期性）
• 权限开通、变更、回收记录
• 密钥安全事件处置演练记录
• 培训记录

准备材料时有一条经验：给每一份材料编一个编号，并在台账和索引表里引用编号。测评员问到某一项，你能立刻说"这是材料 R-07"，比翻箱倒柜找半天有效得多。

十二、FAQ

Q1：我们已经买了服务器密码机，密钥管理是不是就自动合规了？
不会。密码机解决的是密钥的生成与运算保护，解决不了权限分离、轮换记录、备份分量保管、审计独立这些管理要求。密评里密钥管理是独立计分的，必须有对应的制度与记录支撑。

Q2：密钥轮换周期定多长合适？
没有统一答案，通常按密钥层级区分：根密钥最长、密钥加密密钥居中、数据加密密钥较短。原则是"周期要写进策略、系统要有提醒、执行要有记录"，三者缺一不可。周期定得太长容易被质疑，太短则运维压力大，建议结合数据敏感度和密钥承载的数据量确定。

Q3：历史密钥已经轮换过，但当时没留记录，怎么办？
补不出来，不要伪造。正确做法是从整改之日起建立连续记录，并在差距说明中如实描述，同时说明已引入系统化的自动记录机制。测评更看重"当前是否受控且可持续"。

Q4：三员分离一定要三个人吗？小团队怎么办？
要求的是权限线分离，不是人数。但同一人不得兼任相互制约的两个角色，尤其是管理员与审计员必须分开。小团队可以由不同岗位人员兼任不同角色，但必须保证制约关系成立，且系统层面强制而非靠自觉。

Q5：密钥能不能导出备份？
对称密钥不得以明文形式导出。备份的正确做法是在密码产品内部完成，或采用分量机制由多人分别保管。备份与生产必须做到存储位置、保管人、权限三方面分离，且恢复需要审批与记录。

Q6：审计日志要保存多久？
建议至少覆盖一个完整测评周期并留有余量，具体以满足本单位制度与行业监管要求为准。关键不在时长而在完整性：日志必须只追加、防篡改、管理员不可删改。

Q7：自研的加密模块能通过密评吗？
自研模块本身不是问题，问题在于密钥是否在合规密码产品内产生和保护。如果自研模块里的密钥是明文常量或本地生成，基本会判不符合。改造路径是把密钥收归密码产品或密钥管理系统，自研模块只保留业务编排逻辑。

Q8：密评和等保能不能一次准备、两份用？
可以复用一部分证据，比如审计日志、权限管理、制度文件。但关注点不同：等保看访问控制和审计，密评看密码应用的合规、正确、有效。密钥台账、算法清单、密码产品资质这些是密评特有的，需要单独准备。

Q9：在百度上搜"密评不过怎么办"的人，最常见的误区是什么？
以为是买设备的问题，于是急着加购密码机。实际上多数不通过项集中在"密钥不在密码机里"“没有记录”"权限没分开"这三件事上，属于工程与治理问题，需要先改调用方式和流程，再谈设备扩容。

十三、几个容易踩的坑

坑一：把密钥管理平台装好就算完成。平台是工具，证据来自运行。装好不跑业务、不产生日志、不做轮换，等于没有。

坑二：制度文件写得漂亮，系统里没配置。制度说三员分离，系统里一个 admin 账号通吃。测评员现场一演示就露馅。

坑三：只准备"当前状态"，不准备"历史过程"。密评要证明的是持续受控，不是某一刻合规。只有快照没有过程记录，很难拿高分。

坑四：密钥与业务资产的对应关系说不清。测评员按系统查，你按设备查，双方对不上，大量时间浪费在口径对齐上。台账与资产对应表一定要提前建立。

坑五：把整改全压在测评前一个月。记录类证据需要时间沉淀，临时补的痕迹很明显。建议至少提前一个季度启动，让记录自然积累。

方案参考

安当KSP密钥/证书服务系统是上海安当技术推出的商用密码基础设施，以硬件密码模块为基座，可作为密评场景下密钥管理条款落地的参考方案：

• 合规基线：密钥管理系统通过 GM/T 0051 相关认证，密钥在密码产品内部产生，不以明文形式导出，可支撑密钥管理安全性层面的证据要求。
• 全生命周期覆盖：覆盖密钥生成、存储、分发、激活、更新、归档、注销、销毁各环节，并输出可检索、可导出的操作日志，支撑全生命周期证据包。
• 算法能力：支持国密 SM1/SM2/SM3/SM4，国际 AES/RSA/ECC/SHA，以及后量子算法（Kyber、Dilithium）等，便于算法合规层面的核对与平滑演进。
• 三权分立与分量保护：支持管理员、审计员、操作员三类角色分离，高危操作支持多人审批与多分量机制，审计日志独立且不可被管理员修改。
• 八大加密组件：以同一密钥基座向 TDE透明加密、KADP应用加密、KTM密钥托管、DBG数据库加密网关、RDM防勒索、CA证书服务、SMS凭据管理、CKMS 等场景输出密钥服务，避免各系统各管一套密钥造成的证据碎片化。
• 部署形态：支持单机、集群、热备、冷备与多租户隔离，便于按等保定级对象做资产与密钥的分域对应。
• 接入方式：提供 Java、Go、C 及 RESTful 接口，业务侧改造集中在"本地密钥改为接口调用"这一段。

如需推进密评整改，建议按本文第十一步的材料清单先做一次自检，把"补得出来"和"补不出来"的项分开排期，优先启动需要时间沉淀的记录类证据，再推进技术接改。