数据离开数据库之后怎么管：人行令 3 号与分类分级作为统一识别层

当数据离开数据库

分类分级如何成为数据安全的统一识别层

过去六期我们讨论了分类分级的范式、方法、行业差异、工程基础。但有一个根本问题一直没有正面回答——

分类分级做完之后,真正的价值是什么?把每个字段贴上标签,然后呢?

市场上的多数项目,这个问题的答案是:加密、脱敏、访问控制。这三件套被称为「数据安全三板斧」,也是绝大多数厂商的标准交付物。机构买了分类分级工具,部署完之后,把高敏字段做加密、查询时脱敏、按角色管访问——项目结题、监管认可、年度合规过关。

但稍微深入观察就会发现一个奇怪的现象:

1. 机构投了重金做分类分级,但敏感数据泄露的事件并没有减少;

2. 终端、邮件、Web 各种设备都有 DLP 能力,但误报和漏报都很严重;

3. 员工把数据库导出的 Excel 通过个人微信发出去,所有设备视而不见;

4. 一份内部文档在多轮编辑后流出,溯源追不到任何一个分类标签。

根本原因不在工具数量不够,也不在三件套不够用。根本原因在于:数据安全的核心战场,已经从数据库内,转移到了数据库外。

这一期我们用整篇文章讲一件事——为什么数据离开数据库之后,分类分级的角色应该从「合规标签」升级为「数据安全的统一识别层」;以及,这件事监管端已经看清楚了,工具端为什么还在原地。

一、数据离开数据库,形态立即发生变化

数据库里的数据是结构化的——字段、表、关系都清晰可见。但数据库只是数据生命周期的起点,数据真正发挥业务价值,是在它流出数据库之后。

数据真实的存在和流通形态

把一家金融机构、医疗机构或大型企业的数据流动场景列开来,数据库内部的存在只是冰山一角。下面这张表覆盖了数据离开数据库后最常见的八种流通形态。

这张表里的每一种形态,从结构化数据库视角看,都是「非结构化或半结构化」。它们的共同特征:

1. 数据脱离了原始字段名,变成 JSON 节点、报文标签、文档片段、HTML 渲染元素、文件内容、向量编码;

2. 数据的业务含义不再由表结构定义,而由上下文、文档类型、传输场景共同决定;

3. 数据的敏感性需要从内容本身重新识别,不能再依赖原始字段标签。

传统数据库视角的覆盖率

如果只用数据库内的方式做分类分级与保护,实际能覆盖的数据,在多数机构里只占资产总量的 20%-40%。剩下 60%-80% 的敏感数据,在数据离开数据库的那一刻起,就走出了传统数据安全的视野。

这不是某一家机构的特殊问题,是行业整体面临的结构性盲区。

数据库内的数据保护已经被研究了二十年,工具成熟、监管清晰。但今天的数据安全核心矛盾,在数据库外。

二、监管已经看到了这件事

数据形态的演变,监管端比我们想象的看得更清楚。

2025 年发布的人行令 3 号《中国人民银行业务领域数据安全管理办法》,在数据分级与保护这一章中,做了一件意义深远的事——它不止讨论数据库内的结构化数据,而是把「非结构化数据」明确纳入了分级与保护的强制范围。

四条监管原文,把全生命周期的分级保护画好了

原文一:非结构化数据也要逐项分级

在数据分级基础上,数据处理者应当参考行业标准,根据数据遭到泄露或者被非法获取、非法利用时,可能对个人、组织合法权益或者公共利益等造成的危害程度,将数据项敏感性从低至高进一步分为一至五共五个层级。结构化数据项应当逐一标识层级;非结构化数据项应当优先按照可拆分的各结构化数据项所对应最高层级,标识其层级。

—— 人行令 3 号 关于数据敏感性分层级

这条原文的关键在两个动词——「逐一标识」和「优先按照可拆分的各结构化数据项所对应最高层级」。

第一个动词意味着:分级不是「这张表整体是 3 级」这种粗颗粒,而是「每一个数据项都要有自己的层级标识」的细颗粒。第二个动词意味着:非结构化数据(文档、报文、邮件附件)不能因为「形态不同」就回避分级——它要先被拆解为可识别的结构化数据项,然后按其中最高敏感的那一项标识层级。

