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

一、密评季的真实痛点技术做完了材料却拿不出来每年密评季都会出现一类高度相似的场景系统该上的国密算法都上了传输链路换成了国密套件存储加密也做了密码产品采购合同、检测报告、型号证书一摞一摞摆在桌上。结果测评员问了一句你们的密钥在哪儿生成、存放在哪儿、谁有权导出、什么时候轮换过、轮换记录给我看一下全场安静。很多团队在百度搜索密评整改方案时真正想确认的其实不是要不要买密码机而是**“我们做的这些事怎么变成测评员认可的证据”。这两件事差别极大前者是采购问题后者是工程与治理问题。密评不是考你有没有密码技术而是考你这套密码技术在真实系统里是否按规矩运行**以及你能否证明它一直在按规矩运行。尤其在等保2.0与密评并行的单位往往会出现一种错觉等保过了密评应该差不多。实际上等保关注的是访问控制、身份鉴别、审计、剩余信息保护等通用安全要求而密评关注的是密码应用的合规性、正确性、有效性。前者问有没有锁后者问锁芯是不是符合国家密码标准、钥匙是不是统一配发管理、谁配过钥匙有没有记录。密钥管理恰恰是这两套体系交叉最深、也最容易丢分的地方。先给出本文的核心判断在密评的四个技术层面里密钥管理是唯一一个既是独立指标、又渗透到其他三个层面的维度。算法合规不合规要看你用的密钥是不是合规算法生成的技术合规不合规要看密钥是不是用在正确的位置上产品合规不合规要看密钥是不是在合规产品内部产生和保护。所以密钥管理做扎实了四个层面一起受益密钥管理做虚了四处漏风。二、先把密评到底评什么讲清楚四个技术层面密评的技术评估通常被归纳为四个层面行业内常简称为四个技术。理解这四个层面的边界是准备材料的前提。2.1 密码算法合规性这一层回答的是用什么算法。核心是判断系统中实际使用的算法是否属于国家密码管理部门批准的算法即 SM2非对称加密与签名、SM3哈希、SM4对称加密、SM9标识密码、ZUC序列密码等以及在国际算法互通场景下是否做了正确的过渡与标识。测评员在这一层的典型动作是抓包看握手套件、看代码或配置文件里写死的算法标识、看密码产品的算法支持清单、看随机数检测报告。常见的翻车点是配置里写的是国密实际跑的是国际算法或者签名用了 SM2但摘要还是用了不合规的哈希组合以及随机数发生器没有检测报告。2.2 密码技术合规性这一层回答的是算法用得对不对。即便算法合规如果用法错了一样判不符合。这一层关注密码技术的应用场景与实现正确性比如身份鉴别用的是签名验签还是简单的哈希比对挑战值是否新鲜、是否防重放传输加密是单向认证还是双向认证证书链是否完整校验是否校验了吊销状态存储加密的密钥是否与数据分离存放是否做到了一数一密或一域一密完整性保护用的是签名还是带密钥的消息鉴别码是否覆盖了全部关键字段数字签名的私钥是否在合规产品内部产生且不可导出。这一层的证据主要来自设计文档、接口调用记录、抓包分析、代码走查。很多单位在这里失分是因为开发团队自己实现了一套加密而这套实现没有经过密码产品保护密钥以明文形式在内存或配置文件中出现。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 角色 × 动作矩阵下面这张表可以直接作为授权矩阵的设计蓝本动作管理员操作员审计员备注系统配置与服务启停允许禁止禁止配置变更需双人复核创建账号与分配角色允许禁止禁止不可给自己赋业务角色发起密钥生成申请禁止允许禁止生成在密码产品内完成审批密钥生成允许禁止不可自审禁止与发起人为不同人密钥分发与导入导出禁止允许需审批禁止导出必须加密形式密钥轮换禁止允许需审批禁止到期自动提醒密钥销毁禁止允许需审批禁止需见证人与销毁记录查看密钥明文禁止禁止禁止密钥永不明文导出查看审计日志禁止仅本人操作允许管理员无日志权限修改或删除审计日志禁止禁止禁止系统层面禁止导出审计日志与出审计报告禁止禁止允许定期出具这张表的价值在于可核查测评员可以现场让你演示用管理员账号尝试删除一条审计日志系统直接拒绝比任何口头说明都有说服力。七、密钥台账的字段设计一张表怎么填给一个可直接套用的台账字段设计。字段不求多但求能支撑测评员追问。字段说明示例密钥编号系统内唯一标识KEY-2026-00817密钥名称业务可读名称订单库字段加密主密钥所属系统对应等保定级对象/业务系统订单管理系统保护对象保护的数据或链路订单表手机号、身份证字段算法与长度标识与强度SM4 / 128 位密钥用途加密/签名/鉴别/密钥加密密钥加密KEK层级根密钥/主密钥/会话密钥主密钥KEK生成时间精确到秒2026-01-14 10:22:31生成方式产品内生成/导入服务器密码机内生成存储位置密码产品编号密码机 A / 槽位 3责任人操作员账号op_zhang轮换周期天/月365 天上次轮换时间2026-01-14到期提醒是否开启已开启提前 30 天当前状态在用/归档/已销毁在用备份情况是否有备份、组件保管人有三分量分别由三人保管关联证书如涉及 PKI证书序列号配套的系统资产对应表则把所属系统这一列展开系统名称、定级情况、部署位置、涉及的数据类别、使用的密码技术传输加密/存储加密/身份鉴别/完整性/不可否认、对应的密钥编号列表、对应密码产品。两张表通过密钥编号关联测评员无论从系统还是从密钥切入都能查到。八、测评现场会查什么、怎么问、怎么答这一节给一组高频问答示例句式可以直接用于现场应答。注意原则先说制度与依据再说系统实现最后拿出记录。不要只回答我们做了要给谁能证明和记录在哪。问你们系统里一共用了多少把密钥答我们建立了统一密钥台账当前在册密钥共 N 把覆盖 X 个业务系统。台账字段包含算法、长度、用途、责任人、轮换周期与状态。可以按系统导出也可以按密钥编号导出。这是按订单管理系统筛选后的清单。问密钥在哪里生成的用什么随机源答全部密钥在密码机内部生成应用侧只调用生成接口、只拿回密钥句柄或公钥不接触密钥明文。随机源是密码机内置的物理噪声源随机性检测报告在证据包四里。这是生成记录含时间、算法、长度、操作人。问密钥会不会以明文出现在应用服务器答不会。应用侧通过接口调用密码服务密钥不出密码产品边界。我们做了配置扫描检查配置文件与环境变量中不存放密钥材料。这是扫描检查记录。问谁能导出密钥答没有人能导出对称密钥明文。公钥允许导出用于分发给验签方导出需审批并留痕。导出动作由操作员发起、管理员审批审计员可查。这是导出审批记录与操作日志。问密钥多久轮换一次上次轮换是什么时候答按密钥分级设定周期根密钥与 KEK 按年、数据加密密钥按季度或按量触发。到期系统自动提醒。这是最新一次轮换记录含旧密钥归档方式与新密钥启用时间。问密钥备份怎么管能演示一次恢复吗答备份采用分量机制分量由不同保管人分别持有与生产密钥在存储位置和权限上分离。恢复需发起申请、审批、多分量到场。这是备份保管登记和恢复演练记录演练每半年一次。可以现场演示恢复流程。问有人离职了他的权限怎么回收答账号与角色由管理员统一回收回收动作留痕。该人员此前发起的所有密钥操作记录保留在审计日志中可按人员导出。这是该人员权限回收记录与历史操作记录。问审计日志会不会被管理员删掉答不会。日志只追加存储系统层面不提供删除接口管理员账号无审计查看权限。审计由独立审计员负责定期出具审计报告。可以用管理员账号现场演示系统拒绝。问如果密钥泄露了怎么办答我们有密钥安全事件处置流程包含发现上报、影响评估、密钥吊销或销毁、数据重加密、追溯与改进五个环节并定期演练。这是流程文件和最近一次演练记录。现场演示建议提前排练四项随机指定密钥导出全生命周期记录用管理员账号尝试删除审计日志预期失败演示一次密钥轮换演示一次备份恢复。这四项打通测评员的信任度会明显提升。九、整改优先级排序与典型周期整改不能平均分力。建议按补不出来的先动和影响面大的先动两个维度排序。优先级整改项为什么优先典型周期P0密钥明文存储清理与轮换高风险项且历史明文无法事后消除6–12 周P0随机数合规改造牵动算法层面判定需改造生成路径4–8 周P0审计日志防篡改与独立审计角色记录需要时间积累越早越好3–6 周P1三权分立与高危操作审批流制度配置需组织协调4–8 周P1备份分量化与恢复演练需要演练记录作为证据4–6 周P1台账与资产对应表建立前置工作其他材料的目录2–4 周P2轮换策略落地与到期提醒需跑满一个周期才有说服力持续P2策略文件体系完善与流程同步迭代持续P2培训与定期审计机制长期治理持续一个典型的整体整改进度可以按四个阶段推进第一阶段差距分析与资产梳理2–4 周确定密评对象范围、梳理信息系统资产、盘点现有密钥、形成差距清单与风险分级。第二阶段技术整改6–10 周收敛密钥生成与存储路径、清理明文密钥、接入统一密钥管理系统、改造应用调用方式、部署日志防篡改。这个阶段是工程量主体。第三阶段制度与流程落地4–6 周建立角色与授权矩阵、制定密钥管理策略与应急预案、完成一次备份恢复演练、一次密钥轮换、一次销毁演练形成连续记录。第四阶段自查与预评估2–4 周按测评指标逐项自查组织一次内部预评估或请第三方做差距复查补齐材料再进入正式测评。需要提醒的是第三阶段的记录类证据必须有时间跨度。测评员看到所有记录都集中在测评前两周可信度会打折扣。所以最省时间的做法是技术整改启动的同时就把制度与记录流程开起来让记录自然沉淀两三个月。十、落地步骤从差距分析到复评的七步下面给一条可直接执行的主线其中第三步是材料体系能否成型的关键。第一步定边界明确本次密评对象包含哪些系统、哪些数据流、哪些外部接口。边界不清后面所有材料都会失焦。第二步盘密钥对边界内的系统进行全量密钥盘点包括配置文件里的、代码里的、数据库里的、密码机里的、证书里的。盘点结果直接进台账。第三步收敛到统一平台把密钥的生成、存储、使用、轮换、销毁全部收敛到一个密钥管理系统应用侧不再自己持有密钥材料。以安当KSP为例这类平台提供 RESTful 及多语言接口业务侧改造量通常集中在把本地密钥换成接口调用这一段配合八大加密组件可以按场景选择接入深度。第四步划权限按第六节的矩阵建立管理员、审计员、操作员三类角色配置高危操作的多人审批与分量机制。第五步定策略并跑起来设定分级轮换周期、备份策略、销毁条件、到期提醒并确保系统自动执行或至少自动提醒加人工确认。第六步建材料体系按第五节的五个证据包整理成册台账与资产对应表作为目录其余材料按编号索引。第七步预评估与复评邀请第三方或内部安全团队按测评指标做一次预评估针对发现的差距补正再进入正式测评。在第三步的接入改造上一个常见的技术判断是不要试图一次性把所有系统接进来。优先接三类一是涉及重要数据存储加密的二是涉及身份鉴别与签名的三是对外接口中承担完整性保护职责的。这三类覆盖后密评的主要得分点基本落袋其余系统可以二期推进。十一、材料清单可直接照着准备最后给一份完整的材料清单按制度类、技术类、运行记录类三组组织。制度类密码应用方案与密评相关设计文档密钥管理策略生成、长度、用途、轮换、备份、销毁密钥管理岗位职责说明与三员分离制度密钥安全事件应急预案与处置流程密码产品使用与运维管理制度人员保密与离岗交接制度技术类密码产品型号证书、检测报告、固件版本、设备铭牌照片密钥管理系统相关检测证明与部署拓扑图系统中实际使用的算法清单与用途说明随机数检测报告密钥分层结构与保护机制说明含分量机制说明应用调用密码服务的接口说明与调用点清单日志防篡改机制说明备份与恢复技术方案运行记录类密钥台账与系统资产对应表密钥全生命周期操作日志样本按密钥、按人、按时间三种维度密钥导入导出审批单与操作记录密钥轮换历史记录密钥备份保管登记与恢复演练记录密钥销毁审批与销毁记录含见证人审计报告周期性权限开通、变更、回收记录密钥安全事件处置演练记录培训记录准备材料时有一条经验给每一份材料编一个编号并在台账和索引表里引用编号。测评员问到某一项你能立刻说这是材料 R-07比翻箱倒柜找半天有效得多。十二、FAQQ1我们已经买了服务器密码机密钥管理是不是就自动合规了不会。密码机解决的是密钥的生成与运算保护解决不了权限分离、轮换记录、备份分量保管、审计独立这些管理要求。密评里密钥管理是独立计分的必须有对应的制度与记录支撑。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 接口业务侧改造集中在本地密钥改为接口调用这一段。如需推进密评整改建议按本文第十一步的材料清单先做一次自检把补得出来和补不出来的项分开排期优先启动需要时间沉淀的记录类证据再推进技术接改。