防勒索如何映射密评数据完整性：把防护变成可交付举证材料

摘要：等保 2.0 与商用密码应用安全性评估（密评）都把数据完整性列为关键控制项，要求对重要数据实现防篡改、防破坏、可恢复。勒索病毒恰恰是数据完整性的头号破坏源。本文从合规举证视角出发，拆解进程白名单与透明加密如何逐条映射数据完整性控制项，并给出恢复演练清单、审计导出规范与密评整改报告的技术措施写法，把防住勒索转化为一份评审可直接采信的举证材料。 正在上传图片...

关键词：等保2.0，密评，数据完整性，进程白名单，透明加密，防勒索，整改材料，举证，GB/T 39786，GM/T 0054

一、为什么防勒索会被合规评审反复追问

在等保测评与密评整改现场，工程师最常听到的追问往往是：你们怎么证明重要数据没有被篡改或破坏？如果明天中了勒索病毒，你怎么向评审专家证明数据完整性没有失守？这两个问题看似在问安全产品，实质上是在问举证能力。传统防病毒思路侧重能不能杀掉已知样本，而合规评审关注有没有形成可追溯、可复现、可交付的证据链。二者之间有一条明显的鸿沟：杀毒软件拦截了一千次攻击，如果日志无法导出、无法和具体控制项对应、无法在演练中复现，评审仍然会判定控制措施有效性证据不足。

勒索病毒之所以成为数据完整性条目下的高频风险点，是因为它的破坏方式直击完整性核心。一次完整的勒索攻击，最终落点就是把明文数据替换为密文数据，使原始数据不可读、不可恢复，这本身就是最严重的被破坏。因此，谈论防勒索不能只谈拦截率这类营销口径，而要回到控制项本身：等保 2.0 的数据完整性、数据备份恢复，密评的应用和数据安全、数据完整性，到底要求什么技术动作，我们的防护手段又怎样逐条满足、并留下证据。

二、等保 2.0 与密评中数据完整性到底在审什么

2.1 等保 2.0 三级的对应控制项

按照 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》，三级系统与安全计算环境相关的控制项中，与勒索防护直接挂钩的有三条主线。第一条是数据完整性，要求应采用校验技术或密码技术保证重要数据在存储过程中的完整性。放到勒索场景下，这条意味着系统要能检测到重要数据被未授权改写，并在改写发生时阻断或告警。第二条是数据备份恢复，要求应提供重要数据的本地数据备份与恢复功能、异地实时备份功能、重要数据处理系统的热冗余。勒索的破坏之所以致命，往往不是加密本身，而是没有可用的恢复点。第三条是个人信息与重要数据保护，要求应仅采集和保存业务必需的用户个人信息，应禁止未授权访问和篡改。

2.2 密评在应用和数据安全层面的要求

密评依据 GM/T 0054-2018《信息系统密码应用基本要求》，在应用和数据安全层面明确要求：重要数据在传输和存储过程中的完整性应采用密码技术保证；重要数据的机密性应采用密码技术保证；实体身份真实性应采用密码技术保证；以及密钥全生命周期管理合规。注意这里的措辞差异。等保讲校验技术或密码技术，密评则更强调必须落到密码技术，且密钥管理要闭环。这意味着，如果防护方案用明文备份、用本地弱口令密钥、把密钥和密文放在同一磁盘，即便挡住了攻击，在密评眼里仍属未采用合规密码技术保护完整性，一样会被判不符合。

2.3 完整性、防篡改、防破坏的同一性

对评审专家而言，完整性、防篡改、防破坏是同一个硬币的三面：完整性是目标，防篡改是手段之一，防破坏是结果的可恢复性兜底。一个合格的举证材料应当同时覆盖这三面，而不是只交一份我们装了杀毒软件的说明。把勒索攻击链与数据完整性的破坏路径对应起来。

勒索攻击链与完整性破坏路径对应示意

三、进程白名单与透明加密如何逐条满足控制项

3.1 进程白名单：默认拒绝异常加密进程

进程白名单的核心策略是默认拒绝，只有经过签名、哈希、路径、发布者多重校验的可信进程，才被允许对受保护目录发起批量写操作。任何不在白名单内的进程，一旦表现出高并发加密行为，立即被拦截并记录。这一机制对应到数据完整性控制项，价值在于把检测未授权改写从事后校验提前到事中阻断。传统完整性校验只能告诉你数据已经被改了，而白名单在改写动作发生的第一毫秒就切断了执行链，使完整性破坏根本无从发生。

工程落地时，白名单策略建议配置为三层：内核驱动层负责文件写事件的实时拦截，策略引擎层做进程身份与行为基线比对，管理平面层负责白名单的发布、版本回滚与例外审批。三层解耦后，既能保证拦截性能，又能让策略变更本身留下审计痕迹。需要特别说明白名单的两种校验模式差异。一种是基于哈希的固定指纹校验，优点是精确，缺点是业务每次更新版本都要重新采集指纹；另一种是基于代码签名者的信任链校验，只要进程由受信发布者签名即通过，适合内部业务频繁迭代的场景。实际部署中常把二者组合。

