企业官网建设流程全解析

信创项目里，“密评”这两个字往往是排在最后、却最容易在验收环节把人卡住的一环。我见过太多团队，等保测评顺顺利利过了，应用也上线跑了半年，结果到了密评这一关，被一份差距分析报告打回来重做改造——不是技术多难，而是压根没搞清楚评的是什么、要留什么证据、哪些环节属于“做了但说不清等于没做”。这篇就围绕信创环境下的商用密码应用安全性评估（下称密评），把我这几年在项目里摸出来的东西完整摊开讲：它到底评什么、技术点在哪、改造怎么落地、现场怎么应对、哪些坑是重复踩的。不管你是第一次接触密评的开发，还是被临时推上来负责这块的项目经理，看完至少能画出一张自己的实施路线图，不至于拿着测评表一项一项瞎猜。

1. 先把“密评”这件事拆开看

1.1 三个容易混为一谈的概念

很多人一上来就把等保、密评、密码改造当成一回事，这是后面所有混乱的源头。它们的目标其实不一样：等保评的是“你这个系统整体安不安全”，覆盖面广，从机房到管理制度都算；密评只盯一件事——密码技术在这个系统里用得对不对、够不够、能不能自证。换句话说，等保是体检，密评是专项检查，而“密码应用改造”是你为了通过专项检查要去做的那些活儿。

理清这层关系，很多决策就顺了。比如等保三级要求“重要数据传输和存储要加密”，这句话在密评里会被翻译成非常具体的问题：你用的什么算法？密钥多长？密钥怎么产生、怎么分发、多久换一次？换的时候业务会不会中断？有没有操作日志？——同一件事，等保问的是“有没有”，密评问的是“怎么做的、能不能证明”。我在项目里最常说的一句话是：密评不是看你会不会用密码，是看你用密码这件事有没有留痕。

还有一层现实差别：等保测评机构来现场，主要是看配置、看日志、看制度文件；密评除了这些，还会真的去验算你的密码实现是否正确，比如抓一段密文看是不是标准算法输出、验证签名能不能对得上、检查随机数源是不是真随机。所以“文档写得漂亮、系统里没真做”这条路在密评面前走不通。

1.2 四个层面加四个特性，构成一张评分表

密评的技术要求可以粗暴理解成一张二维表：横向是物理和环境、网络和通信、设备和计算、应用和数据四个层面，纵向是机密性、完整性、真实性、不可否认性四个安全特性。每一个格子对应若干条具体要求，评估结论一般落在“符合、部分符合、不符合、不适用”这几档上，最后汇总成整体结论。你需要做的，是把每个格子在系统里的实现方式填满，并且每一格都有对应的证据链。

下面这张表是我自己项目里常用的对照工具，把四个层面最容易出问题的地方标出来：

我建议每个项目在启动阶段就把这张表打印出来，逐格填“现状—目标—差距—责任人”，填不满的格子就是后续工作量。别指望测评机构帮你找差距，他们的职责是判定，不是给你做咨询。

注意：表格里“不适用”这一档要慎用。有些团队习惯性把用不上的项标成不适用，但如果系统实际存在该场景，硬标不适用会被直接判不符合，反而更难解释。

1.3 信创环境带来的额外变量

普通环境做密评，难点在应用层；信创环境做密评，难点是全栈适配。处理器架构、操作系统、数据库、中间件、浏览器，每一层都可能影响密码能力的调用方式。举个很实际的例子：密码设备厂商提供的开发接口在不同指令集架构上的库文件不一样，如果你的应用是跨架构部署的，编译产物必须分开出包，不能一套二进制走天下。再比如国密SSL证书在部分客户端上的信任链预置方式不同，前端页面加载会直接失败，这类问题在测试环境不一定暴露，到了用户终端才炸。

还有一个常被忽略的点：信创环境下不少组件的默认配置里并不启用国密算法套件，需要显式开启。数据库连接池、消息队列、缓存客户端，这些中间件各自有各自的加密开关，漏一个就是一个扣分点。我的做法是建一张“组件—加密开关—验证方法”的清单，每接一个新组件就往里加一行，改完立刻验证，别攒到最后统一联调。

2. 技术细节逐项过：真正决定过不过的地方

2.1 算法选型：别在起跑线上丢分

