密评改造对应用层调用的改造幅度，绝大多数系统都处于可接受的范围不是推倒业务代码重写，而是集中处理算法替换、接口参数适配、密钥管理和数据迁移四类改动。
改造幅度的大小，决定密评整改的工期和预算，摸清这个问题，要从代码库的调用分布和业务耦合度两个维度入手,下面拆开讲。
密评改造要改多少代码，先拿这两个维度衡量幅度
评估改造幅度，最怕拍脑袋，业内专家指出，应用层调用的改造量，主要取决于两个变量：一是代码里国密算法替换触及的调用点密度，二是这些调用与业务逻辑的耦合深度，两者都高，改动面就大；一高一低,多数改动还能控制在局部范围。
先拿代码库做一个盘底
动手评估前，先把项目代码翻一遍，老系统里通常散落着一批已经过时的密码算法调用，比如MD5、SHA-1、DES、RSA等，用代码搜索工具全局扫描,比靠回忆靠谱得多。
grep -r "MD5|SHA-1|DES|RSA" src/ --include=.java --include=.py --include=.js扫描结果出来后,按模块归类：
- 登录认证模块里的密码哈希、令牌签名调用
- 外部接口里的报文加解密、数字信封调用
- 数据存储层的敏感字段加密调用
- 文件处理模块的文件流加解密调用
把每一类调用点标记出来，再数一下这些点上游和下游各关联了几个业务函数，一个调用点背后挂着十几个业务功能的，改造幅度就明显偏大；孤立挂在工具类里的,改动范围相对可控。
按调用分布估算改造幅度
同样规模的系统，改造幅度的差异可能很悬殊，多数情况下,可以按调用点分布把系统分成三种典型状态：
- 集中型：密码调用集中在几个工具类或基础服务里，业务层没有散落调用，这种结构改造幅度最友好，替换底层实现后,上层业务几乎无感。
- 分散型：加解密逻辑散落在几十个业务文件里，每个文件都有独立的调用写法，这种需要逐文件调整，改完还要回归测试,工作量翻倍。
- 混合型：一部分集中在底层，另一部分散落在核心链路，改造幅度居中,但风险往往藏在散落的调用点里。
代码库的语言和框架也会影响幅度，Java系有成熟的国密SDK适配经验，Spring Boot项目的切面改造相对顺畅；PHP老项目如果自研加密函数较多,每个自定义函数的替换都要单独验证。
应用层调用改造范围，真实系统里到底动了什么
改造幅度听起来抽象，落到具体场景就清晰多了，以一个典型电商业务系统为例,密评改造对应用层调用的改动主要集中在三处。
登录流程的接口改动
老系统登录模块如果用RSA做密码传输加密，改造时要换成SM2，改动不只是替换算法类,还包括：
- 前端加密公钥的获取方式调整，从配置中心读取改为密钥服务下发
- 后端验签、解密逻辑改调国密SDK的对应接口
- 登录令牌的签名算法由JWT默认签名改为SM3或SM4的适配实现
- 会话管理里旧令牌的兼容，避免用户改造后立即被踢下线
这部分改动，通常影响登录链路的上百行代码，但对业务层影响较小,属于中等偏小幅度。
数据加解密层面的改动
业务数据里的手机号、身份证号、银行卡号，密评改造要求采用国密算法加密存储，老系统里基于AES的加密函数全部要替换，这个层面的改造幅度,往往比预期更大：
- 数据库里存量密文的密钥体系要迁移，不是改算法就行
- 加密字段的查询逻辑受影响，原来支持模糊查询的部分可能要退化为内存解密后匹配
- 数据同步、数据备份的链路要跟着调，不然后台任务解密失败
把数据加解密改造摊开看,它在整体应用改造量里占相当一部分比重。
文件流与报文传输的适配
涉及文件加解密、API报文加密的系统，改造点集中在流处理和序列化环节，国密SDK的加解密接口与老接口在输入输出格式上常有差异,需要写适配层。
改造幅度对比概览：
| 改造区域 | 主要改动内容 | 业务层感知 | 回归测试范围 |
|---|---|---|---|
| 登录认证 | 算法类替换+密钥获取调整 | 较小 | 单点登录链路 |
| 数据存储 | 加密函数替换+存量数据迁移 | 较大 | 所有读写接口 |
| 文件报文 | 流处理适配+报文格式调整 | 中等 | 文件上传下载链路 |
常见应用改造工作量，老系统与新建系统差多少
改造流程步骤对老系统和新建系统，完全是两种打法，新建系统可以在设计阶段就直接引入国密算法，改造工作量几乎为零；老系统的常见应用改造工作量,则要按拆解步骤逐项推进。
改造流程步骤分三步走
第一步，先做调用点清单，把代码库扫描结果整理成表格，标注每个调用点的算法类型、所在模块、调用深度和依赖接口。
第二步，确定改造顺序，优先改造对外交互的接口、系统间联调的报文，然后是数据存储层，最后是内部工具函数，对外接口牵扯第三方合作方，联调周期长,放在前面做可以尽早暴露问题。
第三步，分批上线切换，应用层调用改造完成后，不能一把梭直接全量上线，先拿一个非核心交易模块灰度跑几天，观察加解密耗时的变化、解密失败率、监控告警,确认稳定后再滚动替换其他模块。
老系统独有的改造负担
老系统在改造幅度上多出来的部分，主要是历史包袱，不同时期的代码风格不统一，同名工具类在不同包里有两套实现，配置文件里硬编码的密钥散落各处，这些隐性改动虽然单看很小,累积起来却会把工期拉长。
预算方面，密评改造费用中测试评估费只占一部分，应用层改动的人力成本才是大头，不同区域的密评机构对改造评价口径基本一致，但各地监管部门的审查节奏有差异，建议在备案时先确认本地要求的完成时限,再倒排改造计划。
改造完成后，怎么验收应用层改动是否到位
改造幅度的大小，最终要落在验收结果上，行不行,跑一遍自查就知道。
自查清单
- 扫描全量代码库，确认已经没有旧算法在业务链路上调用
- 抽查核心交易日志，确认国密加解密调用过程无异常报错
- 检查密钥管理流程，确认密钥轮换机制已生效，不再使用硬编码密钥
- 做一次全链路回归测试，覆盖改造涉及的全部核心接口
行业共识认为，应用层调用改造的验收标准，核心是看一遍业务主流程能否在国密环境下完整跑通,以及异常情况是否有降级处理方案。
警惕无效改造
有些项目为了应付检查，只把包名和类名换成国密SDK，核心逻辑还是旧算法，这叫无效改造，测评机构在协议层做抓包分析时，这类问题很容易暴露，改造时按调用链一层层追到底,才能避免返工。
密评改造对应用层调用的改造幅度相关问答
问：密评改造对应用层调用的改造幅度，跟等保级别有直接关系吗？
没有直接关系，等保级别决定的是密评的合规要求范围，比如哪些系统必须过密评、哪些算法必须替换，改造幅度的核心变量还是系统自身的调用结构，代码越分散改造面越大，等保三级以上系统涉及的数据量更大,数据迁移的工程量相应更重。
问：只换SDK不调业务代码，能减小改造幅度吗？
要看情况，如果代码库属于集中型，调用都收敛在底层工具类，只换SDK确实能覆盖大多数调用点，但如果业务代码里直接调用了旧算法的常量定义、密钥类型或报文格式，只换SDK不够,业务参数层也要跟着适配。
问：内部系统不对外联网，改造幅度是不是小很多？
内部系统的对外交互少，链路短，改造幅度确实更小，但要注意，内部系统之间的接口调用同样在密评审查范围内，尤其是涉及敏感数据传输的系统间接口,需要对报文加解密和密钥协商做改造。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/734586.html
