3. 国密改造总体架构设计：改造范围界定、技术架构选型与路径规划

国密改造这件事，很多人一上来就问我：“老张，我们到底要改哪些系统？是不是全都要换成国密算法？”

说实话，这个问题问得特别好，但也特别容易踩坑。我见过不少项目，上来就拍脑袋说“全栈替换”，结果改到一半发现业务系统跑不起来了，最后只能回滚。嗯，今天我们就来聊聊这个核心问题——改造范围怎么定、技术架构怎么选、路径怎么规划。

3.1 改造范围界定：不是所有系统都要动

我个人习惯，第一步先做“资产盘点”。说白了，就是把你公司里所有用到密码技术的系统都列出来。别急着动手改，先搞清楚哪些系统在用密码、用的是什么密码、合规要求是什么。

我建议你按这个维度来梳理：

• 合规红线系统：涉及等保三级及以上、关键信息基础设施、金融核心交易等，必须改。
• 数据敏感系统：存储或传输个人敏感信息、重要业务数据的系统，优先改。
• 对外服务系统：面向公众的网站、APP、API网关，这些是监管检查的重点。
• 内部管理系统：OA、HR、财务等，如果只是内部使用且不涉及敏感数据，可以暂缓。

我曾经遇到一个客户，他们想把所有系统一次性改完，连内部考勤系统都要换国密。我拦住了——考勤系统用的是国际算法，数据也不敏感，改它干嘛？浪费钱还增加风险。最后我们只改了核心交易系统和对外接口，省了至少60%的工作量。

3.2 技术架构选型：全栈替换 vs 密码服务化

这是国密改造里最纠结的一个选择题。我见过两种极端：一种是“全栈替换派”，觉得不改底层就不彻底；另一种是“服务化派”，觉得加个密码中间件就完事了。其实，没有绝对的对错，关键看场景。

我们先看看这两种方案的对比：

对比维度	全栈替换	密码服务化
改造深度	替换底层密码库、硬件模块、协议栈	在应用层接入密码服务平台
改造成本	高（涉及大量代码重写、测试回归）	中低（只需改造接口调用方式）
性能损耗	低（硬件级加速）	中（网络调用开销）
合规风险	低（彻底合规）	中（需确保服务化方案通过密评）
运维复杂度	高（每个系统独立维护）	低（统一管理、集中运维）
适用场景	新建系统、核心交易系统、硬件设备	存量系统改造、多系统统一纳管

我个人更倾向于“混合策略”。说白了，就是核心系统用全栈替换，非核心系统用密码服务化。举个例子：

• 核心交易系统：全栈替换。直接换国密SSL、国密签名验签、国密加密存储。性能要求高，不能有额外网络开销。
• 周边业务系统：密码服务化。通过国密API网关统一接入，底层用密码机集群提供SM2/SM3/SM4能力。改造成本低，上线快。
• 老旧系统：如果实在改不动，可以考虑“密码代理”模式。在系统前面加一个国密代理层，透明替换国际算法。但注意，这种方式只能解决传输层问题，存储层还是得改。

下面这张图是我常用的架构选型决策流程，你可以参考：

3.3 改造路径规划：三步走策略

范围定了，技术选型也定了，接下来就是怎么落地的问题。我建议分三步走，别想一口吃成胖子。

第一步：试点先行（1-2个月）

选一个业务相对独立、影响面小的系统做试点。比如内部OA系统的登录认证模块。先跑通SM3密码哈希、SM2签名验签的流程。这个阶段的目标是：验证技术方案、积累改造经验、培养团队能力。

第二步：分批推广（3-6个月）

试点验证通过后，按系统的重要程度分批改造。我建议按这个优先级：

1. 第一批：对外服务系统（网站、APP、API网关）。这些是监管检查的重点，也是用户感知最强的。
2. 第二批：核心业务系统（交易、支付、账务）。这些系统数据敏感，合规要求高。
3. 第三批：内部管理系统（OA、HR、财务）。如果数据不敏感，可以暂缓或只做传输层改造。

第三步：全面覆盖与优化（6-12个月）

所有系统改造完成后，进入持续优化阶段。这个阶段主要做三件事：

• 性能调优：国密算法本身比国际算法慢一些，尤其是SM2签名验签。需要优化硬件选型、调整并发参数。
• 监控告警：建立国密链路的全链路监控，包括密码机状态、API调用成功率、响应时间等。
• 应急演练：定期做国密降级演练。万一国密链路出问题，能不能快速切回国际算法？这个预案一定要有。

最后，我想说一句：国密改造不是一锤子买卖，而是一个持续演进的过程。别追求一步到位，稳扎稳打才是正道。你想想看，密码技术本身也在不断演进，SM3/SM4/SM2之后，说不定哪天又出新算法了。所以，架构设计的时候就要考虑可扩展性，别把自己锁死在一个方案上。