省级政务云等保三级与密评双达标实战路径与合规方案解读

某省级政务云平台做完等保三级测评，结论是"基本符合"，整改意见只有寥寥几条。三个月后同一套系统做密评，现场却被判了"不符合"------等保刚说没问题的地方，密评恰恰认为问题很大 。最典型的一条：平台的统一身份认证，"用户名+口令+短信验证码"，等保视角下满足了"两种以上鉴别技术组合"的要求；密评视角下却被追问：短信验证码走的是运营商通道，属于"密码技术"吗？口令存储用的是 SM3 还是明文加盐？ 前者不属于密码技术，后者如果用的不是国密算法，这一项直接不给分。

这不是两套标准谁写错了，而是它们本来就在看不同的东西。等保问"你的防护措施够不够"，密评问"你用密码这件事做得规不规范"。一个政务云平台要同时通过这两套评估，靠的不是"多买几台设备"，而是先搞清两条轨道各自的判据、周期和失分点，再按同一套技术底座去对齐。

全文结构：

一、双轨为什么"打架"：等保与密评的定位差异
二、双达标七个环节实战路径
三、四个技术层面的密码落地点
四、四个方面管理要求：另一半容易被忽略的分数
五、双达标最常见的八类失分项
六、把密码能力做成"可被测评的形式"
七、验收清单

一、双轨为什么"打架"：等保与密评的定位差异

要理解"等保过了、密评没过"，先要接受一个前提：这两套评估的监管主体、依据标准和观察视角都不同，结论不一致是常态，不是意外。

1.1 两套评估的六维差异

维度	网络安全等级保护测评	商用密码应用安全性评估（密评）
监管主体	公安机关	密码管理部门
核心依据	《网络安全法》、公通字〔2007〕43号、《信息安全等级保护管理办法》	《密码法》、《商用密码应用安全性评估管理办法》（国家密码管理局令第3号）
主要标准	GB／T 22239-2019（基本要求）、GB／T 28448-2019（测评要求）	GB／T 39786-2021（基本要求）、GB／T 43206-2023（测评要求）
观察视角	系统整体防护能力是否达标	密码技术使用是否合规、密钥管理是否可控
判据性质	"有没有做"为主，措施有效即可	"做得对不对"为主，算法、密钥、协议都要符合国密要求
测评周期	第三级每年至少一次等级测评 + 每年至少一次自查	重要网络与信息系统每年至少一次

最后一行两套周期常常被当成"一回事"，其实依据不同文件：《信息安全等级保护管理办法》第十四条明确第三级信息系统每年至少进行一次等级测评 ，同时要求每年至少进行一次自查；密评的年度要求则出自《商用密码应用安全性评估管理办法》第九条------重要网络与信息系统建成运行后，运营者应当自行或者委托商用密码检测机构每年至少开展一次商用密码应用安全性评估。两套评估都要做，不能互相替代，也不存在"等保过了密评就免了"。

1.2 关键差别：等保看"措施"，密评看"要素"

这个差别决定了整改的方向。用一个政务云上最常见的场景说明：

平台要求运维人员登录堡垒机必须"双因素认证"。等保测评关注的是------你确实配置了两种鉴别因素吗？有没有绕过路径？日志是否留存六个月以上？ 措施在、日志全，这一项就过。

密评关注的是完全不同的一组问题：

这两种鉴别因素里，哪一种是基于密码技术的？短信验证码不是，动态令牌（基于 SM2 挑战应答）是。
如果是口令鉴别，口令的存储和传输用了什么算法？如果是 SM3 加盐分段存储、传输走国密 TLS，符合；如果口令明文比对或用了国际算法，这一项要扣。
鉴别过程中用到的密钥从哪来、谁管、怎么轮换？如果密钥硬编码在配置文件里，即便算法用的是 SM2，这一项同样不给分。

换句话说，等保检查"你有没有锁门"，密评检查"你的锁是不是合规的锁、钥匙有没有专人管、有没有备用钥匙流落在外"。前者是管理视角的完备性，后者是技术视角的合规性。政务云平台的典型困境正在这里：等保整改往往推动了一批安全设备的采购和策略配置，但密码算法的合规性、密钥的全生命周期管理，很可能整条链路都没被认真梳理过。

