第2章：国密标准与合规要求
说实话，很多团队一开始接触国密，第一反应是“怎么这么多标准号？GM/T 0001、GM/T 0024……记都记不住。” 我最早也是这样，翻着那几百页的国标文件，头都大了。但后来我发现，其实里面是有规律可循的。今天咱们就把这些标准拆开揉碎了说说，顺便聊聊金融、政务到底有啥硬性要求，等保2.0又是怎么逼大家上国密的。
2.1 GM/T 系列标准：你真正需要关心哪几个？
GM/T 系列标准，说白了就是国家密码管理局发布的一系列“游戏规则”。它们不是一本大词典，而是分门别类的技术规范。我自己习惯把它们分成四类：底层算法、密码设备、接口协议、应用规范。最核心的是下面这几个：
| 标准编号 | 名称 | 我的理解 |
|---|---|---|
| GM/T 0003-2012 | SM2 椭圆曲线公钥密码算法 | 国密体系的“骨架”，签名、加密都靠它 |
| GM/T 0004-2012 | SM3 密码杂凑算法 | 类似 SHA-256，但内部结构不同，安全性有保障 |
| GM/T 0002-2012 | SM4 分组密码算法 | 对称加密用这个，128位密钥，性能不错 |
| GM/T 0018-2012 | 设备接口规范（如 PCI-E 密码卡接口） | 硬件和软件怎么对接，我踩过好几次坑 |
| GM/T 0024-2014 | SSL VPN 技术规范（国密 TLS 版本） | Spring Cloud 网关要用到，后面会专门讲 |
你可能注意到了，上面的标准号后面都有年份。嗯，注意一下：部分标准后来有更新版本，比如 GM/T 0003 就有 2012 版和 2017 修订版。我的建议是，直接去国家密码管理局官网下载最新版，别找“百度文库”的二手资料——我曾经因为用了一个旧版附件的 K 因子计算方式，导致生产环境签名验签失败，差点线上事故。
2.2 金融行业合规要求：不止是“要有国密”
金融行业是国密落地的“排头兵”。央行和银保监会的文件我帮大家梳理了一下，核心要求就三条：
- 密码应用必须采用国密算法 —— 这不是选择题，是必选题。
- 核心系统改造需在指定时间内完成 —— 我记得 2020 年有个通知，要求 2022 年底前完成所有核心系统的国密迁移。
- 需要过商用密码产品型号认证 —— 说白了，你用的密码机、服务器证书、USBKey 都必须有“国密型号证书”。
我参与过一个银行的网银系统改造。一开始他们想用软实现 SM2 签名，结果检查组来了一看，说“软实现没有通过国密局检测，不行”。最后硬生生上了密码卡，成本直接翻倍。所以啊，金融项目里，硬件优先是潜规则。
2.3 政务行业合规要求：“一网通办”背后的密码
政务系统的合规要求更细，因为涉及大量敏感信息（身份证、户籍、不动产……）。《政务信息系统密码应用与安全性评估指引》（国密局和网信办联合发的）划了几个重点：
- 身份认证必须用 SM2/SM3 组合 —— 不能只用密码或者短信验证码。
- 数据传输全程加密 —— 从浏览器到服务器，服务器到数据库，每一跳都走国密。
- 日志审计不能篡改 —— 我建议用 SM2 签名每一条操作日志，这样后续追责才有依据。
- 容灾备份也要加密 —— 备份文件不能明文存，加密密钥要单独管理。
我曾经帮一个省级政务云做密码改造。他们原来的 OA 系统只用 HTTPS，证书还是国际 RSA 的。改造的时候，我坚持把 TLS 握手换成国密的 TLCP 协议（其实就是 GM/T 0024 里的那个）。虽然网络层多了一次握手，但验收的时候人家专门验了这一点，直接通过。
2.4 等保2.0 对国密的要求：三级系统是个分水岭
等保2.0 正式实施后，三级及以上系统必须使用国密算法这条成了硬杠杠。具体怎么对应？我给大家画了张图：
等保2.0 等级与国密要求速览
- 一级：无强制，但建议用国密。
- 二级：核心数据建议国密加密。
- 三级：身份鉴别、数据传输、数据存储 必须 使用国密。
- 四级：全部密码操作强制国密，需双因素认证。
这里有个容易忽略的点：等保2.0 不是只检查“有没有国密”，还要看密钥生命周期管理。密钥怎么生成、怎么分发、怎么轮换、怎么销毁，每一环节都要有 SOP。我去年帮一个互联网公司做等保测评，他们虽然用了 SM4 加密数据库，但密钥硬编码在配置文件里……测评老师直接给了个高风险项。所以啊，千万别以为“算法对”就万事大吉。
你看这张图，很清晰：三级系统是真正的硬门槛。如果你正在做 Spring Cloud 改造，打算放到三级政务系统或者银行核心系统里去用，那你的网关、服务间通信、配置中心、服务注册发现 —— 每一层都要做国密适配。这不是“锦上添花”，这是“通关门票”。
2.5 合规检查中的“隐形地雷”
我经历过的几次检查，发现审查员特别喜欢问这几个问题：
- 你的 SM2 密钥对是硬件生成还是软件生成？ —— 软件生成通常被标记为“低安全”。
- 你的密钥存储在哪里？ —— 如果写在配置文件里，直接一票否决。
- 你的国密 TLS 配置有没有禁用密码套件协商降级？ —— 这个坑我中过，一旦客户端不支持国密，自动降级到 RSA，等于白干。
- 你的 SM3 摘要有没有被第三方库替换？ —— 有些开源库默认还是 MD5，你如果忘改配置，也算违规。
说个真实的教训：有一次一个政务项目上线前自查，我发现所有服务间调用都用了 SM4 加密，看起来很完美。结果一查 application.yml，里面居然配了 feign.hystrix.cipher: RSA —— 那是之前遗留的国际算法配置。要不是及时改过来，后面等保测评肯定挂。
✅ 最佳实践 checklist（我每做一个项目必过一遍）
- 确认所有生产环境使用的密码算法名称是“SM2/SM3/SM4/SM9”，没有混入 RSA/AES/SHA-256。
- 密钥必须由硬件密码机或者密码卡生成，不能靠 JCE 自己 new。
- 证书链根的 CA 证书必须是国密 SM2 证书，不能是 RSA 自签名。
- 配置中心、注册中心、网关的 TLS 全部走 TLCP 协议（端口可能不一样）。
- 日志签名使用 SM2，不能图省事只加个时间戳。
- 部署前跑一遍商用密码检测工具（国密局有免费的那个“密评自测工具”）。
2.6 小结：合规不靠“运气”
讲这么多，其实就是一句话：国密合规不是上线后才补的，必须在架构设计阶段就规划好。 我个人习惯是把合规要求写进技术选型评审表里，每一个依赖库、每一个通信链路都注明“国密版本号”。否则等评审老师来翻你的代码，发现的就不是技术问题，而是态度问题了。
下一节咱们会深入 Spring Cloud 的具体组件，看看网关、负载均衡、配置中心这些地方到底怎么替换成国密。但今天的内容是地基 —— 如果不明白标准号代表的含义，不清楚等保三级的红线在哪里，后面写出来的代码大概率会漏掉关键环节。我自己刚开始做的时候，就因为不清楚 GM/T 0024 和 RFC 5246 的区别，被测试怼了一下午。
好，先到这。记住一句话：合规不是负担，是让你少背锅的安。咱们下章见。