商用密码算法这套体系里，常用的就那么几个：用于非对称运算的SM2、用于哈希的SM3、用于对称加密的SM4，再加上SM9这类标识密码算法。选型上没什么可纠结的——只要场景能用，优先用这几个，别自作聪明上国际算法再套一层壳，那在评估里属于“未采用标准算法”，直接不符合。

有一点需要说清楚：SM2的256位密钥，安全强度大致对标3072位RSA，不是对标2048位。这个换算关系在做安全设计说明的时候用得上，很多方案文档写错这一句，评审时会被追问。SM3输出256位摘要，SM4分组长度和密钥长度都是128位，这些基础参数写进方案里，比写一堆形容词管用。

实际选型时的判断顺序，我一般是这么走的：先看数据是“存”还是“传”。传的数据，优先上协议层的国密SSL/TLS，因为它一次性解决身份真实性、机密性、完整性三件事，工作量最小；存的数据，看敏感程度，普通敏感字段用SM4做字段级加密，需要防篡改的加SM3做完整性校验，需要防抵赖的（比如电子合同、审批意见）才上SM2签名。别一上来就全字段加密，性能扛不住，运维也痛苦，而且密评并不要求你把所有数据都加密，只要求“重要数据”。

还有一个容易踩的细节：算法套件的组合要一致。我见过一个系统，通道用了国密SSL，握手用的SM2证书，但应用层做数据签名时调的是另一套接口，结果签名值和通道里的证书对不上，不可否认性这条直接被质疑。选型定下来之后，最好画一张“哪个环节用哪个算法、密钥从哪来”的图，贴在设计文档第一页。

2.2 密钥管理：最容易“说不清”的部分

如果说密评有一个必考大题，那一定是密钥全生命周期管理。生成、存储、分发、使用、更新、归档、销毁，七个环节，每一个都要说清楚“谁做的、用什么做的、记录在哪”。这一块的技术含量不在写代码，在于把流程做成可验证的事实。

我通常建议采用三层密钥体系：主密钥（根密钥）、密钥加密密钥、数据密钥。主密钥放密码设备里，不出设备；密钥加密密钥用来加密数据密钥，在系统内传输；数据密钥真正用来加业务数据，用完即弃或者定期轮换。这样做的好处是，即使某一层泄露，影响范围可控，而且在评估时层次清晰，容易解释。

轮换周期是个常被问的问题，没有统一答案，我的经验是：主密钥跟着设备生命周期走，一般三到五年；密钥加密密钥按年轮换；数据密钥按数据敏感度和数据量定，高频业务可以按月甚至按周。关键是轮换过程要能不停机，做法是双密钥并存一段时间，新数据用新密钥，老数据用老密钥解，解密后按需重加密。这个“双密钥期”的设计要写进方案，不然评审会问你“换密钥的时候老数据怎么办”，答不上来就是部分符合。

提示：密钥备份和恢复是最容易漏的一环。很多团队做了备份，但没做过恢复演练，也没有恢复操作的审批记录。这在评估里属于“有备份无验证”，往往判部分符合。恢复演练至少做一次，留记录。

销毁环节同样别糊弄。密钥销毁要有操作人、审批人、销毁方式、销毁时间，如果密钥在硬件设备里，要有设备返回的销毁成功回执。软件层面“把变量置空”不算销毁，这一点在文档里别写得太随意，写错了反而是自己给自己挖坑。

2.3 身份鉴别与传输加密：两个高扣分项

身份鉴别这块，问题集中在“单因素”上。用户名加口令属于单因素，很多系统觉得加了个图形验证码就算双因素了，这是误解。密评语境下的双因素，通常要求“你知道的”加“你拥有的”，比如口令加数字证书、口令加动态令牌、口令加生物特征。改造时最省事的路径是给管理类用户上数字证书，普通用户看系统定位，如果没有硬性要求，至少把管理通道做成证书鉴别。

传输加密的坑更隐蔽。外部访问上了国密通道，内部服务之间还是明文HTTP，这在“网络和通信”层面会被认定为覆盖不全。我一般的处理是：对外用国密SSL/TLS终结在网关，对内如果服务在同一信任域内，可以用加密隧道或者应用层加密补偿，但一定要在方案里说明“为什么这样划分信任边界”，把逻辑讲圆。评估不是不允许你有取舍，是不允许你取舍了还不解释。

2.4 性能这件事，得用数字说话