1.3 政务云还有一层特殊性：责任边界被托管切开了

普通机房里，安全责任是清晰的------谁的系统谁负责。政务云不一样，它有至少三方：

云平台运营方：提供计算、存储、网络、云底座，负责平台自身的等保与密评。
业务系统运营方（各委办局）：负责自己那套业务应用的等保与密评。
云服务商/运维方：可能托管数据库运维、代管备份。

密评现场最常出现的扯皮是："数据库里的敏感字段没加密"这条，到底算谁的责任？ 云平台运营方说"我提供的是 IaaS，数据是你的"；业务方说"数据库是你托管的，运维人员能直接看到数据"。

这类争议的正确解法是在合同和技术层面同时划清密码资源边界：平台方提供合规的密码运算资源和密钥管理基础设施（密码机、密钥管理系统），业务方负责业务数据的加密策略与密钥归属。边界划清了，密评现场才有一份可举证的"责任---控制"对应表；划不清，测评方只能按"整个系统未采取有效密码措施"来判。

二、双达标七个环节实战路径

理解差异之后，剩下的就是路径问题。政务云平台从零到双达标，通常会经历七个环节。下面按顺序拆开，每个环节给出做什么、交付物、最常见的失守点、可复制的取证方式四件事。

环节一：定级备案与密评范围界定

做什么 ：先确定系统的等保级别（政务云平台通常定三级，涉及大量公民个人信息的核心系统可能更高），完成公安备案；再根据定级结果确定密评范围------按《商用密码应用安全性评估管理办法》，需要开展密评的是关键信息基础设施，以及网络安全等级保护第三级及以上的信息系统。

交付物：定级报告、备案证明、系统边界说明书（含网络拓扑、数据流向、密码资源清单）。

最常见的失守点 ：边界画得太窄或太宽。画太窄------只把门户网站纳入范围，把后台的数据交换平台、共享交换区漏在外面，现场一到数据流向图就露馅；画太宽------把整朵云都包进来，结果云上一百多个业务系统的密码应用状况参差不齐，测评范围失控，整改无从下手。

政务云的合理做法是按"业务系统 + 支撑平台"分层界定：先明确本次评估的是哪一个具体的政务应用系统，再把它依赖的数据库、中间件、密码资源作为支撑环境纳入，但不把整个云平台的其他租户拖进来。

取证方式：

bash 复制代码

# 梳理系统边界时，先摸清真实的数据流向与对外暴露面
# 1) 列出本系统对外暴露的服务端口与协议（在业务侧主机上执行）
ss -tulpn | awk '{print $1, $5, $7}' | sort -u

# 2) 确认数据库实例与连接来源，判断数据是否跨系统流动
#    数据库连接串中的主机名统一使用占位，实际以部署文档为准
mysql -h db.example -u audit_ro -p -e "SHOW PROCESSLIST;" 2>/dev/null | head -20

# 3) 记录密码资源的调用关系（密码机/密钥管理服务的实际调用方）
grep -r "HSM_API\|KSP_API" /etc/app/conf/ 2>/dev/null | sed 's/=.*/=<masked>/'

第三条命令是密评现场很吃香的一份材料------能拿出"哪个应用调用了哪种密码资源"的清单，说明你对密码应用现状是真清楚的，而不是测评时才临时去翻。

环节二：差距分析（等保差距 + 密码应用差距）

做什么 ：对照两套标准做逐条比对，输出两张差距清单。等保差距按 GB／T 22239-2019 的十个安全类（安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心 + 四个管理类）逐项过；密评差距按 GB／T 39786-2021 的四个技术层面 + 四个方面管理要求逐项过。

交付物：等保差距清单、密评差距清单、整改优先级排序表。

最常见的失守点 ：只做等保差距，密码应用差距凭经验估 。政务云平台里有一类高频情况------密码机买了、证书也配了，但实际业务流量根本没走密码通道：TLS 配置里国密套件排在最后，客户端协商结果回落到国际算法；或者数据库只是"开启了加密选项"，实际加密的是备份文件而不是数据文件；或者签名验签做了，但验签的业务侧只验内容不验证书链有效期。

