企业官网建设流程全解析

1. 密评现场的一个缩影：应用层为什么总是挨打

先说个真实场景。前阵子陪朋友单位做密评整改，测评机构进场第三天，问题清单拉出来，扣分最狠的几乎全集中在“应用和数据安全”这一块：登录接口还在用明文口令传参、核心业务表的敏感字段直接裸奔在数据库里、日志里面POST请求体被完整记录下来、更夸张的是某支付回调接口连基本的签名校验都没有。负责开发的兄弟一脸委屈：“我们系统本来就有HTTPS，密码也做了MD5加密，怎么还不行？”

这个场景我见过太多次了。密评全称是商用密码应用安全性评估，它考的不是“你有没有用密码技术”，而是“你有没有用合规的密码技术，并且用在了该用的地方”。而应用层恰恰是整个评估体系里最容易暴露历史债、最容易出现认知偏差、也最难临时抱佛脚的一个层面。

从评分构成来看，密评按照《信息安全技术 信息系统密码应用基本要求》（GB/T 39786-2021）来执行，整体分为物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全、密钥管理安全等几个维度。其中“应用和数据安全”相关的测评项，不管在哪个级别里，占比都不低，而且扣分逻辑极其严格：你哪怕99%的接口都做好了，只要有一个核心接口不满足，这项就是不符合，就得整改。

这个“一票否决”式的逻辑，让应用层成了密评整改的重灾区。很多单位在等保时代习惯了“有密码就行”，到了密评时代才发现，“有密码”和“合规用密码”之间，差了整整一个改造周期。

这篇内容我不打算抄标准条款，那是测评机构培训干的事。我想从一个实际参与过密评整改项目的技术人的角度，把应用层数据安全防护这件事掰开揉碎讲清楚：密评到底在应用层盯哪些点，代码层面该怎么落地，实操中会遇到什么坑，以及怎么在测评进场前把该补的洞补完。

2. 密评的尺子：应用层数据安全到底量什么

2.1 四个必考维度，每一个都躲不过去

密评在应用和数据安全层面，核心考察四个方向。第一个是身份鉴别，业务系统在登录、交易、审批这类操作里，用户的身份鉴别过程有没有使用密码技术做支撑，口令有没有经过国密算法加密或哈希处理，而不是直接走明文或者MD5这种旧算法。第二个是传输机密性，应用层业务数据在客户端和服务端之间传输时，有没有采用密码技术保证机密性，这里的关键词是“应用层”，不是“网络层”，也就是光有TLS不够，重点看你业务数据本身是否经过了密码保护，尤其是在HTTPS卸载、网关转发的内网场景里，应用层数据往往是裸奔的。第三个是存储机密性，业务数据落盘时，敏感字段有没有加密存储，比如身份证号、手机号、银行卡号、病历、合同金额这些，测评人员会直接进数据库去看字段值是不是明文。第四个是完整性和抗抵赖性，系统里的重要数据、操作行为有没有做完整性保护，有没有数字签名和验签机制来防止事后抵赖。

这四个维度不是选择题，是必答题。测评机构现场会拿着测评表和检查清单，逐条核对你的系统设计文档、代码实现、配置记录、运行日志，甚至现场发请求抓包验证。应用层如果在这四个维度里任何一项失守，对应的测评项就是“不符合”，然后进入整改流程。

2.2 测评等级和指标要求：三级是最常见的坎

密评的等级划分和等保测评是挂钩的，三级系统做三级密评、四级系统做四级密评。实际工作中，三级密评是绝大多数企业要面对的。三级的要求非常具体，拿身份鉴别这一项来说，测评指标要求“采用密码技术对登录用户进行身份鉴别，保证用户身份的真实性”，听起来很抽象，但落到现场测评时，测评人员会检查你登录模块的代码，会在登录请求里抓包看口令字段的处理方式，会问你口令是用了什么算法什么模式做的哈希、盐值是什么、有没有加时间戳抗重放。

