密评改造中，应用层调用的改造幅度最大，通常占整体工作量的半数以上，是决定项目周期和成本的核心变量。原因很简单：密码改造不是买个设备就能交差，而是要让你业务系统里的每一处敏感数据处理，都换成符合国密标准的调用方式，这个"换"的过程,远比想象中复杂。
密评改造工作量由什么决定
同样是过密评，有的系统改两周就完事，有的系统改半年还没结束，差距不在密码设备本身,而在应用层的耦合程度。
代码侵入程度是首要因素
改造幅度和你的系统当初怎么用密码直接相关。
- 如果业务代码里到处散落着
crypto库调用，比如直接用openssl函数做加解密、签名验签,那每个调用点都要重写。 - 如果系统已经做了密码服务抽象层，业务方只调内部统一接口，那改造只需要动底层适配模块,上层业务基本不动。
我见过一个极端案例：某金融机构的支付网关，代码里直接openssl encrypt的调用点超过200处，密评改造耗时5个月，另一个做统一密码服务平台的公司，改造核心模块只用了一个月，因为业务方全部走KMS接口,只需把KMS背后的厂商换成支持国密的实现。
判断你处于哪个阵营，最快的方法是全局搜索：grep -r "RSA|AES|DES|SHA1" src/ --include=".java",统计一下命中数量和分布密度。
密码资源池的成熟度影响改造策略
很多单位在密评改造前，密码设备是"一机一用"的零散状态。
- 每台业务服务器上配一个软件密码模块
- 各业务线独立采购硬件加密机
- 证书、密钥分散存储在应用配置文件里
这种状态下做密评改造，等于先做资源整合再做应用改造，工作量翻倍，如果改造前就建了统一的密码资源池，提供标准接口，应用层改造就纯粹是接口替换,工作量集中在入参出参的格式转换上。
行业共识认为，先建密码基础设施再做应用接入，总成本能下降三到四成，逻辑很直白，基础设施统一了，应用侧改动才可能做减法；基础设施不统一,每个应用都得单独适配不同厂商的SDK。
业务逻辑复杂度决定改造深度
不同业务对密码的依赖程度差异很大。
- 仅做登录认证的系统，无非是改一下加解密算法和证书格式,改造深度较浅。
- 涉及电子签章、数据完整性的系统，要额外处理签名格式、时间戳、证书链校验,改造深度明显加深。
- 涉及跨境支付、多方对账的系统，还可能牵扯对方系统是否支持国密算法,没有商量的余地。
应用层调用改造到底改什么
密评改造不是简单地换一个算法库，涉及的东西相当零碎，把改造内容拆开看,主要集中在五个层面。
算法替换与参数适配
这是最直观的改造点，把RSA换成SM2，把AES换成SM4，把SHA-1换成SM3，表面上就是几个函数名的事，实际上参数长度、填充方式、密钥格式全部要跟着变,不是改一行代码就能跑通的。
- RSA密钥长度2048位起，SM2密钥长度固定256位，密钥存储和传输格式完全不同
- AES支持多种填充模式，SM4的填充规则也有差异，需要逐个对齐
- SHA-1输出20字节，SM3输出32字节，所有依赖摘要长度的数据结构都得改
证书与密钥管理改造
这一块往往被低估，很多系统的证书是内置在代码里或者写在配置文件中,密评要求密钥必须由硬件密码设备管理或使用加密机保护。
- 应用启动时主动从KMS或加密机拉取密钥，替代本地配置文件
- 双证书体系（签名证书+加密证书）的引入，要求应用能区分使用场景
- 证书过期轮换机制必须具备自动化能力，人工更换不符合密评合规要求
改造过程中，密钥托管逻辑的调整通常会占应用层改造总工时的三成以上，因为这部分牵涉到联调环境、生产环境的多轮验证。
通信协议国产化替换
如果应用之间用的是TLS通信，密评要求使用国密SSL协议或TLS 1.3国密套件，这部分改造牵动的面比较广不只是应用本身，负载均衡、网关、数据库连接池全都要跟着调。
- 后端服务之间的内部调用，需要确认中间件是否支持国密套件，比如Nginx、Tomcat、Spring Boot的版本兼容性
- 对外接口要同时兼容国密和传统国际算法，需要做双证书或协议降级策略
- 行内框架自研的RPC协议，如果内置了加密逻辑，改动量会特别大
数据格式和业务习惯的调整
算法换了，数据格式自然要换，SM2签名输出的ASN.1结构、SM4加密的Base64编码长度，都会和原有格式不一样，这会导致存储字段长度不够用、对接方解析失败等问题。
更麻烦的是，部分历史数据是用旧算法加解密存储的，这些存量数据要不要迁移？怎么迁移？是解密后重新加密还是双读双写？每一步都有决策成本。
改完之后要过的测试关
改代码只是开始，密评材料准备也很费劲，要有改造前后对比表、算法替换说明、测试报告,每一项都得有对应的证明材料。
统计下来，应用层改造的时间分配大体是六成改代码、两成做测试和数据迁移、两成整理测评材料。
密评改造周期评估与进度管理
改造周期是每个项目组都会反复追问的问题，给一个相对靠谱的评估方法：按应用系统数量和技术栈陈旧程度来估算,而不是按业务模块数量。
| 系统状况 | 预估改造周期 | 主要难点 |
|---|---|---|
| 新建系统，已预留国密适配层 | 2-4周 | 联调国密设备与测试反复验证 |
| 存量单体应用，代码结构清晰 | 6-10周 | 算法替换和存量数据迁移 |
| 存量微服务架构，调用链路复杂 | 3-6个月 | 各服务逐一改造，网关统一适配 |
| 老旧系统，依赖第三方闭源组件 | 6-12个月 | 第三方组件不支持国密，需替换或封装 |
是单人全职投入的估算，如果团队配置三五个人，周期可以压缩三分之一到一半，但要考虑业务版本迭代的窗口期,不是人越多越快。
密评改造方案落地顺序
有一个比较稳的落地路径，按这个顺序做,能少走不少弯路。
- 第一步，选一个非核心的外围系统做试点，跑通整个改造和测评流程,估算出真实的工作量和成本。
- 第二步，基于实际改造经验，制定核心系统的改造方案,重点评估架构层面有没有需要动的地方。
- 第三步，分批推进改造，每次上线前预留至少两轮完整的回归测试时间,避免业务故障。
- 第四步，同步整理测评材料，在完成全部改造后补充加密机配置截图、管理记录等合规性证明文档。
如何控制改造过程中的不变因素
让业务方放心很难，应用层改造对用户无感，但改动变数比较大，控制变数主要看三个点：接口出入参是否保持不变、数据库字段是否有扩展余量、原有容灾机制是否还适用，这三个点做好了,系统基本不会在改造过程中出现大范围故障。
密评改造报价是怎么算出来的
很多单位在立项前会问价格，但应用层改造部分没有统一的报价标准，密码设备采购价格相对固定,应用改造费用才是浮动最大的。
常见报价模式的优缺点
业内专家指出，了解报价构成,能帮你在预算评审时更准确地判断合理区间。
| 报价模式 | 适用场景 | 注意事项 |
|---|---|---|
| 按人天计价 | 改造范围不明确，边做边探索 | 明确人天费和预估总人天，防止后期追加成本 |
| 按系统数量打包 | 系统边界清晰，数量相对固定 | 要求写明每个系统的改造范围，避免"包含"和"不包含"扯皮 |
| 按等保级别报价 | 系统定级明确，密码方案清晰 | 适合预算匡算阶段使用，细化时还要回到人天核算 |
影响报价的核心变量
同样是密评改造，报价差距能有一倍以上，关键在于你是否已经具备密评需要的管理制度和运维流程，好多单位卡壳不在技术上，而是在于测评机构的整改意见下了好几轮,每一次整改都要重新跑一遍流程。
应用层的改造工作量，说到底取决于你的代码能有多大体面地"接住"国密算法，改之前多花点时间梳理资产清单,比谈价格时的讨价还价更有效。
密评改造常见问题解析
密评改造必须全量替换国际算法吗
主要看业务系统是否属于关键信息基础设施，以及是否已登记为等保三级及以上系统，这类系统要求优先使用密码应用安全性评估中的合规密码技术，内部各系统间的通信、数据存储、身份鉴别等均需要使用国密算法，外部接口涉及与合作方系统协同的，如果合作方尚无国密改造计划，可以采用国密算法与国际算法并存的过渡性方案,并限期完成替换。
密评改造用hsm还是vsm性价比高
密码设备形态的选择主要取决于系统的并发量和部署架构，并发量较高、对延迟敏感的核心交易系统建议优先考虑硬件密码机，单机性能更强，且GmSSL与加密机的适配方案已经相当成熟，云上部署的研发测试环境、灾备环境，用虚拟化密码模块能达到同样的国密合规标准，共享物理设备，成本可以压缩到硬件方案的数十分之一，需要明确的是，正式生产环境通常仍需硬件密码设备支撑,这是测评机构判定合规的重要参考条件。