📚 课程目录第3章数据分类的基础方法

3. 数据分类的基础方法：按业务、按敏感度、按合规要求分类

说实话，很多团队刚开始做数据分类时，最容易犯的毛病就是「一把抓」。

恨不得把所有属性都塞进一个分类维度里。结果呢？分类标准打架，业务部门看不懂，安全部门用不上。

我个人习惯是把分类方法拆成三个独立维度。就像搭积木，每个维度解决一个问题。咱们一个一个来看。

3.1 按业务分类：让数据回到它该待的地方

什么叫「按业务分类」？说白了，就是问一句：「这数据是干嘛用的？」

我在项目中遇到过一家金融公司，他们把所有客户数据都贴上了「敏感」标签。听起来很安全对吧？但业务部门根本没法干活——连客户姓名都走审批，流程卡死。后来我帮他们重新按业务域梳理，问题一下就解决了。

常见的业务分类维度包括：

业务域：客户域、产品域、交易域、风控域、人力域……
数据主题：客户基本信息、账户信息、合同信息、日志信息
数据流转阶段：采集、传输、存储、处理、交换、销毁

举个例子。一个电商系统的订单数据，按照业务域就属于「交易域」，数据主题是「订单信息」，生命周期里它正在「存储」阶段。每个阶段的安全要求是不一样的——存储时加密，传输时也要加密，但处理时可能需要在内存里解密。你想想看，如果不按业务分类，这些细颗粒度的控制根本落不下去。

我的一点经验：业务分类最好让业务部门的人来主导。安全团队只给框架，具体标签让业务自己贴。他们最清楚每张表、每个字段背后是什么场景。

3.2 按敏感度分类：给数据评个「危险等级」

敏感度分类，这是安全人员的老本行了。但千万别搞成「一刀切」——所有数据都标成「机密」等于没标。

我记得第一次做数据安全治理时，甲方领导要求「全部打上最高级」。我当时就说：「您这么搞，最后一定是所有标签都形同虚设。」 因为业务部门会发现：反正什么都审批，那我索性批量跳过流程。嗯，后来他们还是按我的建议做了分级。

最常见的敏感度分级体系是四级制：

敏感度等级	定义	典型示例	基本管控要求
公开	可无条件对外发布	官网产品介绍、新闻稿	无需保护
内部	仅限公司内部使用	内部通讯录、部门制度文件	访问控制、禁止外发
敏感	泄露会对公司或个人造成中等损害	员工工资、项目投标价、未公开财务数据	加密存储、审批查看、脱敏使用
机密	泄露会造成严重法律或商业风险	客户身份证/银行卡号、核心算法源码、董事会决议	强加密、最小权限、全程审计、禁止下载

这里有个坑：敏感度不能光看「数据本身」，还要看「上下文」。同样一条手机号，在你的CRM系统里可能是「敏感」，但在脱敏后的测试环境里可能只是「内部」。我曾经在项目里遇到过测试库被拖库的事，原因就是运维把所有库都按「敏感」级别做了同样的防护——结果反而忽略了真正该重点保护的生产库。

  核心原则：敏感度标签是「动态」的。数据脱离原始上下文后，敏感度等级可以降级。比如脱敏后的数据，就不要再按「机密」管了。

3.3 按合规要求分类：别让法务找上门

按合规分类，这是最近几年才被重视起来的维度。为什么？因为监管真的在罚款啊。

GDPR 最高罚全球营业额的 4%，中国的《数据安全法》《个人信息保护法》也不是闹着玩的。所以分类时必须问：「这数据受哪部法规管？」

常见的合规维度包括：

个人信息：受《个人信息保护法》监管，进一步细分为一般个人信息和敏感个人信息
重要数据：受《数据安全法》监管，通常由行业主管部门定义目录
核心数据：涉及国家安全，监管最严
跨境数据：涉及出境时触发安全评估

举个例子。你在做一款出海App，用户在欧洲。那这批用户的邮箱地址就同时属于「个人信息」和「跨境数据」。既要满足《个人信息保护法》的告知-同意要求，又要符合 GDPR 的跨境传输机制。只按敏感度标一个「敏感」根本不够用。

我曾经踩过这个坑：把合规标签挂在敏感度标签下面，以为「敏感」已经包含了「个人信息」。结果法务审计时发现，有些一般个人信息（比如用户头像）根本没被识别出来。合规分类必须是独立标签，不能是被包含关系。

3.4 三个维度怎么协同？

你可能会问：那具体落地时，这三个维度怎么一起用？总不能给一条数据打三个标签就完事吧？

我个人习惯用「分类矩阵」的思路。业务分类给出数据在哪、叫什么；敏感度分类给出要多小心；合规分类给出要遵守什么法。三者在实际系统中可以并存：

数据资产元数据示例：
{
  "数据名称": "客户身份证号",
  "业务分类": { "业务域": "客户域", "主题": "身份信息" },
  "敏感度": "机密",
  "合规标签": ["敏感个人信息", "重要数据", "跨境数据"],
  "管控策略": {
    "存储": "AES-256加密",
    "传输": "TLS 1.3",
    "访问": "仅风控审批可查，脱敏展示",
    "出境": "需通过安全评估"
  }
}

下面这张图可以帮你理清三个维度的关系：

落地小建议：在数据资产目录系统中，把这三个维度做成三个独立的下拉标签。别合并成一个字段。合并了就没法做灵活的策略推导了。

3.5 实际项目中的避坑指南

做数据分类时坑不少。我挑几个最常见的说说：

分类粒度太粗或太细。粒度太粗（比如整个数据库标一个等级）会导致策略「一刀切」，该放的不放、不该放的放。太细（每个字段都标）会让管理和维护成本爆炸。一个比较实用的经验是：以「表」为基本单元做业务和合规分类，以「字段级」做敏感度分类。
分类标准互相矛盾。比如按业务分类里写了「客户信息」，按合规分类里写「一般个人信息」，按敏感度分类里却标了「机密」。如果客户信息里只包含姓名和电话，那敏感度顶多算「内部」，不应该标「机密」。所以三个维度必须对同一数据的定义保持一致。我一般会在元模型中做交叉校验。
忽视「动态降级」。数据在生命周期里是会变的。原始订单数据是「敏感」，但过了 5 年订单早就归档了，可能就降成「内部」了。我见过很多企业的分类标签「一锤子买卖」，后来数据量大了，想改都改不动。

曾经有个客户，把 3 年前的历史交易数据全部标成了「机密」。结果每次做数据分析都要走审批流程，业务部门怨声载道。后来我们花了两周时间重新梳理生命周期，把超过 2 年的历史数据降级为「内部」，审批量减少了 80%。
记住：分类不是刻在石头上的，要定期复审。

好了，这一章的内容就这些。三个维度——业务、敏感度、合规——是数据分类的「三驾马车」。别只盯着其中一个，也别把它们搅在一起。分开定义，协同使用，才能让安全策略既精准又不妨碍业务。