字段级脱敏如何映射密评数据保密性：从控制项到可交付整改材料

摘要：等保 2.0 与商用密码应用安全性评估（密评）对「数据保密性」控制项提出了明确的去标识化与加密要求。本文从密评条款出发，拆解字段级动态脱敏如何作为该控制项的技术措施，给出控制项到技术措施的映射表，并说明敏感数据发现、分类分级联动、脱敏策略、去标识化举证与审计报告如何沉淀为可交付的整改材料。同时给出性能基线与损耗在整改报告中的写法，帮助工程师把技术能力翻译成评估专家可采信的证据链。 正在上传图片...

关键词：密评，等保2.0，数据保密性，去标识化，动态脱敏，字段级脱敏，整改材料，举证，GB/T 39786，GM/T 0054

一、密评「数据保密性」控制项到底在审什么

密码应用安全性评估（简称密评）依据 GB/T 39786《信息安全技术 信息系统密码应用基本要求》，把信息系统的密码应用分为物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个层面。其中与数据脱敏最相关的是「应用和数据安全」层面的「数据保密性」控制项。该控制项的核心判定逻辑只有一句话：对存储和传输的敏感数据，必须采用密码技术保证其保密性；对需要对外提供但又不能暴露原始值的场景，应采用去标识化、脱敏等手段降低泄露风险。

很多单位在准备密评材料时容易陷入一个误区：认为「数据保密性」就是上透明加密。实际上控制项的评估维度包含三条主线。第一条是静态存储保密性，落盘的数据尤其是个人信息、账户口令、证件号、银行卡号等是否经过加密或去标识化处理。第二条是动态使用保密性，在查询、导出、运维、远程接入等使用环节，敏感字段是否按身份与场景动态脱敏。第三条是密钥与策略可管理性，加密或脱敏所依赖的密钥是否由合规的密钥管理系统统一托管，策略是否留痕、可回溯。

密评现场测评通常采用「技术测评加管理测评」双线。技术测评看的是真实生效的能力，比如截一段运维查询的返回结果，看身份证号是否变成了星号；管理测评看的是制度与材料，比如有没有敏感数据资产清单、有没有脱敏策略审批单、有没有定期审计报告。这就带来一个现实问题：技术能力本身不等于密评能通过，必须把技术能力翻译成评估专家能看懂、能采信的举证材料。字段级脱敏恰好是一个既能在技术层面真实生效、又能在材料层面清晰呈现的控制项。

1.1 控制项原文的关键词拆解

控制项文本里反复出现两个动作词：「采用密码技术保证保密性」与「采用去标识化技术」。这两个词对应到工程实现上是两套不同机制。加密保证的是即使拿到数据也读不出原文，典型如字段级加密、表空间加密、文件加密。去标识化与脱敏保证的是在使用环节不暴露原文，典型如动态脱敏、静态脱敏、泛化、掩码。两者不是替代关系，而是互补关系。加密解决存储态保密，脱敏解决使用态保密。一套完整的整改方案通常会把两者组合进同一个数据访问链路上。

1.2 测评扣分的典型情形

在历年密评整改项目里，数据保密性控制项失分最常见的几种情况如下表所示。可以看到，表里多数情形本质上都指向同一件事：需要一个位于应用与数据库之间的统一管控平面，把脱敏、加密、权限、审计收口到一起，而不是让策略散落在脚本里无法举证。

字段级脱敏统一管控平面示意

二、字段级脱敏如何映射为密评技术措施

把字段级脱敏翻译成密评语言，核心是把我们能做什么对齐到控制项要求什么。下面是一张可直接复用于整改报告的控制项到技术措施映射表，它把模糊的「我们部署了一个脱敏网关」变成「针对控制项要求，我们落地了措施，可提交物」的结构化举证。评估专家最欢迎的就是这种一一对应的结构。

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

2.2 动态脱敏与静态脱敏的分工