这类"配置在、实效无"的问题，等保测评大概率发现不了（措施存在），密评现场一测就穿（用工具一验就知道实际协商的是什么算法）。所以差距分析阶段必须以实测结果为准，不能以配置文档为准。

取证方式：

bash 复制代码

# 密评差距分析阶段的核心动作：实测而非读配置
# 1) 抓取服务端实际协商的 TLS 参数（国密改造后应协商到 GM／T 0024 定义的套件）
openssl s_client -connect portal.example:443 -showcerts </dev/null 2>&1 \
  | grep -E "Protocol|Cipher|Server public key"

# 提示：不同国密实现的套件命名不统一，套件名以工具实际输出和设备厂商文档为准，
#      不要按印象手写套件字符串；拿不准时以检测机构提供的工具链输出为准。

# 2) 确认数据库数据文件落盘是否真的加密（而非仅备份加密）
#    思路：在测试环境写入一条可识别标记，然后在数据库停止状态下直接读取数据文件
#    若能在文件中检索到明文标记，说明存储层未加密
grep -c "AUDIT_MARKER_" /var/lib/mysql/audit_test/records.ibd 2>/dev/null
# 输出为 0 = 未检索到明文，符合加密预期；输出非 0 = 明文落盘，此项必扣分

# 3) 核对证书链与算法标识
openssl x509 -in server_cert.pem -noout -text \
  | grep -E "Signature Algorithm|Public-Key|Not After"

环节三：方案设计与"三同步"

做什么：把差距清单转成密码应用改造方案，明确每个层面的技术选型、密码资源部署方式和密钥管理架构；同时落实政务信息化普遍要求的**"三同步"------密码应用与系统同步规划、同步建设、同步运行**。

交付物：密码应用改造方案、密码资源部署图、密钥管理架构说明、实施计划表。

最常见的失守点 ：把密钥管理放在方案最后一页，当成实施细节。这是密评失分最集中的地方。政务云平台上密钥管理的典型错误有三种：

根密钥用软件保护：密钥存储在应用服务器的配置文件或数据库表里，用口令加密后落盘。密评视角下，根密钥没有硬件保护，整个密钥体系的可信起点就不成立。
密钥管理员与密钥使用者是同一人：密钥的产生、分发、使用、销毁全由一个人完成，缺少双人双岗与权限分离，管理要求这一大块直接不给分。
密钥没有轮换机制：从上线到现在没换过，也没有轮换计划。密评会追问密钥使用期限的设计依据，拿不出依据就是失分项。

方案阶段必须把密钥管理提升到架构级 ：密钥按层级划分（根密钥、主密钥、工作密钥/数据密钥），逐层明确产生方式、存储介质、使用范围、轮换周期和销毁流程。根密钥由硬件密码模块保护且不可导出；主密钥由密钥管理系统统一纳管；数据密钥按业务或按表派生，做到一库一密、一表一密甚至一字段一密，任何一个密钥泄露的影响面都被限制在最小范围。

环节四：密码整改落地（四个技术层面）

做什么：按方案在物理环境、网络通信、设备计算、应用数据四个层面逐项落地密码措施。

交付物：整改实施记录、密码资源配置清单、策略配置截图/配置导出文件、测试报告。

最常见的失守点 ：只改"看得见的"，不改"跑得动的" 。举一个非常典型的例子------数字证书换了国密证书，但应用的信任库没同步更新，结果是新旧证书混用；或者签名验签接口改造了，但历史数据的验签逻辑没做兼容，导致改造后历史数据集体验签失败。这类问题不会在整改报告里出现，只会在业务侧的真实报错里出现。

所以整改落地必须包含一轮**"改造后业务回归"：不只看密码措施是否生效，还要看原有的业务流程有没有因为密码改造而断裂**。这部分内容在下面第三节按层面详述。

取证方式：整改阶段的取证要"可复现"------每项措施记录清楚"在哪台设备、哪个配置文件、改了什么、怎么验证"，现场测评时能当场复现一遍，比事后补文档有说服力得多。

环节五：自评与材料准备

