密评指的是商用密码应用安全性评估，依据是《商用密码管理条例》与 GB/T 39786 等一系列标准，评估对象覆盖物理和环境、网络和通信、设备和计算、应用和数据几个层面。客户提出「系统要能过密评」，落到开发方身上的实际含义是：在设计阶段就把密码能力的调用位置留出来，别等系统上线后回头补。
很多项目卡住，不是算法不会调，而是架构里没有「密钥放在哪、由谁管、审计怎么留」的位置。下面按场景、候选路线、代价与边界、决策建议的顺序展开，供方案评审时参考。
先明确：密评改造真正要预留的能力有哪些
不管走哪条路线，架构上要留的改造点大体是同一组。建议在需求调研阶段就把它们写进方案，而不是留给开发阶段临场决定。
- 密钥与证书的生命周期管理：生成、分发、轮换、吊销、归档，谁负责、在哪个系统里做。
- 身份认证与传输通道：用户登录、系统间接口调用准备启用哪类密码技术。
- 重要数据的存储保护：哪些字段属于「重要数据」，加密与完整性保护在应用层还是数据层做。
- 调用入口的抽象层：把密码调用收拢到统一的接口封装，避免散落在业务代码里。
- 日志与审计：密码操作留痕，能支撑评估时取证。
这五项里，前四项影响架构，第五项影响运维。需要具体的拆解方式，可以参考我们的软件定制开发与系统集成服务中的交付做法。
路线一：应用层自建密码服务模块
在业务系统内部封装一套密码调用模块，由开发方自行对接密码机或软件密码模块，业务代码统一走这层封装。
- 优点：改造范围可控，业务团队自己说了算，联调周期短。
- 优点：与现有技术栈贴合，Java、.NET、PHP 后端都能做统一封装。
- 缺点：密钥管理的责任落在项目组身上，轮换与审计容易被忽略。
- 缺点：后续多个系统各做一套，口径不一致，评估时解释成本高。
这条路适合单系统、业务边界清楚的场景。若企业内部已有统一的安全基础设施，更稳妥的是复用而不是新建。
路线二：对接企业已有的密码服务平台
企业侧通常已有密码机、证书体系或统一身份平台，业务系统通过标准接口调用，自己不碰密钥。
- 优点：密钥与证书由专业团队管理，职责边界清晰。
- 优点：多个系统共用一套能力，评估材料口径统一。
- 缺点：依赖对接方的排期，接口规范需要提前确认。
- 缺点：能力范围受平台限制，特殊场景要单独评估。
系统集成类项目常见这种做法。如果客户是政府或国企，通常已有或正在建设统一平台，建议在方案阶段就问清楚：有没有现成的能力可调、调用规范由谁出。同类场景可参考政府与国企国产化改造案例。
路线三：结合信创环境整体规划密码能力
在国产化改造中同步考虑密码能力，硬件、操作系统、数据库与应用一并设计，避免分批改造反复返工。
- 优点：一次规划，减少后续二次改造。
- 优点：与国产软硬件环境的适配问题在早期暴露，联调相对从容。
- 缺点：前期投入大，需要多厂商配合，方案讨论周期长。
- 缺点：任一环节变动都可能牵动其他环节，变更管理要求高。
适合处于整体替换窗口期的单位。如果只是单个业务系统上线，用这条路容易把小问题做成大工程。
什么情况下不要选它
选型除了看优点，更要看边界。以下几种情况建议换路线，而不是勉强推进。
- 项目周期紧张时，不要选整体规划路线：多方联调不可控因素多，容易拖累上线。
- 客户已有统一密码平台时，不要再自建一套：重复建设既增加维护负担，也让评估口径分裂。
- 业务系统本身即将被替换时，不要做深度改造：改造成本难以摊销，建议先做最小可用预留。
- 只涉及表单填报、展示类功能时，不要过度设计：按实际数据敏感程度确定保护范围即可。
另外，凡涉及国产 OA 等第三方产品，二次开发通常受产品自身机制约束，不要在方案里承诺具体实现路径，先做 POC 验证再定。
架构阶段该做的三件事
- 在需求调研时输出密码应用方案初稿：明确保护对象、能力来源、责任分工，与客户的信息化负责人共同确认。
- 把密码调用做成一到两个抽象层：业务代码只调用封装，后期换实现不影响业务逻辑。这一点在技术实现细节里有过展开。
- 预留部署与运维位置：密码相关组件的部署方式、监控项、运维交接内容提前写进交付清单，云上部署场景尤其要写清楚。
三件事都不复杂，前提是别拖到开发中期。已经进入开发再补，通常要动接口和数据结构。
文字版对比清单
把上面的取舍压缩成三行，方便放进方案对比章节。
- 应用层自建密码模块 → 适合谁：单系统项目、技术栈统一的团队。主要代价：密钥与审计责任落在项目组，需自建运维规范。
- 对接企业密码平台 → 适合谁：已有统一安全基础设施的政企单位。主要代价：依赖对接方排期与接口规范，前期沟通成本高。
- 结合信创整体规划 → 适合谁：处于整体替换窗口期的单位。主要代价：多方协同、周期长、变更管理要求高。
需要把这套思路落到具体项目里，可以看我们的同类项目案例，或直接沟通交付流程。
常见问题
密评是不是上线之后做也可以？
可以做，但改造成本明显不同。密码调用位置、密钥管理责任、审计留痕都需要在架构里预留，上线后补往往要改接口和数据表结构。建议在需求调研与 POC 阶段就确定路线。
客户只说要过密评，没说具体范围，怎么办？
先把评估对象和范围问清楚：是单个系统还是整体，涉及哪些数据，是否已有密码平台。范围不同，预留的改造点也不同，这一步不能省。
改造点会影响系统性能吗？
加解密与签名验签会带来额外开销，具体影响取决于调用频次与部署方式，建议在 POC 阶段做一次压力验证，再决定哪些环节需要优化。
开发方需要交付哪些材料？
一般包括密码应用方案、接口封装说明、部署与运维文档，以及与客户安全团队的对接记录。具体清单建议在合同里列明，验收时逐项核对。