密评改造最常见的反弹来自业务方：“加了密码运算，接口慢了怎么办？”这个问题不能靠拍胸脯回答，得算。

举个我实际算过的例子：某业务系统峰值约3000笔/秒，每笔交易需要一次签名加一次验签。纯软件实现下，单核SM2签名性能大致在几千次/秒量级，具体取决于实现和CPU；如果换成带密码运算能力的硬件卡，单卡签名性能可以到万次/秒以上。按峰值3000笔/秒、每笔2次运算算，需要6000次/秒的运算能力，配置一张卡留一倍余量就够了。

这里的冗余系数我一般取2，因为要考虑单点故障和业务增长。纯软件实现的场景要特别小心，尤其在信创平台上，如果没有对应的指令级加速，SM4的吞吐可能只有带硬件加速时的几分之一，压测必须做，别拿x86测试环境的数字去推生产环境。

3. 实操路线：从差距分析到现场测评

3.1 差距分析怎么做出能用的结论

差距分析不是把标准条文抄一遍然后打个勾，那样做出来的东西自己都不敢信。我的做法是“三列法”：第一列写标准要求，第二列写系统现状（要有具体到组件和配置的证据），第三列写差距和整改建议。第二列是关键，必须能落到“哪台机器、哪个配置文件、哪一行”。写不出这一列的，说明你还没摸清楚系统，先去做资产梳理。

资产梳理要梳理到什么程度？至少要到“哪些组件之间有数据流动、流的是什么数据、有没有敏感数据”。我一般会画一张数据流图，节点是组件，边是调用关系，边上标注数据类型。这张图画完，四个层面的评估范围基本就自动浮出来了，也能立刻看出哪些链路是明文。这个图还有个额外好处：改造排期的时候，你可以按链路一条一条切，不用一次性全改。

差距分析出结论后，要排优先级。我的排序原则是：先补“有没有”，再补“好不好”。算法没用对的，先换算法；用了但密钥管理说不清的，再补流程。原因很现实——前者是硬伤，直接不符合；后者往往是部分符合，还有解释空间，但也不能拖到最后。

3.2 典型场景的改造要点

登录鉴别场景。改造思路是把口令认证升级为“口令加证书”的双因素。技术实现上有两条路：一是在应用层集成证书认证模块，用户插证书登录；二是在网关层做双向认证，应用层拿到网关透传的身份标识。第二条路对应用侵入小，但要确认网关透传的身份信息不被伪造，需要加签名保护。我倾向第二条，改造成本低，风险集中在一处好控制。

数据存储场景。字段级加密的难点在查询。加密后的字段没法做等值查询和模糊查询。常见的解法是：需要精确查询的字段，额外存一列SM3哈希值用于比对；需要模糊查询的字段，要么放弃加密，要么改成索引化的分词方案。这个取舍必须提前和业务方谈，别改完了才发现列表页搜不出来。

日志完整性场景。运维日志、审计日志要防篡改，做法是每条日志写完后计算SM3摘要，摘要链式串联（后一条包含前一条的摘要），定期用SM2对链头签名。这样任何一条被改动，链就断了。实现上要注意日志写入的性能，异步计算摘要、批量签名，别把主业务拖慢。

不可否认场景。涉及电子合同、审批意见这类需要“事后不能赖账”的操作，要用SM2签名，并且签名值要和时间戳绑定。时间戳的获取方式要在方案里写清楚，是内部时间服务还是第三方可信时间源，两者在评估里的说服力不一样。

3.3 现场测评怎么配合

现场测评阶段，测评方一般会做几件事：访谈、查看配置、验证功能、抽查记录。你要做的准备，本质上是把前面所有工作整理成别人能快速看懂的材料。

材料清单我一般准备这几样：密码应用方案（含算法选型、密钥管理设计）、系统拓扑与数据流图、密钥管理操作规程、密钥生命周期记录（生成、轮换、销毁）、密码设备清单与配置截图、关键功能的验证录屏或截图、整改记录。录屏这个东西特别有用，因为现场演示容易受环境影响，录屏可以随时回放，而且能证明操作步骤的完整性。

访谈环节要提前定人。问算法的找开发负责人，问密钥管理的找运维负责人，问制度的找安全负责人。最怕的是一问三不知，或者几个人说法不一致。我通常会在测评前组织一次内部预演，把可能被问到的问题过一遍，尤其是“密钥存在哪、谁能取、取用有没有审批”这类问题，答案必须统一。