做什么 ：在正式委托测评前，先按测评要求做一轮自评，把材料准备齐。密评的材料量通常比等保更大，因为它要求逐项举证密码技术的实际使用。

交付物：自评报告、密码应用情况说明表（算法---密钥---协议---设备逐项对应）、密钥管理制度文件及执行记录、密码设备资质材料。

最常见的失守点 ：材料与现场不一致 。材料上写"敏感字段采用 SM4 加密存储"，现场一验是明文；材料上写"密钥每年轮换一次"，翻不出轮换记录。密评是文档审查 + 现场测评双重手段，文档与现场对不上的代价比"根本没做"更大------前者会直接引发对整套材料可信度的质疑。

材料准备的正确姿势是以实测结果反推材料：先测、后写，测出来是什么就写什么，做不到的先补，补不上就在方案里写清补偿措施。宁可在材料里承认某一项"已规划、计划于某时间完成"，也不要写一个现场验不出来的结论。

环节六：委托测评与现场配合

做什么：按等保和密评各自的资质要求，选择具备资质的测评机构分别开展测评。

交付物：等保测评报告、商用密码应用安全性评估报告。

最常见的失守点 ：两个测评背靠背做，改完一轮再改一轮。等保测评提出"日志留存不足"，密评提出"密码运算日志未记录密钥索引"------两条整改意见都指向日志体系，如果分两轮做，日志模块要改两次、回归两次。

高效的做法是在同一时间窗内安排两套测评，较理想的是由同一时间段的整改团队统一对接，把两边的整改意见合并成一张清单再动手。代价是现场配合的人手要翻倍，收益是整改轮次从两轮压到一轮。

环节七：结果报送与复测周期

做什么：测评完成后，按规定向密码管理部门报送密评结果，向公安机关报送等保测评结果；同时把复测周期排进年度运维计划。

交付物：报送回执/记录、年度测评计划表。

最常见的失守点 ：把测评当成"一次性验收" 。两套评估都是年度动作 ：等保三级每年至少一次等级测评加一次自查，密评每年至少一次。更关键的是，系统发生重大变更后需要重新评估------政务云平台做版本升级、迁移上云、新增对外接口、扩容节点，都可能构成重大变更。很多平台在第二年测评时才发现，上一年的测评结论早已因为一次架构调整而失效。

建议做法 ：建立一份变更---评估联动清单，明确列出哪些变更类型会触发重新评估（密码设备更换、密钥体系调整、系统架构变化、对外服务面扩大等），把评估触发条件写进变更管理流程，而不是靠人记得。

三、四个技术层面的密码落地点

七个环节是时间线，四个技术层面是内容线。GB／T 39786-2021 对第一级到第四级的密码应用提出了基本要求，技术部分落在四个层面：物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全。政务云在这四个层面的典型落地点如下。

层面	密评关注的核心能力	政务云典型落地点	常见失守
物理和环境安全	人员身份真实性、访问记录完整性	机房出入口身份鉴别（国密门禁卡、指纹/人脸+国密签名）、视频记录完整性保护	门禁用的是普通 IC 卡，鉴别结果无密码保护
网络和通信安全	通信实体身份真实性、通信数据机密性与完整性	国密 TLS 改造（GM／T 0024）、纵向/横向边界加密通道、运维通道加密	国密套件未实际协商成功，回落国际算法
设备和计算安全	设备身份真实性、系统资源访问控制信息的完整性、重要信息完整性	运维登录双因素认证、堡垒机操作签名、系统日志完整性保护	只做口令认证，日志可被本地篡改
应用和数据安全	用户身份真实性、访问控制信息完整性、重要数据机密性与完整性、不可否认性	统一身份认证、敏感字段加密存储、电子凭证签名验签、数据脱敏	加密只覆盖新数据，历史数据仍明文

3.1 物理和环境安全：最容易"整层丢分"的地方

这一层常被误认为"跟政务云没关系，机房不是我的"。但只要有独立机房区域、有本地运维人员进出，这一层的分数就要拿。

