信息系统密码应用测评要求

综述

GB/T 39786—2021为信息系统密码应用确立了“应当做什么”的规范性框架，而信息系统密码应用的实际合规程度则需要依赖一套系统化的验证机制加以判定。这一验证需求催生了《信息系统密码应用测评要求》（以下简称“《测评要求》”），对条款体系的操作化定义与证据化映射。

从学理层面审视，《测评要求》解决的是一个典型的规范可操作性问题：法律与国家标准中的规范命题“应实现通信实体双向身份鉴别”本身不具备自明性的验证路径，必须经由测评标准的转换，形成可由第三方重复检验的测评单元、核查方法与结果判定准则。本文旨在从方法论层面系统解析该文件的内在逻辑结构，揭示其在商用密码应用安全性评估（以下简称“密评”）实践中的核心枢纽地位。

---

一、测评标准的结构定位：对GB/T 39786的“操作化转译”

GB/T 39786定义了密码应用的目标状态与要求项，属于规范性标准；而《测评要求》定义了获取目标状态证据的方法与判定准则，属于程序性与方法性标准。构成“规范—验证”的二元闭环。

《测评要求》将GB/T 39786中的每一个要求项拆解为一个或多个测评单元。测评单元是测评活动的最小逻辑单位，其结构包含四个核心要素：

要素	功能定义	学术对应概念
测评指标	来源于GB/T 39786的具体条款	待验证的规范命题
测评对象	证据采集的实体指向（产品、文档、人员等）	证据源
测评实施	具体的技术核查步骤与方法	证据采集规程
结果判定	基于证据得出符合性结论的逻辑规则	证据评价准则

这种四元结构的设计学术价值在于：它将原本抽象的法律规范命题（“应当……”）转换为可由独立第三方重复执行的经验验证程序（“核查是否……”），从而在规范世界与经验世界之间建立了可通约的证据链。

二、要求强度的层级递进

“可—宜—应”的逻辑处理规则

GB/T 39786中三个情态动词——“可”“宜”“应”——在《测评要求》中得到了更为精细的程序化处理。这并非简单的语义重复，而是从测评方法论角度对规范条款赋予了差异化的证据采信规则。

“应”（Shall）条款的测评处理：密评人员应当无条件将此类条款纳入测评范围，按照第6章相应测评单元的要求逐项核查。若根据系统密码应用方案与评审意见，能够判定系统确实不存在与某条款相关的密码应用需求，方可标记为“不适用”，但需在评估报告中附具充分的论证说明。此规则体现了“应”条款作为合规基线的不可随意逾越性。

“宜”（Should）条款的测评处理：此处蕴含了《测评要求》最为精巧的程序设计。默认规则为“宜”条款纳入测评范围；但若系统已编制并通过评审的密码应用方案对该条款做出了明确的风险接受说明，则密评人员应进一步核实该说明所依据的风险控制措施在实际系统中是否满足前置条件。若前置条件成立，方可判定该条款为“不适用”；否则仍应纳入测评。这一机制的核心逻辑在于：放弃一项推荐性要求必须用经过论证的风险接受来置换，而非主观随意忽略。

“可”（May）条款的测评处理：由信息系统责任单位自主决定是否纳入测评范围。若不纳入，直接标记为“不适用”，无需附加风险论证。这体现了标准的最大弹性空间。

上述三级处理规则的设计，实质上是将规范文本中的情态动词转换为测评程序中的举证责任分配规则——“应”条款的举证责任在于“必须找到合规证据”，“宜”条款的举证责任转移给“欲放弃该条款的一方需提供风险论证”，而“可”条款无需举证。这种设计在法律方法论上具有严谨的程序正义特征。

三、测评实施的技术方法学

以核查为核心的证据采集范式

《测评要求》定义的核心测评方法可归纳为“核查”（examination），即测评人员对测评对象进行观察、查验与分析的过程。相较于渗透测试的主动攻击方法与漏洞扫描的自动化探测方法，核查是一种基于证据的系统性验证方法，其学术特征在于标准化、可重复性与可溯源性。

在技术层面的各测评单元中（第6.1至6.4节），每个测评实施条目均遵循固定的三段式结构：

1. 密码算法与密码技术合规性核查：追溯至第5.1节通用测评要求，核查所涉密码算法是否以国家标准或行业标准形式发布，或已取得国家密码管理部门的使用批准。此环节解决的是“用什么”的合法性问题。
2. 密钥管理安全性核查：追溯至第5.2节通用测评要求，核查密钥体系中除公钥外的密钥是否被非授权访问、使用、泄露、修改和替换；公钥是否被非授权修改和替换；密码产品与密码服务是否具备合规认证且达到相应安全等级（GB/T 37092一级/二级/三级）。此环节解决的是“密钥是否被妥善保护”的工程实现问题。
3. 特定密码功能实现机制核查：针对该测评单元所辖的具体保护对象或应用场景（如通信实体身份鉴别、日志完整性保护），核查具体密码技术机制（动态口令、MAC、数字签名、加密等）是否被正确部署且有效运行。此环节解决的是“功能是否生效”的有效性问题。