这类问题的答案如果只是“我们用了常见的哈希算法”，在密评的语境里基本就等于不合格。为什么？因为密评明确要求优先采用国密算法，也就是SM系列算法——SM2椭圆曲线公钥密码算法、SM3密码杂凑算法、SM4分组密码算法，以及SM9标识密码算法。SM系列算法是商用密码领域的国家行业标准，密评现场对算法合规性的检查是最硬性的指标，你用了不满足政策要求的算法，功能再强也没有用。

2.3 不仅是应用系统，数据安全管理制度也要过检

还有一个很多人容易忽略的点：密评不只看技术，还看管理和制度。数据安全管理的相关文件、密钥管理制度、密码产品清单、运维流程、应急预案，测评人员全都要看。也就是说，你光把代码改了还不够，得有配套的文档、记录、审批流程。很多团队在密评整改时只盯着技术开发，结果测评当天被问到“你的密钥多久更换一次”“密钥的备份存在哪里”“谁来审批密钥的导出操作”时，现场答不上来，一样扣分。

所以我会反复跟朋友强调一句：密评整改是“技术+制度+文档”三位一体的工程。后面我会把技术落地和制度配套拆开讲，先看代码。

3. 落地前的判断：哪些数据必须重点防护

3.1 识别敏感数据，画清应用边界

拿到一个业务系统，第一件事不是写代码，而是盘数据。哪些接口在传输过程中需要加密？哪些存储字段需要落盘加密？哪些操作需要签名和验签？你不可能把所有数据所有接口全部上密码技术，那样性能和开发成本都受不了，密评也不会这么要求。测评的核心思路是“该保护的必须保护”，所以你要先做一轮数据资产梳理。

具体方法不复杂：把数据库表列一遍，把接口清单导出来，然后按敏感程度分三档。第一档是核心敏感数据，包括口令、密钥、证件号、手机号、银行卡号、病历、合同金额、个人隐私信息、核心业务交易数据，这些必须在传输和存储上做强度最高的保护。第二档是重要业务数据，比如订单状态、审批记录、操作日志，重点做完整性保护，确保被篡改后能发现。第三档是普通数据，比如文章标题、商品名称这类公开信息，不需要额外叠加密码技术，但要求不主动泄露敏感字段。

数据分级画完之后，你会发现工作量和方向一下子清晰了。我配合做整改的一个电商系统，原始代码量很大，但真正需要改造的核心接口也就二十来个，核心字段也就是用户表、订单表、支付流水表里的那十几个列。把边界画清楚之后，改造范围就锁死了，不会出现“改着改着不知道改到哪儿去了”的失控感。

3.2 密码产品的选择：先看“型号”，再看“功能”

很多开发同学对密码设备、密码产品的了解不多，以为就是在代码里调用一个加密函数库。实际落地时会涉及密码机、签名验签服务器、密钥管理系统、安全网关等设备，这些产品都必须有商用密码产品认证证书，而且型号要和测评机构备案的清单一致。

选型的时候有两条路。一条是买硬件密码机和配套的密钥管理系统，由独立密码设备统一管理密钥，应用系统通过标准接口调用密码服务，这条路改造量小、安全性高、测评认可度最好，缺点是成本高，适合对密评要求比较严格的大型企业和关键信息基础设施。另一条是用软件密码模块，在应用系统内部集成合规的密码算法库，自己做密钥管理，这条路成本低、落地快，但对开发能力要求高，而且密钥管理的规范性问题在测评时容易被追问。

我自己的建议是：如果公司预算允许，优先选硬件密码机，哪怕是租用云上的密码机服务也行。因为密钥管理在密评里的检查力度非常大，硬件密码机天然具备密钥生成、存储、使用、销毁的完整管理能力，软件方案里你想把这些流程都做到合规，工作量绝对超出你最初的预期。

3.3 接口层面的改造范围：传输、存储、签名一个都别落

划完数据、选完产品，接下来就是把密码技术嵌入到具体的代码路径里。从接口视角看，一个典型的业务请求要经过这么几条链路：客户端发起请求，请求体里的敏感字段先加密或签名；服务端收到请求后先验签、后解密；业务处理过程中涉及数据库读写，敏感的字段列要做加解密转换；业务完成后写操作日志，日志里的敏感内容也要脱敏或加密；对外提供接口时，响应体里的敏感数据同样要加密返回。