在整改材料里，建议明确区分两类脱敏，避免被追问你的脱敏是哪种脱敏。动态脱敏指数据不出库，查询时按访问主体的身份、角色、时间、来源网络实时决定返回明文还是掩码，适合运维查询、远程接入、报表导出等在线场景。静态脱敏指把生产库的数据抽取到测试、分析、培训环境时，先脱敏再出库，适合数据外发、开发测试场景。密评更看重动态脱敏的实时生效与按身份差异，因为它直接对应使用态保密性；静态脱敏则更多用于数据外发合规。

三、敏感数据发现与分类分级联动

脱敏要做得对，第一步不是写规则，而是先知道哪些字段敏感、敏感到什么级别。这恰恰是很多整改项目最容易跳过的环节，结果就是脱敏规则靠人工拍脑袋，既漏字段又难举证。

3.1 敏感数据发现

敏感数据发现指对数据库中的表、列做自动扫描，结合字段名特征（如证件号、手机号、邮箱）与数据内容特征（身份证号十八位正则、手机号十一位正则、邮箱格式）识别敏感列。一个可复用的发现流程如下：

# 敏感数据发现流程（步骤示意，非真实命令）
1. 连接目标数据源，拉取元数据（库/表/列/注释）
2. 按字段命名规则匹配敏感类型：
   - 证件类：id_card / cert_no / sfz
   - 联系类：phone / mobile / email
   - 账户类：bank_card / account_no
   - 地址类：address / addr
3. 抽样扫描列内实际数据，用正则与校验位验证
4. 输出敏感数据资产清单，标注命中列与命中率
5. 把命中列自动挂到分类分级标签

上述流程把命中列自动挂到分类分级标签，避免人工逐表梳理，也让后续脱敏策略有据可依。

3.2 分类分级联动策略

数据安全法与个人信息保护法要求对数据做分类分级。脱敏策略应当直接引用分级结果，而不是另起一套规则。推荐的分级联动模型如下：

关键点在于：分级结果变了，脱敏动作自动跟着变。当某个字段被重新定级，脱敏网关应能在策略发布后即时生效，而不是要改代码。这种分级驱动脱敏的链路，是密评材料里非常加分的一段，它证明你的脱敏不是孤立脚本，而是与数据治理体系联动。

3.3 策略表达示例

脱敏策略在工程上可以表示为一份结构化配置，下面用配置说明其要素：

policy:
  name: 个人信息动态脱敏策略
  scope:
    datasource: 客户主库
    tables: [t_customer, t_order]
  rules:
    - field: id_card
      level: 核心
      method: fpe_keep_format      # 保留格式加密，存储态保密
      mask_query: full_mask        # 运维查询全掩码
    - field: phone
      level: 重要
      method: shuffle_keep_tail    # 中间位打星
      mask_query: tail_4           # 仅保留后四位
    - field: address
      level: 重要
      method: segment_mask         # 街道门牌脱敏
  approver: 数据安全负责人
  effective: T+0 即时

把这份配置连同审批单一起归档，就是一份完整的技术措施加管理审批双证材料。

四、去标识化举证：把脱敏前后对照写进报告

密评专家最关心的不是你说做了脱敏，而是能看到脱敏前后的对照证据。因此整改材料里必须包含脱敏前后对照样例。

4.1 脱敏前后对照表

下面是一张可直接贴进报告的对照样例（数据为虚构测试样本）：

这张表要说明的是：同一个数据库、同一份数据，不同访问主体看到的内容不同。这正是动态脱敏加权限三视图的举证核心，它直接回应控制项里按身份差异保护敏感数据的要求。

4.2 保留格式加密的举证价值

普通加密会把手机号变成一段定长密文，导致原来依赖前缀、范围、模糊查询的语句全部失效。保留格式加密保证密文与原文在格式和长度上一致，例如手机号加密后仍是十一位数字。这对密评材料有两个实打实的好处。第一是业务连续性可验证，加密后原有查询语句仍可用，证明加密改造没有破坏业务。第二是存储结构不变，字段长度、类型不变，证明是应用零改造的字段级方案。