这是非常具体的工程要求。它直接判定了——一个只能处理结构化数据库字段的工具,不满足这条监管要求。

原文二:三级以上要加密存储,非结构化要拆分加密

除因业务影响、产业制约,并可提供详细分析报告情形外,应当优先采用商用密码技术对信息系统中第三层级以上数据项实施加密存储,结构化数据项在对数据库文件整体实施加密基础上鼓励进一步采用更细粒度的加密方式,非结构化数据项可仅对拆分的第三层级以上结构化数据项单独实施加密。

—— 人行令 3 号 关于加密存储

这条原文延续了第一条的逻辑:既然非结构化数据要按「可拆分的最高层级」标识,那么加密保护也要落实到「拆分出来的高敏字段」上。

一份业务文档不能因为它是 PDF 就笼统加密——要识别出文档中包含的第三层级以上数据项(比如其中的客户身份证、账号),针对这些数据项做加密保护。这意味着工具必须能在文档内部做字段级识别,而不是把文档当成一个不透明的「黑盒」。

原文三:第三层级数据不得未经授权存储在终端

[违规情形之三] 终端设备和移动介质未经授权存储第三层级以上数据项。

—— 人行令 3 号 关于终端违规情形

这一条把数据保护的边界,从数据库直接延伸到了员工的电脑、移动硬盘、U 盘。

它的意思是:一份从核心系统导出的客户清单 Excel,如果其中包含第三层级以上数据项,而员工没有获得授权就保存在自己的笔记本上——这本身就是违规。

要执行这条规定,需要的能力是:终端设备(桌管 / DLP)能识别本地文件中是否包含第三层级以上数据项。但目前绝大多数终端工具识别的是「关键字 + 正则」,根本无法判断「这份 Excel 里的某一列是不是第三层级数据」——因为它们没有统一的数据分级标签作为依据。

原文四:第三层级数据不得通过公共工具传输

[违规情形之十一] 终端设备使用互联网邮件、公共即时通讯、互联网文件传输工具传输第三层级以上数据项或者打印第三层级以上数据项。

—— 人行令 3 号 关于终端违规情形

这一条把保护边界进一步延伸到了流转链路——员工不能用个人邮箱、个人微信、公网文件传输工具发送第三层级以上数据项,也不能随便打印。

这一条对工具的要求最严苛——要在邮件网关、IM 监控、Web 上传、终端打印等多个出口同时做识别。识别的关键不是「这里有一个字符串看起来像手机号」,而是「这里有一个数据项被打了第三层级的标签」。

四条原文连起来,监管的逻辑非常清楚

把上面四条原文连起来看,人行实际上画出了一条完整的「全生命周期分级保护」链条:

1. **起点：**所有数据项(包括非结构化)逐一标识层级;

2. **存储：**第三层级以上的数据项要加密,非结构化数据要按拆分项加密;

3. **终端：**第三层级以上的数据项不得未经授权存储在员工终端;

4. **流转：**第三层级以上的数据项不得用公共邮件、IM、文件传输工具传输,不得随便打印。

这四个环节连起来,构成了一个跟着数据走的「分级标签 + 差异化保护」体系——分级标签是基础,所有的保护动作都以「第几层级」为判断依据。

监管端已经把全生命周期分级保护的图画好了。现在的问题在工具端——绝大多数工具还停留在数据库内的静态保护,根本无法支撑这条监管链条的全部环节。

三、传统三件套的能与不能

讲到这里,我们才能公允地评价「加密、脱敏、访问控制」这传统三件套——它们解决了什么,又没解决什么。

三件套解决了什么

1. **加密：**解决数据在数据库或文件系统中静态存储时的保护——数据被偷走了也读不出来;

2. **脱敏：**解决数据被查询时的展示控制——展示给低权限角色看的是 *** 而不是明文;

3. **访问控制：**解决数据在系统边界的进出控制——什么角色能查什么表、调什么接口。

这三件套是数据安全的基础,任何一个项目都需要它们。在过去二十年的数据库时代,这三件套基本能覆盖大部分数据保护场景。

三件套不能解决什么

但今天数据安全的新场景,三件套覆盖不到的,远比覆盖到的多。

第一,三件套只在「数据库边界」生效

