GB/T 39786-2021 标准学习和实践参考

一、标准

1.1 GB/T 39786

《中华人民共和国密码法》第二十七条明确提出：关键信息基础设施等系统应当使用商用密码进行保护，并开展商用密码应用安全性评估。法律确立了"必须做"的原则，但"做到什么程度""怎么做"需要标准来回答。

GB/T 39786就是回答这个问题的基础性通用标准。它与等保2.0标准体系（GB/T 22239）形成紧密配合——等保定级决定密码保障等级，密码标准给出具体技术要求。

1.2 五个等级的密码保障能力逐级增强

等级	核心特征	适用场景参考
第一级	最低要求，鼓励使用密码	一般办公系统、信息展示类网站
第二级	增加操作规程与培训	企业级内部业务系统
第三级	强化真实性与机密性，覆盖完整管理要求	绝大多数重要业务系统（政务、金融、物流等）
第四级	全面覆盖完整性、不可否认性，强制双向认证	极高保护需求系统（关键基础设施核心）
第五级	本标准不描述具体要求，超出第四级	国家重大战略领域

实践中，第三级是最常见的安全等级，对应等保三级系统的密码保障能力要求。本文后续技术分析均以第三级为基准展开。

1.3 标准的适用范围

从规划阶段的密码应用方案编制，到建设阶段的系统部署，再到运行阶段的密码应用安全性评估（密评），GB/T 39786贯穿信息系统密码应用的全生命周期。各行业可在此基础上制定行业细则，但不能低于本标准的最低要求。

二、标准架构

初看GB/T 39786目录时，很容易被物理和环境安全 网络和通信安全等章节标题误导，以为它是一个按系统层面划分的孤立要求清单。但当你把技术要求维度与管理要求维度交叉映射来看，会发现标准真正的设计意图是一套二维矩阵架构：

2.1 技术维度（四个密码安全功能）

密码功能维度	技术实现方式	在第三级中的覆盖强度
真实性	动态口令、MAC机制、数字签名机制	强（"应"覆盖登录、通信、接入全场景）
机密性	对称/非对称加密机制	强（"应"覆盖传输与存储重要数据）
完整性	MAC机制、数字签名机制	中（"宜"覆盖多数保护对象）
不可否认性	公钥密码数字签名机制	弱（"宜"仅应用于法律责任认定场景）

不可否认性需要依赖外部可信第三方（如CA证书体系）支撑，实现成本较高，标准将其设定为按需选用，而非强制基线。

2.2 技术实现层面（四个物理/逻辑层面）

标准选择四个层面作为密码能力的部署载体，背后有严密逻辑：物理（实体环境）→ 网络（数据传输）→ 设备（计算节点）→ 应用（业务流程），构成了从外到内、从底层到上层的完整纵深防御链。

2.3 管理维度（四个管理保障域）

密码安全"三分技术，七分管理"。标准的管理要求包含管理制度、人员管理、建设运行、应急处置四个维度，保障技术措施在人的层面得到持续有效执行。如果说技术要求是"锁"，管理要求就是"钥匙管理制度"——没有后者，前者形同虚设。

交叉矩阵总览：

密码功能 ↓ / 层面 →	物理和环境	网络和通信	设备和计算	应用和数据
真实性	宜	应	应	应
机密性	—	应	—	应
完整性	宜	宜	宜	宜
不可否认性	—	—	—	宜

不同层面侧重不同的密码功能，而非四个层面机械复制同一个要求。例如，网络和通信层面侧重"通信实体身份真实性"和"传输数据机密性"；应用和数据层面则承接"用户身份鉴别"与"业务数据安全"。

2.4 标准条款的三个动词："可""宜""应"

这是很多初学者容易忽略的精妙设计。标准中每个条款前都带有 "可""宜""应" 之一，代表不同的实现强度：

• 应（Shall） ：必须实现。若无合理例外，不满足即判定为不符合，属于合规刚需。
• 宜（Should） ：推荐实现。若未实现，须在密码应用方案中说明风险接受理由，并经密评机构认可后方可判定为"不适用"或"部分符合"。
• 可（May） ：可选实现。由系统责任单位自定是否纳入，不影响合规判定基线。

---

三、密钥生存周期管理

附录B（密钥生存周期管理）虽为资料性附录，却在密评中被视为核心评判依据。

3.1 密钥是密码系统的命脉

密码算法的安全性依赖于密钥的保密性。密钥被泄露或非授权替换，整个密码系统即告崩塌。密钥管理是密码应用安全性的单点依赖。

3.2 十个管理环节拆解

附录B覆盖了密钥的完整生命周期：