这几条链路每一处都是一个测评点。实操时最容易漏掉的是日志环节。很多系统改造时把接口加解密做得很好，但日志组件会在拦截器里把请求参数全部打印出来，一条日志就把明文敏感数据全暴露了。测评人员排查日志文件发现大量明文手机号和身份证号，你的存储加密做得再到位，这一项也是不符合。

4. 从原理到代码：应用层密码改造实操

4.1 算法选型：什么时候用SM2、SM3、SM4

先把算法选型的逻辑理清。SM4是对称加密算法，适合大批量数据的加解密，比如接口请求体加密、字段级存储加密，速度快、性能开销小，密钥长度128位。SM3是哈希算法，输出256位摘要，适合做完整性校验和口令存储，比如登录口令哈希、接口参数防篡改校验。SM2是非对称加密算法，用于数字签名、密钥交换和少量数据的加密，比如接口签名、证书签发、密钥协商保护。SM9是标识密码算法，用手机号、邮箱这类身份标识直接作为公钥，适合身份标识固定、不需要部署证书的场景。

实际落地时，一个典型的登录场景是这样的：前端用SM2公钥加密用户口令，传给后端，后端用SM2私钥解密拿到口令，再用SM3加盐哈希后和数据库里存储的哈希值比对，校验通过后签发带SM2签名的会话令牌。这样一个流程把SM2、SM3都用上了，而且符合密评的身份鉴别和传输机密性要求。至于大批量业务数据落库，用SM4做字段加密是常规做法，密钥由密钥管理系统统一分发，加密后的密文以Base64或十六进制形式存入数据库列。

4.2 一个可以直接参考的接口签名落地方案

这里我给出一套我在实际项目里用过、也通过了测评现场验证的接口签名方案。核心思路是对关键业务接口做“参数加签、服务端验签”，防止数据在传输过程中被篡改，同时也能在抗抵赖测评项上得分。

签名流程不复杂：

1. 客户端把请求参数按key值做字典排序，拼成待签字符串，拼接时把所有参数名和值都纳入，同时加上时间戳字段和随机数nonce字段。
2. 使用SM2私钥对待签字符串做签名，签名结果放请求头的sign字段，时间戳和nonce也放进请求头。
3. 服务端收到请求后，先从请求头拿到时间戳，校验是否在允许的时间偏差范围内（一般设为5分钟，太短容易误伤网络慢的用户，太长容易遭受重放攻击）。
4. 服务端用客户端对应的SM2公钥对同样的参数字符串做验签，验签通过才继续处理业务，不通过直接返回签名校验失败。

这里要特别提醒，时间戳和nonce不能只是一个摆设。我看到过不少团队把签名做得很规范，但时间戳完全不校验，nonce也不做去重，结果签名保护形同虚设，攻击者只要把原请求原样重放就能完成重复下单、重复操作。正确的做法是服务端要维护一个最近N分钟内已使用nonce的集合，重复出现就直接拒绝。

4.3 存储加密：SM4字段级加密的常见设计

字段级加密落地时，我踩过不少坑，最大的坑就是“查询条件加密字段”。假设你的用户表里手机号做了SM4加密，但业务上经常要根据手机号精确查询用户，最直观的做法是查出来的每一行都解密再比对，这种方式在数据量小的时候还能接受，数据量一上来性能直接崩。

比较成熟的方案是引入密文索引列的概念。存数据时构造一个摘要索引列，专门存手机号的SM3哈希值，查询时先算出入参的哈希值，在索引列上做等值匹配，再把命中的记录解密还原。这个方案性能损耗很小，查询响应时间和明文状态差距不大，而且不会暴露手机号的任何明文信息。如果业务上有模糊查询的需求，比如搜手机号前三位，那就只能靠分片存储或者外部搜索组件来做，这类场景建议在方案评审阶段就明说，否则改造成本会失控。

4.4 密钥管理：密评里最容易翻车的环节