要求的实质是人员身份真实性 + 访问记录完整性。达标的关键在于鉴别过程本身是否使用密码技术：门禁卡如果只是普通射频卡，鉴别结果没有任何密码机制保护，卡可以被复制，这一层就不给分；如果用的是带国密算法的身份卡，或者生物特征模板经国密算法保护、比对结果带签名，才构成有效的密码应用。

视频监控记录同样要求完整性保护------录像文件有没有做完整性校验，能不能证明"这段录像没被裁剪过"。这一条在实践中被忽略得最厉害，因为大家默认监控就是"看着的"，没想到它也是密评的举证对象。

3.2 网络和通信安全：改造了但没生效的重灾区

这一层的核心是国密 TLS 改造。政务云平台上，"做完了"和"生效了"完全是两件事：

套件顺序问题：服务端同时开启国密套件和国际套件，但没有设置优先级策略，实际协商结果由客户端决定，浏览器或老版本客户端一律回落到国际算法。
客户端未同步：服务端改完了，业务侧的调用方还是老的 SDK，连国密套件都不支持，协商必然失败或者回落。
证书链不完整：国密证书配了，中间 CA 证书没配全，部分客户端校验失败后降级。

要证明这一层真的生效，只能靠实测：从网络层抓取实际协商参数，而不是看服务端配置里写了哪些套件。

3.3 设备和计算安全：运维路径是重点

政务云上这一层的重点对象是运维路径------因为运维人员手里的权限，比普通业务用户大得多。

要求可以概括成三件事：运维人员身份真实性、运维操作的可追溯性、系统资源访问控制信息的完整性。

达标做法：运维登录必须双因素，且其中至少一种基于密码技术（比如智能密码钥匙的 SM2 挑战应答，而不仅仅是口令或短信）；运维操作全程经堡垒机，操作记录带签名保护，防止有人事后修改审计日志；系统关键配置文件的完整性有校验机制。

这里有一个常被忽视的细节：SSH 密钥登录算不算密码应用？ 严格说，SSH 密钥用的是国际通用算法体系，且密钥本身通常以文件形式无保护地存放在运维人员的工作机上------既不符合国密算法要求，也不满足密钥保护要求。政务云运维通道的合规做法是把运维凭据收进硬件介质（智能密码钥匙）或统一身份服务平台，由平台完成身份鉴别与凭据托管，运维人员手里不留可直接使用的私钥文件。

3.4 应用和数据安全：分数占比最高、也最容易做偏

这一层是密评和等保分歧最集中的地方，因为它同时涉及身份真实性、访问控制信息完整性、重要数据机密性与完整性、不可否认性四类要求。

最容易做偏的是"重要数据机密性"。政务云上常见的做法是只在应用层对少数几个字段做了加密，然后认为"应用和数据安全"这一层已经覆盖。问题在于：

加密的字段选得不对------把姓名做了加密，却把身份证号以明文存进了另一张关联表；
只加密新写入的数据，历史存量数据没做处理，一查历史记录全是明文；
加密结果无法查询------业务需要按身份证号精确查询，加密后查不到，于是又加了一个明文字段做索引，等于白做；
密钥散落在应用配置里，每个服务一份，没有统一纳管和轮换。

政务云平台的合理路线通常是分层落地：数据库存储层用透明加密覆盖整个数据文件，堵住"文件被拿走"的路径；对少数确实需要精确检索的高敏字段，采用保留格式加密或令牌化，兼顾加密与可用；对需要对外提供的共享数据，走脱敏发布通道；所有层级的密钥统一收口到密钥管理系统，根密钥由硬件密码模块保护。

3.5 不可否认性：政务场景的特殊要求

这一条值得单独说。政务业务里有大量"需要事后证明是谁在什么时候做了什么"的场景------审批、办件、证照签发、电子凭证出具。不可否认性的达标记据是数字签名，而不是日志。 系统日志可以被管理员修改，签名不行。

达标要求包括：签名私钥必须由签名人持有或由系统在可控条件下代为持有并严格隔离；签名私钥不可导出到硬件之外；签名结果可验证、验证依据（证书链、时间戳）可长期获取；关键点在于------私钥产生、使用、保管的全过程要能举证。政务系统里签出去的证照往往要保存十年以上，验签能力必须同样长寿。

四、四个方面管理要求：另一半容易被忽略的分数

