一、国密改造背景：不是拍脑袋，是不得不走的路

各位好，我是老周。今天咱们聊国密改造的来龙去脉。嗯，说起这个背景，很多人第一反应是：又一道行政指令，苦了咱们干技术的。其实我入行那会儿也这么想，直到有一次项目中真出了安全事故……那才明白，政策这东西，是拿血泪堆出来的。

1.1 政策要求：自上而下的红线

先看几张关键的“红头文件”时间线。说白了，国家密码管理局、中国人民银行、银保监会这几年密集发文，核心就一句话：信息系统要逐步迁移到国密算法。

文件/标准	发布年份	核心要求
《密码法》	2019	明确密码分类管理，商用密码应用安全性评估成为硬性要求
GM/T 0028-2014	2014	密码模块安全要求，等同FIPS 140-2的国产化方案
《金融和重要领域密码应用指导意见》	2020	金融、政务、能源等关键领域要求三年内完成国密改造
等保2.0 三级及以上	2019	要求使用国密算法进行数据传输和存储加密

为什么会这样？因为政策不只是“建议”，而是 安全检查的否决项。我见过一个银行客户，等保测评时因为用了国际算法，直接判定为“不合规”，被监管点名，全行紧急启动项目——那场面，真叫一个手忙脚乱。

1.2 安全合规：不是换换算法那么简单

很多人以为国密改造就是把 SM2、SM3、SM4 替换掉 RSA、SHA-256、AES 就完事。嗯，我也曾这么天真过。

实际上，合规包含三个层次：

1. 算法合规——签名用 SM2，摘要用 SM3，对称加密用 SM4。但注意，SM4 分组密码的填充方式、初始向量长度都与 AES 不完全一致，不能无脑替换。
2. 协议合规——TLS 握手要支持国密套件，也就是 ECC-SM2-SM4-SM3。我记得最开始对接某网关时，握手包里的 Hello Extension 字段长度差一个字节就解析失败……
3. 密码设备合规——密钥必须存储在国密密码机或安全芯片里，不能直接写在配置文件。我在项目中遇到过客户用软实现把密钥写死在代码里，直接被审计写红灯。

所以合规不仅仅是换算法，还涉及：

• 密钥生命周期管理（生成、分发、轮换、销毁）
• 国密 SSL VPN/IPsec 组网
• 商用密码产品型号认证（型号证书能省很多事）

1.3 企业现状分析：改不动、难兼容、缺标准

搞过大型系统的人都知道，老旧系统的国密改造有多头疼。我大概总结了三种典型现状：

现状类型	痛点	典型场景
历史遗留系统	代码腐蚀严重，加密模块与业务逻辑耦合紧密	10年前的 C/S 架构收银系统，密文写在存储过程里
商业套件改编	底层加密由第三方 SDK 提供，替换成本高	某国外报表工具内部硬编码了 OpenSSL 的 EVP 接口
云原生/微服务	容器化部署下密码机调用延迟增加，集群密钥分发复杂	Kubernetes 中多个 Pod 共享一个硬件 HSM 时的并发问题

说白了，大厂的现状是：顶层想推，中层在算 ROI，底层骂娘。但监管的刀悬在脖子上，你不动，别人动了，出事儿你背锅。

1.4 本章知识结构一览

下面这张图把我上面讲的三个维度串在一起，你可以把它当作本章的思维导图。后面几章会从这张图出发，逐一深入每个细节。

1.5 小结：这章讲的东西有什么用？

你心里可能在想：背景嘛，知道了，然后呢？

嗯，这章是所有后续章节的 决策基础。为什么日志格式要单独适配？因为不同阶段、不同合规要求下，你加的字段不一样。比如：

• 政策要求里明确说“日志必须记录算法标识”，那你的日志就必须有一个 algorithm: SM4 字段。
• 安全合规强调“密钥不可明文出现”，所以日志里不能打印密钥值。
• 企业现状中“老系统重改难”，所以你得分版本、做兼容，日志格式是第一步。