应用层密码改造做得好不好，密钥管理占了一半的权重。密评现场对密钥的检查几乎是“掘地三尺”：密钥是怎么生成的？存在哪里？谁能访问？多久换一次？备份在哪？使用中的密钥怎么防止泄露？销毁时有没有记录？

我在另一个项目里见过一个特别典型的反面案例。开发团队很努力，SM4字段加密都做完了，但密钥就是一个写死在代码里的常量字符串，所有环境用同一个密钥，也没做过轮换。测评人员翻代码看到硬编码密钥的那一刹那，整个存储加密的分数全没了——这是密评里非常严重的违规点。

正确的做法是：应用系统不能直接持有业务密钥，密钥统一由密钥管理系统生成和存储，应用运行时通过接口动态获取，可以缓存在内存里，但绝不能落盘。生产、测试、预发环境要使用不同的密钥，而且要建立密钥轮换机制，核心业务密钥建议至少每季度轮换一次，轮换过程要有审批记录和操作日志。应用系统如果接入了加密机，这部分合规性会轻松很多，因为加密机本身就内置了完整的密钥生命周期管理能力。

5. 改造前中后：密评项目的全流程节奏

5.1 摸底自查：先给系统做一次“密码体检”

真正启动密评整改，我建议不要上来就改代码，先做一次自查摸底。把现有的应用架构图、接口清单、数据库表结构说明书、已部署的安全设备清单全部拉出来，对照前面讲的那几个维度，把现状逐项标记成“已满足”“部分满足”“不满足”三档。这个过程可以自己团队做，也可以请外部评估机构做一次预检，后者会更省精力。

摸底的核心产出是一张差距清单。比如“登录接口：部分满足，口令虽做了哈希，但算法用的是国际通用哈希算法，需替换为SM3”“用户表手机号：不满足，明文存储”“XX业务回调接口：不满足，无签名机制”。这张差距清单就是后续所有改造工作的总纲领，每一行都要落实到具体的负责人和排期里。

5.2 分批改造：先接口、再存储、后补制度

改造的实施顺序我建议按照“先高风险、后低风险、制度技术同步推进”的节奏来。第一批优先处理身份鉴别和支付、签约、退款这类核心链路的接口签名和传输加密，这批改造直接影响密评的重大符合项，也是测评现场必查的项目。第二批处理数据库字段级加密和日志脱敏，这时候应用架构已经基本稳定，改造对业务的影响可预期。第三批就是完善密钥管理制度、密码产品配置文档、操作规范这些制度化内容，可以和开发并行推进。

不要试图一次性把所有系统全部改造完。密评整改的边界以测评报告上列的系统范围为准，在这个范围内的系统要彻底改，范围外的可以先不动。定了边界之后后面的人就不会无休止地铺摊子。

5.3 现场测评的几个动作：演示、问答、抓包、看文档

测评现场应用层这块，测评人员做得最多的动作就四个：看代码、抓报文、翻配置、查文档。看代码会重点关注密码算法引用、密钥变量的来源、是否硬编码；抓报文会实际发起请求，从明文流量里看敏感字段是不是暴露的；翻配置会看数据库连接配置、密码产品配置、服务部署拓扑；查文档会对应检查技术方案、密钥管理制度、密码设备清单这些。

针对这些动作，我建议提前准备一份应用层密码应用说明文档，把系统里用了哪些密码技术、服务于哪些业务场景、密钥怎么管理的，用表格化形式写清楚。这份文档既是测评人员的参考依据，也是内部运维的知识资产，后续新同事接手系统时照着文档就能快速理解设计意图。

6. 实战中的高频坑位与排查工具

6.1 字段加密后排序、统计全部失效

这是存储加密改造里出现率最高的问题，没有之一。某个字段一旦加密存储，数据库层面所有基于该字段的排序、分组、模糊匹配、区间统计全部失效。手机号加密后变成一长串密文，按密文排序没有任何业务意义。