-- 业务侧原有查询，在保留格式加密下仍可命中（语义示意）
SELECT user_name, phone
FROM   t_customer
WHERE  phone LIKE '138%'
  AND  create_date BETWEEN '2024-01-01' AND '2024-06-30';

这条语句在透明加密网关加保留格式加密的组合下，业务代码无需修改即可正常执行，是应用零改造加密最有力的技术注脚。

4.3 去标识化强度的写法

在整改报告中描述去标识化强度时，建议按方法、可逆性、残留风险三段式书写，避免空泛。方法指采用保留格式加密与掩码相结合，核心字段加密存储，查询态按角色动态掩码。可逆性指授权业务主体经策略判定后可恢复明文，运维主体不可逆见明文。残留风险指脱敏后仍可能通过组合字段重识别，已通过字段组合限制与访问频控降低风险。这种写法比单纯写已实现脱敏要扎实得多，评估专家能从字里行间判断你真的做过威胁建模。

五、性能基线与损耗举证

落到一个具体产品形态上会更直观。这里看一款位于应用与数据库之间的透明代理，如何把上述控制项落地，并把性能数据写进整改报告。

5.1 双模式架构与密评对应

透明代理提供两种工作模式，恰好对应密评的不同整改路径：

两种模式可以并存于同一套部署：业务流量走透明加密网关保证落盘保密，运维流量走运维管控网关保证查询脱敏。这种同一平面、双通道的设计，让整改既满足存储加密，又满足运维脱敏，两条控制项一次覆盖。

5.2 性能基线怎么写

密评材料里经常被追问的问题是：你加了这层代理，性能掉多少，会不会成为瓶颈。这时不能拍脑袋，要给出实测基线。可引用的性能基线如下：

• 单集群吞吐：三万以上每秒查询数；
• 性能损耗：相对直连数据库下降百分之五到十；
• 延迟特征：尾延迟在可接受区间；
• 横向扩展：支持多节点负载均衡，吞吐随节点线性提升。

在整改报告里，建议这样组织性能章节：

performance_verification:
  target: 管控网关（透明加密加动态脱敏双开）
  tool: 基准压测客户端，混合读写比例 7:3
  duration: 持续 30 分钟稳态
  metrics: [QPS, 平均延迟, P99 延迟, 错误率]
  result:
    direct_db: { qps: 33000, avg_latency_ms: 4.2 }
    via_gateway: { qps: 31200, avg_latency_ms: 4.6 }
    loss: "约 5.5%，满足生产容量冗余要求"
  conclusion: 网关引入未对业务吞吐造成实质性影响

这段写法的关键是给出前后对照的实测数字，而不是只给一个损耗很小的结论。评估专家更信任带基线的数据。

5.3 密钥由独立系统托管的举证

密评对密钥管理有明确合规要求：密钥不能与应用耦合、不能硬编码、必须可轮换。加密密钥由独立的密钥管理系统统一下发与托管，网关自身不落地主密钥。在材料里可以画一张极简架构说明：

# 密钥分离架构示意（逻辑图，非命令）
应用 ──→ 管控网关（执行脱敏与加解密）──→ 数据库
               │
               └──→ 密钥管理系统（密钥生成/分发/轮换/归档）

佐证材料包括：密钥分级图、密钥轮换记录、密钥与数据分离说明。这三样东西齐了，密钥管理控制项基本就能闭环。

六、审计导出：让每一次脱敏都说得出来源

密评管理测评里极重要的一项是操作可追溯。脱敏不是一锤子买卖，必须证明谁、在什么时候、以什么身份、查了哪个字段、有没有脱敏。这就是审计能力的价值。

6.1 语句级拦截与全量审计

运维管控网关应具备语句级拦截能力：对高危语句按策略拦截或二次审批，同时对所有访问做全量审计。审计记录建议至少包含以下字段，并可直接导出为举证附件：

