不少单位在做政务系统改造时，会遇到这样的现象：主体功能已经改完、联调也跑通了，评审或验收阶段却被指出密码应用方案不完整——某些业务环节该用密码的没有用，某些用了但密钥管理说不清楚。

问题通常不在技术上做不到，而在业务梳理阶段没有把密码需求一并盘进去。本文按「现象—原因—排查顺序—预防」的思路，讲清楚从哪里开始梳理。

为什么改到后期才发现密码环节缺项

常见原因是把密码应用当成一个技术模块，交给开发或运维在末尾补。但商用密码的使用要求分散在身份鉴别、数据传输、数据存储、行为留痕等多个业务动作里，脱离业务场景很难补。

另一个原因是需求调研阶段只梳理了功能清单，没有同步形成密码应用需求清单。等到方案评审时再回头找环节，往往牵动接口和数据结构，返工成本高。这类工作的组织方式可以参考我们的服务范围与交付流程，把密码需求并入调研阶段一并产出。

排查前先明确依据与范围

《中华人民共和国密码法》自2020年1月1日起施行，确立了商用密码的应用与管理框架。政务信息系统以及依法需要开展商用密码应用安全性评估的系统，通常要按相关规范编制密码应用方案并接受评估。

具体适用哪一档要求、是否必须做密评，建议以主管部门和项目批复文件为准，不要自行推断。排查开始前，先确认三件事：系统的定级情况、是否有明确的密评要求、以及本项目允许使用的密码产品与算法。范围不清就动手，容易做无用功。

建议按用户访问系统的完整链路来梳理，而不是按技术分层。链路顺序天然对应密码需求出现的位置，不容易漏。可以按下面这个顺序逐项排查：

每一项都落到具体业务功能和数据对象上，标注「已满足／需改造／待确认」三种状态，形成第一版清单。涉及多系统对接时，接口环节往往最容易出现口径不一致，这部分可参考政府与国企国产化改造案例中的做法。

第一轮梳理常见漏项集中在三处。一是接口层，业务系统与协同办公系统、财务或人事系统之间的数据交换，常被当作内部可信网络而忽略。国产 OA 的集成改造通常需要在组织与权限体系梳理阶段一并明确数据保护方式，不宜留到联调时再定。

二是历史数据。老系统里的存量数据是否需要加密、迁移过程中如何保持可用，往往没有在方案里写清楚。三是运维通道，远程维护、批量导入导出这类动作，容易被排除在业务链路之外。

另外要注意，国产化适配不只是换服务器和数据库。密码算法、密码设备的适配会直接影响应用层改造量，建议在 POC 阶段就验证一遍，而不是上线前才试。需要具体实施方案时，可以参考我们的软件定制开发与系统集成服务。

清单梳理出来后，不要直接变成开发任务列表，先按「必须改／建议改／暂不涉及」分级，并注明依据来源。每一条都写清楚：涉及的业务功能、涉及的数据、责任方、验收方式。

对于跨单位协同的条目，责任方要写清是我方、密码产品供应商还是对方系统承建方。常见做法是在合同中约定接口保护方式与联调责任，避免后期互相推诿。改造工作量与现有系统架构关系很大，具体取决于耦合程度和数据规模。

下一次项目启动会，可以拿这组问题逐条过一遍，答案空白的地方就是需要补的位置。

把这些问题答完，改造清单的骨架基本就有了，剩下的工作是按项目节奏排入调研、开发联调与验收各阶段。