技术层面做完，只拿了一半分。GB／T 39786-2021 的管理要求同样分四个方面：管理制度、人员管理、建设运行、应急处置。政务云平台在这部分失分往往比技术部分更集中，因为它不像技术措施那样有明确的产品对应物，需要落到制度和记录上。

4.1 管理制度：要有文件，更要有对应关系

不是"写一份密码管理制度"就算完成。密评看的是制度与实际的对应关系：制度里写了密钥轮换周期，就要能拿出轮换记录；制度里写了密钥管理员职责，就要能和实际的岗位分离情况对上。

制度文件至少要覆盖：密码应用的总体策略与责任分工、密钥全生命周期管理规程、密码设备运维规程、密码应用变更管理规程、密码事件报告流程。

4.2 人员管理：密钥管理员的岗位分离

核心是密钥管理员与业务操作员的岗位分离 ，以及密钥管理操作的双人双岗。

政务云平台上最常见的失分是：密钥管理系统只有一个人有账号，或者多个人共用一个管理账号。前者没有制衡，后者没有可追溯性------出了事查不出是谁操作的。达标做法是每个密钥管理操作人员一个独立账号，密钥的产生、销毁等关键操作要求双人在场并各自签名，操作记录不可删除。

同时要有人员离岗时的密钥交接与权限回收流程------离岗人员手里的密钥访问权限有没有及时回收，这一条在现场常被抽查。

4.3 建设运行：把"三同步"落到文档

建设运行的实质是把密码应用纳入系统建设流程，而不是系统建好之后补一层密码措施。

举证材料通常包括：密码应用方案及评审记录、密码应用与系统同步规划/建设/运行的证明材料、系统变更时的密码应用影响评估记录、密码资源的使用与运行状态监控记录。

4.4 应急处置：要有预案，更要有演练记录

密钥泄露、密码设备故障、证书过期导致业务中断------这三类事件的应急处置是密评的必查项。

要求的不是"有一份预案文档"，而是预案 + 演练记录 + 最近的处置记录 。密钥泄露的处置尤其要求明确：泄露判定标准是什么、谁有权启动应急、多久内完成密钥更换、历史数据怎么办、如何向上报告。政务云平台上签发的电子凭证有长期验证需求，签名私钥一旦泄露，不只是"换一把钥匙"的问题------所有用旧私钥签过的历史凭证都会同时失去可信度，这是应急处置预案里必须写清的最坏情况。

五、双达标最常见的八类失分项

把前面各节的失守点收拢，政务云平台双达标过程中反复出现的失分项集中在这八类。

#	失分项	典型症状	判据层面	整改方向
1	国密改造未实际生效	配置了国密套件但协商回落国际算法	网络和通信安全	实测协商参数，配置优先级，同步客户端
2	密钥无硬件保护	根密钥以文件形式存于应用服务器	设备和计算安全	根密钥入密码模块，不可导出
3	密钥管理员岗位未分离	一人掌握全部密钥操作权限	人员管理	独立账号 + 双人双岗 + 操作签名
4	加密覆盖不完整	新数据加密、历史存量明文	应用和数据安全	存量数据迁移方案 + 回溯加密
5	加密后不可用导致旁路	为查询另建明文字段	应用和数据安全	保留格式加密或令牌化
6	鉴别因素非密码技术	仅口令/短信却按双因素计分	应用和数据安全	引入基于密码技术的第二因素
7	运维凭据无保护	SSH 私钥明文存放于工作机	设备和计算安全	凭据收口至硬件介质或身份平台
8	文档与现场不一致	材料写"已加密"、现场验出明文	全层面	以实测反推材料，先测后写

第 8 类值得单独强调：它不改变技术事实，但会改变测评方对整套材料的信任度 。密评现场一旦发现材料里的某一项陈述与实测结果不符，后续每一项陈述都会被打上问号，举证成本成倍上升。宁可少写一条，不要写一条验不出来的。

六、把密码能力做成"可被测评的形式"

前面讲的是怎么达标，这一节讲一个更实际的问题：很多平台其实已经做了密码应用，只是做成了"无法被测评的形式"，等于白做。