{
  "audit_fields": [
    "time: 精确到毫秒",
    "subject: 登录账号或应用标识",
    "source: 来源网络与接入通道（本地或远程接入）",
    "object: 库.表.字段",
    "action: SELECT / EXPORT / 拦截",
    "policy: 命中的脱敏策略名",
    "result: 返回明文 / 脱敏值 / 已拦截",
    "risk_tag: 命中高危规则与否"
  ]
}

把这份记录按月导出成文档或表格，附在整改报告运维管控章节，就是一份真实运行态的强举证。

6.2 审计导出与密评材料的衔接

审计数据不能只躺在系统里，必须转化为可归档材料。推荐的材料包结构如下：

把上述六件套打包，几乎可以覆盖数据保密性控制项从技术到管理的主要得分点。

七、把整改材料写成一份可交付包的清单

综合前文，一份能够直接应对密评数据保密性控制项的脱敏专项材料，建议按以下顺序组织。每一节都要做到有图、有数、有审批，避免纯文字描述。密评专家在有限时间内能快速采信结构清晰、证据链完整的材料。

1. 控制项解读页：摘录对应条款，说明本单位的差距与整改目标。
2. 技术架构图：画出应用、脱敏加密网关、数据库、密钥管理的链路。
3. 敏感数据发现报告：给出扫描范围、命中字段、分级结论。
4. 脱敏策略集：列出每条策略的字段、方法、可视角色、审批人。
5. 脱敏前后对照：提供真实脱敏后样例，证明差异视图生效。
6. 性能基线报告：给出直连与经网关的吞吐、延迟、损耗对照。
7. 审计与拦截记录：提供抽样日志，证明运行态受控。
8. 密钥管理说明：证明密钥独立托管与可轮换。

常见材料返工原因多半是：只有架构图没有实测数据，无法证明真实生效；脱敏策略没有审批记录，管理测评不采信；审计记录字段不全，无法回溯谁查了什么；分级与脱敏脱节，说不清为什么这个字段脱、那个不脱；性能数据缺基线对照，无法打消是否拖累业务的疑虑。把返工原因逐一前置规避，可以显著提升一次通过率。

许多单位密评失分，问题不在内网，而在远程接入与运维通道。当人员通过远程方式访问数据库做排查时，如果返回的是完整敏感字段，就等同于把生产明文暴露在不受控环境。整改时应明确：远程接入通道同样要走脱敏网关，且与本地运维采用同一套策略，只是来源网络维度作为额外判定条件。在材料里写清远程接入与本地运维共用脱敏平面这一点，能堵住一个高频失分点。

脱敏前后三视图对照示意

方案参考

把字段级脱敏作为等保密评数据保密性控制项的举证，本质是一套技术生效加材料闭环的方法论，不依赖特定厂商。通用落地路径如下：先做资产盘点再做策略，用敏感数据发现工具扫描全量库表，输出分级资产清单；分级驱动脱敏，把分类分级结果作为脱敏动作的唯一输入源；动静结合，存储态用字段级加密或去标识化保底，使用态用动态脱敏按身份差异呈现；保留业务连续性，优先选择保留格式加密，确保模糊、范围、前缀等原有查询不受影响；统一管控平面，把脱敏、加密、权限、审计收口到应用与数据库之间的单一代理层；密钥独立托管，加密密钥交由独立密钥管理系统统一生成、分发、轮换；用数据说话，性能与损耗必须给出直连与经网关的实测对照，审计必须可导出、可抽样、可回溯；材料结构化归档，按解读、架构、发现、策略、对照、性能、审计、密钥八节组织整改包。在密评整改材料落地中，部分团队会以安当DBG这类产品作为参考实现，对照上述八节逐项自检，补齐缺失的审批单、审计样本与性能基线，通常即可形成一份密评现场可直接采信的脱敏专项举证材料。