很多团队做密评时总觉得 “流程复杂、标准难抓”，但多数不通过的情况，本质是踩了 “基础合规漏洞”—— 比如用错算法、密钥管理不当、测试数据不脱敏。下面结合政务、金融两个真实案例，拆解密评不通过的核心问题、整改细节，帮大家避开同类坑，少走返工路。
该平台是省级政务核心系统，服务全省 13 个地市的企业开办、社保查询、公积金办理等业务，日均访问量超 50 万次，存储着 3000 余万企业和个人的敏感数据（如营业执照号、社保缴费记录）。按《密码法》要求，作为等保三级系统，需在上线前完成密评并备案。
测评机构通过 “文档审查 + 现场检查 + 工具测试”，很快锁定了 3 个高风险漏洞，直接判定 “暂不合规”：
密钥存储不合规：系统加密用的 SM4 密钥，直接明文存放在 Tomcat 服务器的server.xml配置文件中，以 “encryption.key=abc123456789” 的形式暴露 —— 现场测试时，测评人员通过远程登录服务器，10 分钟内就获取了密钥，若被黑客利用，可解密所有存储的敏感数据；
传输协议版本过低：系统前后端数据传输用的是 TLS 1.0 协议，而《GB/T 39786-2021》明确要求 “数据传输需采用 TLS 1.2 及以上版本”，TLS 1.0 存在 “BEAST 攻击” 等已知漏洞，无法抵御现代黑客攻击；
密钥未定期更换：查阅密钥管理日志发现，系统上线 1 年多，核心加密密钥从未更换过 —— 按密评要求，“高敏感数据的加密密钥需每 90 天更换 1 次”，长期不换会增加密钥泄露后的风险（一旦密钥被窃取，历史数据也会被破解）。
针对问题，团队联合密码厂商制定整改方案，重点突破 “密钥安全管理” 和 “传输加密升级”：
密钥迁移至合规 KMS 系统：放弃原来的配置文件存储方式，采购某国产厂商的 GM-KMS 3.0 系统（已通过商用密码产品认证），开发 RESTful 接口实现 “密钥动态调用”—— 代码中不再硬编码密钥，而是通过 “用户身份认证 + Token 授权” 从 KMS 实时获取，调用记录自动同步至日志审计平台，确保 “谁用密钥、何时用” 可追溯；
传输协议升级与兼容处理：将所有接口的传输协议升级为 TLS 1.3，同时考虑到部分老旧政务终端（如乡镇社保大厅的旧电脑）不支持 TLS 1.3，临时保留 TLS 1.2 作为过渡，通过服务器配置 “协议协商机制” 自动匹配终端版本，并推送公告引导用户升级设备；
配置密钥自动轮换：在 KMS 系统中设置 “每 90 天自动更换密钥” 的规则，同时开发 “密钥过渡工具”—— 更换密钥时，先保留旧密钥用于解密历史数据，新密钥用于加密新数据，避免出现 “新密钥生效后，旧数据无法解密” 的问题，轮换过程全程记录日志，供后续审计。
整改完成后，测评机构针对性复测：现场验证密钥需从 KMS 动态获取，工具测试 TLS 1.3 加密强度达标，核查日志确认密钥已自动轮换 1 次，最终出具 “合规” 评估报告。该平台备案通过后，不仅顺利完成政务项目验收，后续运维中还因密钥管理规范，避免了 1 次员工误操作导致的密钥泄露风险。
这款 APP 主打个人消费信贷业务，注册用户超 800 万，日均交易笔数达 10 万 +，涉及用户身份证号、银行卡号、信贷额度等高度敏感数据。作为金融领域关键信息基础设施，按《商用密码管理条例》要求，需每半年做 1 次密评，此次是首次评估。
测评机构重点核查 “数据存储加密”“支付接口安全”“测试环境规范”，发现 3 个中高风险问题：
用户密码存储算法过时：用户登录密码用 MD5 哈希算法存储，未加盐值 —— 测评人员用公开的 “彩虹表” 工具，10 分钟内就破解了 5 条测试账号的密码，而 MD5 算法早在 2004 年就被证明存在安全漏洞，不符合密评 “高敏感数据需用国密算法保护” 的要求；
支付接口用境外算法：APP 与第三方支付机构对接的接口，用的是 RSA-1024 算法加密交易数据，而《GB/T 35273-2020》明确 “金融领域需优先采用国密算法”，且 RSA-1024 的密钥长度低于安全标准（需≥2048 位），存在被暴力破解的风险；
测试环境用真实用户数据：开发和测试环境的数据库中，存储着 10 万条未脱敏的真实用户数据（身份证号、银行卡号完整显示），且测试服务器未做访问控制 —— 测评人员通过弱密码登录测试库，直接下载了全量数据，违反 “非生产环境禁止使用真实敏感数据” 的要求。
团队联合安全厂商快速推进整改，聚焦 “算法替换” 和 “数据脱敏”：
密码存储升级为 SM3 + 随机盐值：废弃 MD5 算法，改用 SM3 国密哈希算法，同时为每个用户生成唯一盐值（由 “用户 ID 哈希值 + 8 位随机字符串” 组成）—— 密码加密时，先将明文密码与盐值拼接，再用 SM3 计算哈希值存储；登录验证时，按相同逻辑计算后比对，确保即使数据库泄露，黑客也无法逆向破解密码；
支付接口替换为 SM2 国密算法：协调第三方支付机构，将接口加密算法从 RSA-1024 更换为 SM2，同时对接某国密认证的支付加密网关 —— 交易数据传输前，先用 SM2 加密，再通过 TLS 1.3 传输，双重加密确保支付安全；整改后，用专用工具测试加密强度，30 分钟内无法破解，符合密评要求；
测试环境数据全量脱敏：开发基于 MyBatis 拦截器的脱敏插件，自动对手机号（显示为 “138****5678”）、身份证号（隐藏中间 8 位）、银行卡号（保留前 6 位和后 4 位）进行脱敏处理 —— 生产数据同步至测试环境时，触发脱敏插件自动处理，同时删除测试库中已有的真实数据；另外，为测试服务器添加 IP 白名单和强密码认证，禁止非授权访问。
复测时，测评机构确认密码无法用彩虹表破解、支付接口加密达标、测试环境无真实数据，最终出具 “合规” 报告。此次整改不仅让 APP 通过密评，还提升了用户数据安全性 —— 后续某测试服务器遭遇黑客扫描时，因数据已脱敏，未造成信息泄露。
从两个案例能看出，密评不通过多是 “基础合规没做到位”，掌握以下 3 点，可避开 90% 的返工：
算法别踩 “过时 / 境外” 坑：优先选 SM2（身份认证、数据签名）、SM3（哈希校验）、SM4（数据加密）等国密算法，避开 MD5、RSA-1024、RC4 等过时或境外算法，尤其金融、政务领域，国密是唯一合规选择；
密钥别 “裸奔”，靠 KMS 管起来：密钥绝对不能存配置文件、代码或普通数据库，必须用国家认可的 KMS 系统，同时设置 “90 天自动轮换” 规则，操作日志留存至少 6 个月，确保可追溯；
测试环境别 “用真数据”：开发、测试阶段必须用脱敏数据，可通过插件、脚本自动处理，避免因测试数据泄露影响密评，也能降低内部数据滥用风险。
其实密评没有想象中复杂，关键是 “提前对标、落地细节”—— 开发阶段就嵌入密码逻辑，前期自查补漏，比上线后突击整改更高效，也能节省大量时间和成本。