一个典型的白名单策略片段如下：

{
  "policy_name": "rdm_protect_finance",
  "mode": "default_deny",
  "protect_paths": ["/data/finance", "/data/customer"],
  "allowed_signers": ["Internal-CA-2024"],
  "behavior_rules": {
    "max_write_per_sec": 200,
    "cross_dir_depth": 3,
    "rename_after_write": false,
    "delete_source_after_write": false
  },
  "action_on_violation": "block_and_log",
  "audit": { "retention_days": 180, "export": "syslog" }
}

3.2 透明加密：密钥独立托管、防二次加密

透明加密在文件系统层对落盘数据加密，业务应用无感知。它对应数据完整性中的存储机密性与完整性双重要求，但要让密评采信，有两条硬约束必须满足。第一，密钥必须托管在硬件安全模块或由合规密钥管理系统统一保护，禁止密钥明文落盘、禁止与密文同盘存放。第二，要区分读写语义，防止二次加密。所谓二次加密，指数据已经被透明加密的情况下，恶意进程再叠加一层自己的加密，导致即便防护存在也无法还原。透明加密引擎需要在内核层区分合法业务读改写与非法外部加密进程，对后者直接拒绝其加密写操作。

下面给出防二次加密的判定逻辑示意：

# 防二次加密判定逻辑（语义示意，非真实脚本）
输入：进程 P 对文件 F 发起写操作 W
步骤1：P 是否在进程白名单？ 是→放行；否→步骤2
步骤2：W 是否由受控透明加密引擎发起？ 是→放行；否→步骤3
步骤3：W 是否对已由本体系加密的密文再做外部加密？ 是→判定二次加密，拒绝并记录
步骤4：W 是否满足行为基线（速率/广度/重命名）？ 否→拒绝并记录
输出：block_and_log 或 allow

3.3 控制项到技术措施映射表

把上述两项能力映射到具体控制项，形成一张可直接贴进整改报告的技术措施表：

这张表的价值在于：评审专家看到的是控制项到技术措施到证据的完整链路，而不是孤立的产品介绍。每一行都能在后续恢复演练与审计导出中找到对应素材。

四、三重主动防护如何对应到举证材料

4.1 分阶段、全链条覆盖

一套进程白名单加透明加密加实时审计的三重主动防护，应当覆盖入侵、加密、提权、清理四个阶段，而不是只在加密阶段做单点防御。入侵阶段通过进程身份校验，阻止未签名、未知发布者的可执行体获得批量写权限，收窄攻击面；加密阶段白名单默认拒绝异常加密进程，透明加密对合法业务透明、对恶意加密拒绝，双重阻断；提权阶段防护引擎具备自保护能力，阻止恶意进程禁用或卸载防护组件，保障控制措施本身不被破坏；清理阶段全量审计日志实时落盘且不可被受保护进程删除，卷影与备份受同等加密保护，使攻击者无法抹除证据。这种分阶段、全链条的覆盖，恰好回应了评审对控制措施是否覆盖数据生命周期关键节点的追问。

五、恢复演练：把能防住变成能证明防住

很多单位在测评时卡在控制措施有效性证据不足，根因不是没有防护，而是没有演练、没有把演练变成记录。恢复演练的目的，是向评审证明即便发生最坏情况，系统仍能从干净副本可信恢复，且恢复过程本身可审计。

5.1 恢复演练清单

建议每次密评前至少执行一轮正式恢复演练，并完成以下清单：

1. 准备干净备份副本，确认备份完整性校验值已记录；
2. 在隔离环境模拟勒索加密事件，触发白名单拦截，记录拦截时间戳与进程信息；
3. 若假设拦截失效，导入加密后的受保护目录，执行从干净副本恢复；
4. 恢复后比对文件哈希，确认与备份前一致，出具一致性报告；
5. 验证审计日志在演练全程未被篡改，导出日志包；
6. 由信息安全责任人签字确认演练记录，归档留存至少一年。

5.2 演练记录模板

演练记录应字段化、可复核，下面给出字段模板：

drill_record:
  drill_id: DR-2026-xxx
  date: 2026-xx-xx
  simulation: 勒索行为模拟（禁用真实外联）
  block_result: 进程 white_list_deny，动作 block_and_log
  recover_source: 离线备份副本 BAK-2026-xxx，哈希 sha256:xxxx
  recover_cost_min: xx
  consistency: 通过（比对文件数 xxxx，差异 0）
  audit_retention: 180 天，导出包已归档
  owner_sign: __________

5.3 审计导出与日志留存

实时审计是全量审计的基础。举证时需要的审计导出通常包含三类：防护拦截日志（谁、什么进程、何时、对什么文件、被如何处置）、加密操作日志（哪些文件被合法透明加解密、密钥标识）、策略变更日志（白名单版本、发布人、回滚记录）。导出规范建议遵循统一字段，便于评审抽样核对：

