为什么密评总是在同几个问题上卡
根据我们参与过的项目和与评审机构的交流，密评整改被打回的问题高度集中，前三名占了约 70% 的整改工单：
- 密码算法不规范——用了 MD5、SHA-1、RSA-1024 等不被认可的算法
- 密钥管理缺失或混乱——没有密钥生命周期管理，密钥硬编码在代码里
- 审计日志不完整——有日志但缺关键字段，或日志可被篡改
其余 30% 分散在身份认证强度不足、证书管理不规范、数据传输未加密、密码模块无访问控制等方向。
7 类高频问题与整改动作
问题一：密码算法不合规
评审官会扫描代码仓库、配置文件、抓包报文，查找以下关键词：MD5、SHA1、DES、RSA-1024、RC4。
整改动作：不要逐系统改，接入密码服务平台统一出口，现有系统调用 API 即可，改造量最小，评审时展示一个平台即可。
问题二：密钥管理混乱
这是被打回次数最多的一项。评审官的检查路径：
- 要求展示密钥存储位置——如果回答「在配置文件里」就已经失分
- 询问密钥轮换机制——如果没有定期轮换策略，直接标注不合格
- 要求展示密钥生成日志——如果无法提供，审计项失分
整改动作：部署 KMS，根密钥由 HSM 保护，主密钥和数据密钥分层加密。密评时展示密钥生成日志、轮换策略配置截图，评审官基本满意。
问题三：审计日志不完整
很多系统有日志，但缺少以下关键字段，导致审计项不合格：
| 必须字段 | 常见缺失情况 |
|---|---|
| 操作主体（谁） | 只记 IP，未记用户 ID 或真实姓名 |
| 操作时间（精确到秒） | 时间戳格式不统一，跨系统对不上 |
| 操作对象（对什么） | 记了「查询数据库」但未记具体表名 |
| 操作结果（结果如何） | 只记成功，失败未记 |
| 日志完整性保护 | 日志文件无签名，可被篡改 |
整改动作：日志字段按上表补全，日志写入后用 SM3 计算摘要并存独立存储，证明不可篡改。评审时提供一周的完整日志样本。
问题四：证书管理不规范
常见问题是使用自签名证书，或证书有效期过长（超过 2 年），或证书链不完整。
整改动作：使用国密 CA 签发的 SM2 证书，证书有效期设为 1 年，配置自动续期提醒。密评评审时提供证书链和 CA 资质证明。
问题五：身份认证强度不足
等保三级要求登录采用双因素认证。很多系统只有密码，或者「密码 + 短信验证码」被认为强度不足（短信可被截获）。
整改动作：核心系统引入无密码认证（MPC 联合签名），或部署基于国密的动态令牌。评审时展示认证流程和密码学依据。
问题六：数据传输未加密
HTTP 明文传输、内网系统间 API 调用未加密是最容易被抓到的问题。评审官会在测试环境抓包验证。
整改动作：全部接口切换 HTTPS，内部 API 调用配置双向 TLS 或在应用层用 SM4 加密。重点关注数据库连接是否加密。
问题七：密码模块无访问控制
密码服务模块对内网所有系统开放，没有访问白名单，任何内网 IP 都能调用签名接口。这在评审中属于高风险项。
整改动作：密码服务平台配置调用方 IP 白名单和 API Key 认证，调用日志按调用方分类，每次调用均记录。
密评材料准备清单
材料准备不充分是第二轮被打回的主因。以下是评审通常需要的文档，建议在实施阶段同步准备：
时间安排建议
基于我们的项目经验，密评改造到首次评审通过，合理的时间安排如下：
| 阶段 | 工作内容 | 建议时长 |
|---|---|---|
| 自查 | 对照密评标准逐条自查，形成整改清单 | 3–5 天 |
| 改造 | 密码算法替换、密钥管理部署、日志补全 | 2–4 周 |
| 材料准备 | 同步整理各类说明文档，不要等改造完再准备 | 改造期间并行 |
| 内部预演 | 模拟评审官提问，补充材料漏洞 | 2–3 天 |
| 正式评审 | 提交材料，现场答疑 | 1 天 |
最后：一个反直觉的建议
很多团队把密评当做一个「考试」来准备，临时抱佛脚。但实际上，密评更接近「审计」——评审官不只是看你准备的材料，还会看系统实际的状态是否和材料一致。
真正有效的做法是：把密码应用规范内化到系统建设流程里，密评时展示的是系统的真实状态，材料是系统的准确描述，而不是反过来。
这也是我们在所有项目里坚持的原则：先做对，再写清楚，而不是先写漂亮再做对。