数据一旦被合法用户取出数据库——通过查询、导出、API 调用、报表生成——三件套就基本退场了。导出的 Excel 不会自动加密、生成的 PDF 不会自动脱敏、流转中的 JSON 不会自动访问控制。从这一刻起,数据进入了三件套照不到的灰色地带。

第二,三件套是「静态」的,不是「跟着数据走」的

数据离开数据库后,它的形态、位置、流转链路都在变化。但三件套的视角是静态的——它只关心「这张表怎么加密」「这个字段怎么脱敏」「这个角色能不能查这个表」,它不知道「这份 Excel 被发到哪里去了」「这个文档被谁打印了」「这条 IM 消息里包含什么级别的数据」。

第三,三件套之间没有共同的「识别层」

加密、脱敏、访问控制是三套独立的策略机制。每一套都有自己的规则配置、识别逻辑、运营团队。结果是:同一个高敏字段,在加密配置里可能是「保护对象 A」,在脱敏配置里是「规则 B 的目标」,在访问控制里是「角色 C 的权限范围」。三套机制各说各话,缺乏共同语言。

不是错,是不够

再次强调——这不是说三件套是错的。它们是数据安全的基础,任何方案都不可缺少。但仅靠三件套已经无法支撑今天的数据安全要求。

人行令 3 号要求的「全生命周期分级保护」,需要的是一种全新的能力——数据走到哪里,识别就跟到哪里,保护就跟到哪里。这种能力,三件套撑不起来,需要一个新的底层。

四、设备时代的分类分级孤岛

讨论完三件套的边界,我们来看今天数据安全的真实图景:数据离开数据库后,实际上是被一系列「网关与终端设备」接管的。

数据离开数据库后,谁在守护它?

一份从核心系统导出的客户清单 Excel,它可能经过的「数据安全设备」包括:

各设备都有识别能力,但识别能力是「孤岛式」的

这张表呈现了一个值得思考的现象:数据安全行业过去十多年间,几乎所有「数据出口」都已经被各种网关和终端设备覆盖了——理论上是好事,数据不再「无人值守」。

但是,每一个设备都用自己的一套识别规则。终端 DLP 用一套关键字和正则,邮件网关用另一套,Web 网关用第三套,数据库审计用第四套。这导致了几个严重后果:

1. **误报率高：**一个不重要的字段被某台网关识别为敏感,触发拦截,业务被打断;

2. **漏报率也高：**一个真正敏感的字段被另一台网关漏掉,数据顺利外发;

3. **策略冲突：**同一类数据,终端 DLP 说要拦截、邮件网关说可以放行——管理员调和不了;

4. **运营成本高：**每个设备需要独立配置、独立运维、独立调优,投入成倍增加;

5. **审计断链：**一份数据从数据库 → 终端 → 邮件 → 网关的流转链路,各设备记录的是孤立日志,无法串起来形成完整审计。

根本原因只有一个——这些设备没有共同的「数据识别语言」。每一个设备都在用自己的方式回答「这是不是敏感数据」,但没有一个统一的、动态的、可信的「数据分级标签」作为大家共享的判断依据。

数据安全设备已经形成了「全网覆盖」,但还没有形成「全网协同」——因为它们之间没有共同的识别层。

五、分类分级作为数据安全的统一识别层

把以上几章的讨论合起来,一个清晰的图景就浮现出来——

如果存在一种能力,可以

1. 识别数据库内的字段并打上分级标签;

2. 识别数据离开数据库后的所有形态(API 报文、文档、邮件、Web、IM、终端文件等)并继续打标;

3. 把这些标签作为统一的「数据 DNA」,被所有数据安全设备共享;

4. 当数据流转时,标签跟着数据一起走,被沿途每一个设备读取并触发对应策略;

——那么三件套的边界问题、设备时代的孤岛问题、监管要求的全生命周期保护问题,都能从根上得到解决。

这种能力,就是「分类分级作为统一识别层」的核心愿景。

它带来的工程价值

价值一:数据走到哪,识别跟到哪

分级标签不再是数据库内的一行元数据,而是数据本身的属性。文档里嵌入水印标签、API 报文里携带标签字段、邮件附件的元数据中包含标签——数据流转过程中,标签始终伴随。