环节	核心安全要点	常见错误
产生	在符合GB/T 37092的密码产品内部产生；记录密钥元数据（种类、长度、拥有者、有效期）	在通用服务器上通过openssl生成密钥文件
分发	加密通道传输；双向身份认证；抗截取/篡改/假冒	通过明文邮件或即时通讯工具传递密钥
存储	密钥不以明文形式出现在密码产品外部；公钥需防护非授权篡改	将密钥以配置文件形式存放在应用服务器磁盘
使用	一钥一用；使用前授权；证书有效性验证；定期更换	同一个工作密钥既用于加密又用于签名
更新	超期或泄露风险时按策略更新；更新过程安全可控	长期不更新密钥
归档	仅用于解密历史信息；生成审计信息（归档密钥、时间）	归档密钥被用于当前业务加密
撤销	证书到期自动失效；可按需手动撤销	撤销后密钥仍被系统接受
备份	加密备份；安全等级与原密钥一致；生成审计信息	明文备份或备份在无访问控制的环境中
恢复	授权恢复/司法恢复；多人审批；生成审计信息	仅需一人即可恢复核心密钥
销毁	销毁过程不可逆；销毁操作记录留存	仅删除逻辑引用而未进行物理覆写

3.3 密钥分级是设计起点

在方案设计中，第一步应确定密钥分级体系（如根密钥→工作密钥→会话密钥三级），然后针对每一级密钥分别走通上述10个环节。这既是对标准附录B的直接落地，也是密评时"密钥管理安全性"单元的核心检查内容。

四、实战视角

基于GB/T 39786的密评工作流程

理解标准后，让我带你从一个密评人员的视角，快速过一遍实际测评流程，有助于理解标准条款如何在真实项目中落地：

1. 确定等级与范围：依据等保定级结果，确认系统适用的密码等级（通常为第三级），明确测评边界。
2. 文档审查：检查密码应用方案、密钥管理策略、应急响应预案等文档是否齐全且通过评审。这一步对应标准的第6章（管理制度）和第7章（建设运行）。
3. 通用测评：核查密码算法合规性（SM2/SM3/SM4等国密算法）、密码产品合规性（是否具备商用密码产品认证证书，等级是否达标）。对应第5章"通用测评要求"。
4. 技术测评：按物理→网络→设备→应用四个层面，逐一对照第6章相应要求进行核查。例如：抓取网络通信报文分析是否使用国密SSL/TLS套件；尝试拔出USBKey验证设备登录是否失败。
5. 管理测评：现场访谈关键岗位人员，确认职责分离、培训记录、应急预案演练记录等管理要求是否落实。
6. 整体测评：分析单元间和层面间是否存在相互弥补作用。例如，某"应"条款未满足时，是否有其他层面的控制措施可以等效补偿？
7. 风险分析判定结论：综合得分与高风险项情况，给出"符合""基本符合""不符合"三级结论。

流程核心逻辑是：以GB/T 39786的要求项为锚点，以技术验证和管理核查为手段，给出可量化的合规结论。

五、常见误区

1. "只有‘应’条款才需关注，‘宜’和‘可’可以忽略。"

密评中"宜"条款若无合理解释和方案佐证，默认纳入测评范围，可能拉低综合得分。弃用"宜"条款需要在密码应用方案中做明确的风险接受说明。

2. "标准仅适用于国家关键信息基础设施。"

错误。GB/T 39786的适用范围是所有采用密码技术的信息系统，无论公共机构还是企业。密评的强制性虽因行业而异，但标准本身是普适的。

3. "满足GB/T 39786即代表系统绝对安全。"

也不对。GB/T 39786是基线要求，而非绝对安全的保证。密码应用的正确性、有效性依赖于具体实施方案与密钥管理的落地质量，标准解决的是"该做哪些"的框架性要求，而"做得有多好"还需要结合具体密码产品的安全实现。

4. "管理要求不如技术要求重要。"

严重误解。从密评实践来看，多数系统的不符合项恰恰出现在管理制度与人员管理环节——制度文档缺失、操作规程未建立、岗位职责未分离、应急处置未演练。管理是技术得以持续有效运行的前提保障，两者同等重要。

六、总结

GB/T 39786的价值在于提供了一个结构化、可落地、可度量的密码应用框架。它将抽象的密码学概念转化为可检验的工程要求，为信息系统建设者提供了明确的基线，也为密评人员提供了统一的评判尺度。

理解这套标准时，建议抓住以下主线：

1. 四个维度：机密性、完整性、真实性、不可否认性（这是"保什么"）。
2. 四个层面：物理、网络、设备、应用（这是"在哪保"）。
3. 四个管理域：管理制度、人员管理、建设运行、应急处置（这是"如何管"）。
4. 密钥全生命周期：从产生到销毁十环节（这是"如何做"）。
5. 三个动词：应、宜、可（这是"做到什么程度"）。