密评的举证逻辑是"可验证的密码应用"。同一件事，做法不同，得分结果完全不同：

密钥管理：把密钥写在配置文件里，和把密钥托管在硬件密码模块中由密钥管理系统统一纳管、按层级派生、有轮换记录------前者不算有效密码应用，后者才构成可举证的密钥管理能力。
数据存储加密：应用层自己写一段加密函数，和用数据库透明加密在存储层统一加密------前者覆盖不全、密钥散落、历史数据难处理，后者边界清晰、可整体举证。
身份鉴别：口令加短信，和口令加基于 SM2 挑战应答的硬件令牌------前者的第二因素不是密码技术，后者是。

安当在这类政务云双达标项目里承担的角色，是把散落在各处的密码能力收拢成可被测评的形式 ：由硬件密码模块提供合规的密码运算与根密钥保护，让"算法合规"这一项有据可查；由密钥管理系统把密钥的产生、分发、轮换、销毁纳入统一管理并留痕，让密钥全生命周期的每一项要求都有记录可举证；数据库透明加密在存储层覆盖整个数据文件，不需要改造业务代码就能把"重要数据机密性"落地；统一身份认证平台把运维与业务两类身份鉴别路径统一收口，鉴别凭据不再散落在各台主机和工作机上；对政务数据共享场景，脱敏发布与加密存储配合，让"同一份数据对内可用、对外不可还原"成为可验证的边界。政务数据的长期验证需求也一并考虑------签名私钥的保护与历史签名数据的可验证性，是这套底座必须同时支撑的两件事。

回到密评的判据上，这些能力对应的是同一句话：让测评方能在现场把每一项要求复现一遍。能做到复现，分数就是稳的。

七、验收清单

双达标自查用。每一条都给出可验证的判据，能拿出证据才算过关。

#	验收项	达标判据
1	定级与备案	定级报告、公安备案证明齐备，系统边界说明含数据流向图
2	密评范围界定	范围按业务系统分层界定，支撑环境纳入但未失控扩大
3	密码资源清单	能提供"哪个应用调用哪种密码资源"的完整对应表
4	国密 TLS 生效	实测协商参数符合国密要求，非配置文件层面声明
5	存量数据加密	历史数据已回溯加密，抽查旧记录无明文
6	存储层加密覆盖	数据库停机直读数据文件，检索不到明文标记
7	高敏字段可用性	加密后仍支持业务所需查询，未另建明文字段旁路
8	根密钥硬件保护	根密钥由密码模块保护且不可导出，有配置证明
9	密钥分级与轮换	密钥分层清晰，轮换周期有设计依据与执行记录
10	密钥操作可追溯	密钥管理员独立账号，关键操作双人在场且记录带签名
11	鉴别因素合规	双因素中至少一种基于密码技术，可现场演示
12	运维凭据收口	运维通道凭据不在个人工作机留存明文私钥
13	日志完整性	关键操作日志有完整性保护，本地篡改可被发现
14	不可否认性	签名私钥保护合规，历史签名数据可长期验证
15	材料与现场一致	每项材料陈述可现场复现，无"写了验不出"的条目
16	变更触发机制	有变更---评估联动清单，重大变更后重新评估有记录
17	应急与演练	密钥泄露/设备故障/证书过期三类预案齐备且有演练记录
18	年度周期排期	等保年度测评、年度自查、年度密评均已排入运维计划

等保三级和密评双达标，难点从来不在"要不要买密码设备"，而在两套评估的判据不同，却要由同一套技术底座同时满足 。等保要的是措施完备、路径清晰；密评要的是算法合规、密钥可控、举证可复现。真正省事的做法，是在方案设计阶段就把两者合并成一张对齐表------同一条技术措施，同时回答等保的"有没有"和密评的"对不对"，而不是先按等保做完，再回来补密评的窟窿。补窟窿的代价，往往是整个密钥体系推倒重来。

你们的政务云平台现在处在哪个阶段------还没做过密评、密评提了整改但没动，还是已经完成一轮双达标正在准备年度复测？密评现场被追问最多的是密钥管理还是加密覆盖？评论区聊聊，一起看看还差哪一步。

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