{
  "export_fields": [
    "event_time: 事件时间（精确到毫秒）",
    "host_id: 主机标识",
    "process_name: 进程名",
    "process_signer: 进程签名者",
    "action: 拦截/放行/加密/恢复",
    "target_path: 目标路径",
    "control_item: 映射控制项编号",
    "policy_version: 生效策略版本",
    "result: 处置结果"
  ]
}

日志留存周期应不小于等保与密评的通用要求（一般不少于半年），且存储位置应受加密保护、与被保护主机分离，避免攻击者清理日志后破坏证据链。

六、密评整改报告中技术措施的写法

在密评整改报告里，技术措施不能写成部署了某产品，而要写成针对某某控制项，采用某某技术，达到某某效果，证据见某某材料。下面给出一套可直接套用的写法范式。

对应用和数据安全、数据完整性条目，可这样写：针对重要数据存储完整性要求，采用进程白名单默认拒绝机制，对未授权加密进程实时阻断；同时采用透明加密技术，密钥由硬件安全模块托管，并对读写语义做区分以防御二次加密。上述措施在测评周期内共产生拦截日志若干条，恢复演练记录一份，能够证明重要数据未被未授权篡改或破坏。

对数据备份恢复条目，可这样写：重要数据执行本地加密备份与异地副本双写，备份介质与密钥分离存储；定期开展恢复演练，演练记录显示恢复后文件一致性比对通过，恢复过程可审计。相关记录见附录演练报告与备份清单。

对重要数据保护条目，可这样写：对模型权重、训练数据、密钥文件等高价值资产纳入进程白名单与透明加密双重保护范围，非授权进程无法改写或读取，相关访问控制拒绝日志已留存并导出。这种写法的关键在于措施、效果、证据三段式，每一段都有对应材料支撑，评审无需二次追问即可采信。

在起草整改报告时，有三个常见失分点值得提前规避。第一是只写产品名不写技术动作，例如已部署防勒索软件，评审无法据此判断是否满足完整性控制项，必须落到默认拒绝异常加密进程、密钥由硬件安全模块托管这类可执行、可验证的描述。第二是证据与条目错配，例如把网络边界的拦截日志当作数据完整性证据提交，二者控制项不同，评审会判定相关性不足。第三是证据时间窗不完整，只提供测评前一周的日志，无法证明控制措施在全周期持续有效，建议至少覆盖一个完整测评周期并标注策略版本演进。

此外，对数据完整性与数据保密性的混淆也较常见。完整性关注是否被未授权篡改或破坏，保密性关注是否被未授权读取，二者在密评中分属不同指标。透明加密同时贡献两条指标：密文存储满足保密性，密钥受控与防二次加密满足完整性。报告中应分别写明，避免被要求补正。

七、从企业全场景到个人单机：举证材料的边界

举证材料的粒度要和组织规模匹配。大型企业多终端、多业务系统，适合由管理平台统一下发白名单策略、集中收集审计日志，提交策略总览、分级统计与抽样日志。对于研发个人、外包驻场等边缘场景，单机版配合硬件密钥本地身份的防护同样能满足控制项，只要密钥受控、本地审计可导出，即可形成轻量完整的举证包。

需要提醒的是，举证的边界在于重要数据的定义。应依据数据分类分级结果圈定受保护范围，再把防护与证据限定在该范围内，既满足合规，也避免资源浪费与性能开销。边界清晰反而更容易通过评审，因为专家最担心的就是保护范围说不清。

恢复演练与审计导出举证链路示意

方案参考

把防勒索能力转化为可交付的合规举证，本质是工程动作而非采购动作。给出几条可复用的方法论，供不同行业组织参考。其一，先画控制项映射表，再选技术，从等保三级与密评的应用和数据安全层面逐条列出数据完整性、数据备份恢复、重要数据保护的要求，再据此匹配进程白名单、透明加密、审计留存三类能力，映射表本身就是第一份举证骨架。其二，把默认拒绝作为白名单的基线原则，任何未经验证身份的进程对受保护目录发起的批量写，都应被拦截并留痕。其三，密钥与密文必须分离、密钥必须由合规硬件或密钥管理系统保护，这是密评与等保在密码技术维度上的共同底线，缺失则完整性、机密性两条同时失分。其四，建立措施、效果、证据三段式文档习惯，每一次策略变更、每一次拦截、每一轮演练，都记录为结构化字段并归档。其五，恢复演练常态化、记录化，演练记录、备份清单、审计导出包三者绑定归档。其六，依据数据分类分级收敛保护范围，先界定重要数据资产边界，再把防护与举证聚焦其上。在密评整改材料落地中，部分团队会以安当RDM这类产品作为参考实现，对照上述六条逐项自检，通常即可形成一份密评现场可直接采信的防勒索专项举证材料。