价值二:所有设备共享同一种识别语言

终端 DLP、邮件网关、Web 网关、堡垒机、CASB 等所有设备,不再各自维护一套识别规则,而是订阅同一个分类分级标签系统。每个设备的策略以「分级标签」为输入——「这份文件包含第 4 层级数据,触发拦截规则」「这条 IM 消息包含第 3 层级数据,触发审计规则」。

价值三:策略可以一处配置、全网生效

管理员不再需要在每一个设备上分别配置规则。在中央策略平台上配置一条「第 4 层级数据禁止通过公共 IM 传输」,这条策略会被所有相关设备(IM 监控、终端 DLP、邮件网关等)同时遵循。

价值四:审计可以全链路串联

一份数据从数据库导出到最终流出,每一个环节(导出、保存、转发、传输、打印)都记录在同一套审计体系中——因为每个环节的识别依据是同一套分级标签。监管现场检查时,可以拿出完整的数据流转轨迹。

价值五:监管要求被直接满足

人行令 3 号要求的「第三层级以上数据项不得通过公共工具传输」「不得未经授权存储在终端」——这些要求在统一识别层架构下,可以被自动化执行。终端发现高敏数据未授权存储,自动报警;邮件网关发现高敏数据外发,自动拦截;每一个动作都有分级标签作为依据。

六、统一识别层的工程含义

把愿景落实到工程,有几个具体的工作必须做。

工程一:非结构化数据的字段级识别能力

统一识别层的基础,是能在非结构化数据中做字段级识别——一份 PDF 里包含哪些可拆分的数据项、一封邮件附件中包含哪些敏感字段、一个 JSON 报文中哪些节点对应哪个业务字段。这正是人行令 3 号原文一所说的「可拆分的各结构化数据项」识别能力。

这种能力的核心,不是 OCR,不是关键字匹配,而是基于业务上下文的精确识别——把非结构化形态还原为可识别的数据项,然后按照与结构化字段相同的方法分级。

工程二:分级标签的标准化与可携带

分级标签需要标准化——所有设备都按同一种格式理解。同时标签要可携带——文档、邮件、报文、向量等形态都需要能携带标签元数据,标签不能在格式转换中丢失。

工程三:中央标签服务 + 设备订阅

需要一个中央的「标签服务」作为全网共识,所有设备通过 API 或事件机制订阅。当中央服务对某类数据的分级更新时,所有设备立即同步;当某个设备识别出一份新数据,通过中央服务获得权威的分级判定。

工程四:策略中心按标签下发

配套一个策略中心——所有数据安全策略都以「分级标签」为输入。终端策略、邮件策略、Web 策略、堡垒机策略,都在策略中心配置,然后下发到各设备执行。

工程五:全链路审计的标签贯通

每一个数据安全设备产生的审计事件,都包含「这份数据的分级标签」字段。审计平台按标签维度做关联,串成完整的数据流转故事。

这五个工程合在一起,才让「分类分级作为统一识别层」从一个愿景变成可落地的工程方案。每一项都是真实的技术挑战,但每一项的回报也都是结构性的——它直接重塑了数据安全的工程范式。

写在最后

回到本文开头那个问题——分类分级做完之后,真正的价值是什么?

如果答案停在「加密、脱敏、访问控制」,那分类分级是一份昂贵的合规文档。

如果答案延伸到「让数据走到哪,识别就跟到哪,保护就跟到哪」,那分类分级是数据安全的统一识别层——所有设备、所有环节、所有策略的共同底座。

分类分级真正的价值,不在它做完之后,而在它如何贯穿数据的全生命周期、如何统一所有数据安全设备的识别语言、如何承载监管要求的全链路保护。

人行令 3 号已经把这条路径画好了——从分级标识到加密保护、从终端管控到流转管控,每一步的判断都建立在「分级标签」之上。监管端的图景已经清晰,工具端的演进只是时间问题。

对机构而言,关键问题已经不是「要不要做分类分级」,而是「我做的分类分级,有没有能力支撑全网统一的数据安全管理」。

下一期我们会进一步展开——分类分级如何驱动数据的存储分布、生命周期管理、跨域流动控制。这是统一识别层落地之后的第一组具体应用。

—— AiDClass 团队 · 模界数智