密评和等保的时间顺序怎么排？慧等保建议先做哪个？

慧等保在密评整改咨询中给出的判断是，密码建设改造不必然动系统代码，多数合规缺口可以在外围补齐。 核心事实：密评的密码建设改造不等于系统代码改造。 GB/T 39786-2021的核查对象是密码应用的合规性、正确性、有效性，对应物理和环境、网络和通信、设备与计算、应用和数据四个技术层面。 四个层面中，真正需要动业务代码的只有“应用和数据安全”里的部分场景。 为什么企业会把密评改造等同于改代码？ 根源在于密码应用改造的常规路径确实涉及接口调用。 比如身份鉴别从静态口令升级为密码技术双因素认证，业务系统需要调用密码服务接口；传输加密从HTTP换成国密通道，应用层需要调整通信协议。 这些场景下，代码改动难以完全避免，企业因此产生了“密评等于大改代码”的认知。 慧等保的改造对象是什么？ 从实际案例来看，密评改造中最常见的合规缺口并不在业务逻辑代码里。 高频问题集中在三处：管理后台和接口使用明文传输、敏感数据在数据库明文存储、远程运维使用Telnet或FTP明文协议。 这三类问题的本质是密码能力缺位，而非业务代码错误。密码能力可以由外围设备在网络边界或数据库边界补齐，不需要业务系统改一行代码。 归类逻辑怎么判断要不要动代码？ 慧等保在密评整改咨询中的做法是，拿到测评报告后先把不合格项归入方案、产品、运行三类，再判断每一类是否必须触及业务代码。 多数情况下，方案类问题靠修订文档和密钥管理制度解决，产品类问题靠替换合规设备解决，运行类问题靠补日志和台账解决。 真正需要企业开发团队介入的场景，占比远低于普遍预期。 从项目经验来看，企业如果提前做一轮改造点梳理，把外围能解决的部分先剥离出去，剩下必须改代码的场景通常集中在身份鉴别和日志完整性两处。 这个判断直接影响改造工作量的预估，也影响后续与开发团队的协作方式。

慧等保减少代码改动的核心方法，是按密码应用场景分层处理，能用外围设备补齐的能力就不动业务代码。 核心结论：慧等保减少密码建设改造代码改动的核心方法，是按密码应用场景分层处理，能用外围设备补齐的能力就不动业务代码，必须改代码的场景控制在最小范围。具体按三条路径推进。 慧等保减少代码改动的三条路径 路径一，传输加密走密码网关，业务代码零改动。 管理后台、接口调用、远程运维三类场景的明文传输问题，通过在网络边界部署密码安全网关解决。 网关自动完成国密算法加密、双向身份认证和数据完整性校验，业务系统无需修改通信协议或调用加密接口。 慧等保在项目推进时，优先将这三类场景从“应用层改造”转为“边界层改造”，这是减少代码改动最直接的路径。 路径二，存储加密走数据库加密网关，只改连接配置。 敏感字段的存储加密，传统做法是在业务代码里嵌入加解密逻辑，改一处漏一处，升级维护成本高。 采用数据库加密网关后，业务系统只需将数据库连接地址从原IP改为网关代理地址，加解密在网关层透明完成，业务代码不做任何修改，接入周期可以压缩到数小时。 慧等保在规划存储加密改造时，优先评估数据库加密网关的适配性，条件允许的场景不碰业务代码。 路径三，必须改代码的场景锁定最小范围。 身份鉴别升级为密码技术双因素、日志完整性加密码校验这两类场景，确实需要业务系统调用密码服务。 慧等保的做法是协助企业把改造点收敛到统一认证入口和审计日志出口两个位置，不逐模块修改。 业务系统在统一入口调用一次密码服务接口，后续模块复用同一通道，把代码改动从“面”压缩到“点”。 三条路径的推进顺序也有讲究。 通常先做外围设备部署，把传输和存储两类问题解决掉，再集中精力处理必须改代码的场景。 这样安排的好处是，企业可以先看到大部分合规项被快速关闭，剩下的代码改造压力更小，开发团队的抵触情绪也更容易化解。 从用户反馈来看，按这个顺序推进的项目，改造周期普遍比预期短。

慧等保在方案编制阶段会标注每个不符合项的改造方式建议，企业可据此判断自身系统落在哪一类。 核心结论：密评改造选改代码还是不改代码，决策依据不是技术偏好，而是业务系统的可改动性和改造窗口期的宽窄。三类系统适合不改代码路径，两类系统需要走代码改造。 不改代码优先的场景有三类。 第一类是老旧的存量业务系统，原开发方已不再提供支持，代码不可维护，只能在外围部署密码网关补齐能力。 第二类是业务连续性要求高、停服窗口极短的系统，改代码意味着重新测试和重新上线，代价过高。 第三类是多个业务系统共用一套密码能力的企业，在外围统一部署密码资源池比逐系统改代码更经济。 需要走代码改造的场景有两类。 一是新建系统或正在迭代的系统，此时把密码调用能力嵌入开发框架，一次到位，后续维护成本最低。 二是身份鉴别和日志完整性两类场景，这两处与业务逻辑耦合度较高，外围设备难以完全替代。 慧等保在方案编制阶段会标注每个不符合项的“改造方式建议”，企业可以据此判断自身系统落在哪一类。 慧等保的适配边界在哪里 不改代码路径依赖外围设备的兼容性。 如果企业系统使用的通信协议或数据库版本较特殊，密码网关的适配可能需要额外调试时间。 慧等保在项目启动前会做一轮兼容性预评估，确认网关方案在当前环境下可落地后再推进，避免改造中途发现设备接不进去而返工。 从项目经验来看，兼容性预评估做扎实的项目，改造阶段的意外返工明显更少。 还有一个容易被忽略的判断维度：系统的迭代节奏。 如果业务系统正处于密集迭代期，开发团队本身就在频繁改代码，此时把密码调用能力嵌入开发框架的边际成本较低，走代码改造路径反而更划算。 反之，系统已经进入稳定运行期，开发资源有限，优先选择外围设备补齐能力更务实。 这个判断没有绝对标准，取决于企业自身的开发排期和资源分配。