值得特别关注的是文件附录B与附录C的资料性指导。附录B给出了典型密码产品（智能密码钥匙、密码机、VPN产品、电子签章系统、动态口令系统、电子门禁系统、证书认证系统）的应用测评技术，明确了测评人员应当执行的具体操作及其预期结果。附录C则从密码功能维度给出测评实施指引。这两个附录的价值在于，它们将抽象的测评指标转化为了可操作的实验规程，使得测评结论可以经由不同测评人员的重复实验加以验证——这正是科学方法论中“可重复性”原则在信息安全评估领域的具体体现。

四、整体测评

单元测评完成之后，可能出现某些测评单元的结果判定为“不符合”或“部分符合”的情形。《测评要求》第7章引入的整体测评机制，是区分“形式合规”与“实质安全”的关键设计。

整体测评包含两个分析维度：

单元间测评：在同一安全层面内（如应用和数据安全层面），分析不同测评单元之间是否存在安全功能的相互弥补。例如，某系统在“重要数据传输完整性”单元未能完全实现保护机制，但通过数字签名机制同时提供了完整性与不可否认性双重保障，后者可能在一定程度上补偿了前者在审计追溯场景下的防护缺口。

层面间测评：在不同安全层面之间分析补偿效应。例如，网络层的通信信道加密可能补偿应用层在数据传输机密性实现方面的不足，前提是补偿机制的保护范围确实覆盖了被补偿对象的安全风险。

整体测评的逻辑基础是安全防护的整体性原理——密码安全不是各层面措施的机械加总，而是其协同效应的综合体现。但需要严格注意的是：补偿效应并非无边界适用。对于“应”条款的核心安全目标（如身份鉴别的真实性），若在任何一个层面出现严重缺失，通常难以通过其他层面的补偿来完全弥合，因为不同层面保护的是不同的攻击面。整体测评的科学性要求测评人员准确判定补偿措施的覆盖范围、保护强度与持续有效性是否与被补偿的原始要求等效。

五、风险分析与测评结论：从符合性判定到风险量级评估

《测评要求》第8章与第9章共同构成了从技术判定到管理决策的最后一环。经过整体测评修正后的单元测评结果中，仍然可能存在“不符合”或“部分符合”项。此时不能直接得出最终结论，而需要进入风险分析阶段。

风险分析的基本逻辑框架为：

\[Risk = f(Asset\_Value, Threat\_Likelihood, Vulnerability\_Severity, Impact\_Magnitude) \]

具体而言，测评人员针对每一项未满足的要求，分析其所对应的安全漏洞被特定威胁源利用的可能性，以及利用成功后对信息系统保密性、完整性、可用性造成的实际损害程度。在此基础上，综合判断该不符合项是否构成高风险。判定高风险的典型情形包括：未使用经国家密码管理部门核准的密码技术，且存在明确的可利用攻击路径；密码产品部署方式严重背离其安全运行前提条件，导致保护功能实质失效；密钥以明文形式存储于密码产品外部且可被非授权实体访问等。

最终测评结论分为三个等级：

结论	判定条件	学术含义
符合	无“不符合”或“部分符合”项；综合得分100分	系统完全满足对应等级的全部密码应用要求
基本符合	存在安全问题但均未达到高风险阈值；综合得分不低于阈值	系统存在可接受风险范围内的合规差距，需限期整改
不符合	存在任一高风险项，或综合得分低于阈值	系统存在不可接受的安全风险，须立即停止相关业务或实施紧急改造

这一结论体系的学术贡献在于将规范符合性与风险可接受性两个通常分立的概念整合为了一个综合评判框架。一个系统可能在形式上“部分符合”标准要求，但只要这些偏离不构成高风险，仍可获得“基本符合”的结论，从而为系统运营者提供了基于风险的整改优先级排序依据。

六、总结

《信息系统密码应用测评要求》的整体设计，方法论实质可以概括为：将GB/T 39786的规范命题转化为可由独立第三方验证的经验命题，再通过系统的风险分析将经验验证结果转化为管理决策依据。这一过程体现了信息安全评估领域从“清单式合规”向“证据驱动的安全治理”演进的深层趋势。

对于系统建设者而言，理解这一逻辑的价值在于：密码应用方案的设计不应止步于“满足条款数量”，而应当预判测评人员的核查路径——每一处密码技术的部署都应当经得起附录B和附录C所规定的方法的检验。对于测评人员而言，准确把握“可—宜—应”的程序化处理规则、整体测评的补偿逻辑以及风险量级的判定标准，是得出科学、公正、可追溯的测评结论的基本职业素养。

最终，无论是标准制定者、系统建设者还是测评执行者，共同面对的根本命题是一致的：在信息系统密码应用这一领域，如何确保规范要求、工程实现与验证方法三者之间的逻辑闭环不被打破。《测评要求》提供了一个目前国内最为系统化的解决方案，其设计理念与操作框架值得所有从事信息安全标准化与实践的专业人员深入研读与持续思考。