4. 高频问题与排查技巧实录

4.1 扣分点速查表

这张表是我从多个项目里攒出来的，按出现频率排序，做自查的时候可以直接对着过：

4.2 几个真实踩过的坑

第一个坑是“改造做了但没生效”。某项目在应用里集成了加密模块，配置也开了，但压测时抓包发现数据还是明文。查了半天，是中间件里有个连接池自己做了二次封装，把加密后的数据又解了一次。这类问题的排查方法很笨但有效：在链路的每个节点抓一次包，看数据在哪一段变成明文，问题就定位了。我现在的习惯是改造完必须做端到端抓包验证，不看日志，看真实流量。

第二个坑是“证书链不全”。国密SSL改造后，部分终端访问报证书错误，服务端日志一切正常。原因是服务端只配了站点证书，没配完整的中间证书链，部分客户端内置的根证书不同，链验证失败。解决办法是把完整证书链配齐，并且在方案里写明客户端需要预置哪些根证书。信创环境下终端类型多，这个问题出现的概率比想象中高。

第三个坑是“密钥轮换把老数据锁死了”。有个系统做密钥轮换时，直接替换了数据密钥，结果历史数据全部解不开。事后复盘，是轮换方案里没设计双密钥共存期。这件事之后我定了个规矩：任何密钥轮换方案，必须先在测试环境用真实历史数据跑一遍解密验证，通过了才允许上生产。

第四个坑是“方案和实现两张皮”。方案文档写得非常规范，三层密钥体系、轮换周期、审批流程一应俱全，但实际代码里根本没有实现密钥管理服务，全是硬编码。这种情况在评估里属于严重问题，因为方案是自证的依据，方案和实现对不上，比没有方案更麻烦。现在的做法是方案定稿后立刻做一次“方案—代码”对照，每一项设计要求都要指到具体的类或配置文件。

提示：给团队一个自查习惯，每次版本发布前问三个问题——这次改动有没有新增敏感数据链路？新增的链路加密了吗？密钥从哪来？三个问题答不上来就别发版。

4.3 关于评估结论的预期管理

不少人对结论有误解，以为必须全部“符合”才行。实际上评估结论通常分符合、基本符合、不符合几档，基本符合也是有条件的通过，但会附带整改要求。真正要避免的是“不符合”，那意味着要重新走一轮。

影响结论的往往不是技术难度最高的那几项，而是最基础的几项，比如密钥管理说不清、覆盖范围不全。这些属于“地基”问题，一旦出现，其他项做得再好也拉不回来。所以资源分配上，我建议把七成精力放在覆盖面完整和密钥管理这两块，剩下三成再去打磨细节。

5. 工期与成本的现实估算

最后说点实际的。密评改造的工期，跟系统规模强相关，但有个大致区间可以参考。单体的业务系统，如果原来没有任何密码应用基础，从差距分析到改造完成再到测评通过，通常需要两到四个月；如果是多系统联动的场景，涉及统一身份、统一密钥管理，周期会拉长到半年以上。其中差距分析占两到三周，改造实现占大头，测评和整改各占两到三周。

成本构成上，硬件密码设备是一次性投入，密钥管理服务如果是自建，要考虑开发和运维成本，如果采购成熟组件，按节点或按调用量计费，需要估算业务量。还有一个容易漏的成本是人力——密码改造涉及应用开发、运维、安全多方配合，如果团队没有相关经验，前期的学习成本不低，这部分往往比硬件更贵。

我的建议是：如果项目处于设计阶段，就把密码应用方案一起做掉，方案评估通过后再开发，这比系统建完再改省一半以上的力气。改造阶段最怕的是边改边加需求，密码相关的改动牵一发动全身，需求不稳定就别急着动手。

真到了实施阶段，先切一条非核心链路做试点，跑通端到端再铺开。试点链路要选有代表性的，最好同时覆盖传输加密和存储加密，这样能把大部分问题提前暴露。试点跑通后，剩下的就是复制粘贴加验证，节奏会快很多。

这套流程我在几个项目里反复用过，最深的体会是：密评考的从来不是密码学知识，是把一件事做完整、留下痕迹的能力。算法就那几个，接口就那几套，真正拉开差距的是你有没有在动手之前把范围划清楚、把证据想明白。