处理思路有两个。第一，能不加密的字段尽量不加密，先做数据分级，普通字段不要为了凑“做了加密”而去加密。第二，必须要加密并且还需要参与业务计算的字段，提前设计好对应的替代方案，比如密文索引列解决精确匹配问题，哈希列解决去重问题，外部搜索服务解决模糊检索问题。这些问题一定要在设计评审阶段就拿出来讨论，等到代码写了一半再发现就晚了。

6.2 国密算法改造后的兼容性问题

把国际算法切换到SM系列算法，最大的问题不是代码写不出来，而是上下游系统的兼容性。对内的系统大家都好协调，对外的接口就麻烦了——你的合作方可能还没完成国密改造，你用SM2签名的回调通知对方验不了，对方的请求用国际算法签名我们这边也验不过。

处理这个问题的常见方案是“双算法并行兼容期”。在切换初期，支持对新请求用国密算法加签验签，同时也兼容旧的国际算法验签逻辑，两端都保留一套全量逻辑，等合作方完成改造后再下线旧逻辑。双算法并行虽然有额外的维护成本，但这是跨组织协同改造时性价比最高的办法。

6.3 日志系统是敏感数据的“泄洪口”

很多团队做了接口加密、做了存储加密，最后栽在日志手里。框架自带的访问日志、业务日志、调试日志，只要在某个环节把请求参数或响应结果给打印出来，敏感数据就等于从另一个出口流出去了。

整改的重点有三个。第一，全链路扫描日志打印点，凡是涉及敏感参数输出的，统一替换成脱敏工具类处理，手机号只显前三后四，身份证号只显前六后四。第二，日志脱敏不能只靠开发人员的自觉，要在日志工具层面做统一拦截和过滤，比如自定义logback的MessageConverter，对匹配脱敏规则的字段自动打码。第三，数据库慢查询日志、错误日志里也可能带上SQL参数明文，这些配置也要同步检查。

6.4 一个实用的排查清单：测评前过一遍

结合我自己的经验，整理了一份测评进场前应用层必查清单，团队可以照着逐项过：

• 登录接口口令是否只经过国密算法哈希，是否加了随机盐，是否引入了时间戳和随机数防重放；
• HTTPS之外的业务接口是否做了应用层加解密或签名验签；
• 数据库核心敏感列是否已加密存储，加密方案是否影响了查询和统计业务；
• 日志组件中是否存在敏感明文输出，脱敏规则是否统一且生效；
• 代码仓库中是否还有硬编码的密钥、口令、token；
• 密钥管理方案是否有文档说明，生产测试环境密钥是否隔离；
• 密码产品型号是否有商用密码认证证书，证书是否在有效期内；
• 技术方案文档、密钥管理制度、运维规范是否已归档。

每次整改临近尾声，我都会拿这份清单带着团队逐项打勾。打勾过程也是查漏补缺的过程，比测评现场才发现问题要从容得多。

7. 密评不是终点，应用层密码能力是一次基建

回看这几个项目的整改过程，我有一个很深的体会：密评整改本质上不是一次应试，而是一次应用层安全能力的基建补课。很多团队在做密评之前，对“加密”“签名”“密钥管理”的理解是碎片化的，有人觉得上了HTTPS就万事大吉，有人觉得MD5加盐就能交差，到了密评面前才发现，这些认知和技术栈需要系统性地重建。

每次整改完成后，回头看那二十来个核心接口的加解密改造、那十几张表的字段加密方案、那份几十页的密钥管理制度文档，它们最大的价值不是让测评通过，而是让这套系统之后所有新增的业务模块都有了默认的合规路径。新来的开发同学写代码时会习惯性地问一句“这个接口要不要签名”“这个字段要不要加密”，安全意识在这个过程里真正长在了团队身上。

如果你所在的团队正在准备密评，或者刚拿到一份应用层整改意见书，我的建议很简单：别焦虑，按数据分级、接口改造、存储加密、密钥管理、制度文档这个顺序往下推，每一步都留下设计和操作记录，密评通过只是时间问题。真正要重视的，是借这次机会把该补的短板补齐，把这套密码应用能力沉淀成团队自己的技术资产，以后再做新系统、新模块，就不用再从零开始了。