📚 课程目录第4章数据分类原则与方法

数据分类原则与方法：从理论到落地的四把尺子

好，我们直接进入正题。数据分类这件事，说白了就是给数据贴标签——但这个标签怎么贴、按什么逻辑贴，决定了后续分级管控的成败。我见过不少团队拿了一份行业目录直接套用，结果业务部门根本看不懂，落地成了摆设。嗯，分类方法选不对，后面全白费。

我个人习惯把分类方法拆成四大类，这四把尺子几乎能覆盖你工作中遇到的所有场景。咱们一个一个来看。

业务维度分类，说白了就是从业务视角给数据定性。它是所有分类方法里最容易被业务接受的一种。为什么？因为它直接用业务语言说话，不用翻译。

核心思路：按数据在业务流程中扮演的角色来划分。典型的分类维度包括：

我在项目中遇到过一家电商公司，他们最开始按数据库命名猜分类，结果把库存台账和客户下单记录混在一起，审计直接被扣分。后来我们改成业务维度重新梳理，销售部门自己就能对号入座，效率翻倍。

我的习惯：业务维度分类一定要拉上业务方一起做。你一个人关起门来编，编出来他们看不懂。我一般会先拉个业务域清单，让每个部门确认“哪些数据是你的”，再把这堆名字直接当分类标签用。

数据属性分类，关注的是数据本身的特征。它不关心数据是谁用的、干什么用的，只管“这数据是什么东西”。

我记得做过一个金融项目的分类手册，其中数据属性维度我们拆得特别细。你想想看，判断一条数据是否敏感，光看业务域还不够，还得看它的格式、内容、密级标识。

为什么会要单独拉出属性分类？因为有些数据光看业务域根本看不出来。比如一张Excel表，标题是“员工信息”，你以为是基础资料，但里面夹了身份证号和家庭住址——这种就得靠属性维度的细粒度扫描才能揪出来。

避坑指南：我曾经在一个大项目的初期阶段只用了业务维度，结果漏掉了一批从第三方API拉回来的非结构化日志。那些日志里藏着大量用户行为数据，但因为没属性维度兜底，全被当成普通运维数据放过去了。所以我的建议是：属性维度一定得配上。

这一点容易被忽略。你以为分类管一次就完了？不是的。数据从产生到销毁，它的敏感度是会变的。

举个例子。一张客户身份证照片，刚生成时是高敏感。但用了一年之后，客户注销了账号，你把它归档了，再之后执行了脱敏处理。每个阶段的分类标签都不一样。

生命周期分类一般分这么几个阶段：

我个人的做法是，在分类字段里加一个“生命周期阶段”标签。比如一条数据的分类结果是 业务域: 客户信息 | 属性: 身份信息 | 阶段: 使用中。这样无论是做权限管控还是加密策略，都能直接按阶段匹配。

关键提醒：生命周期分类不是给你增加复杂度，而是帮你把管控策略做精细。同一个数据，在“使用中”和“归档后”需要的保护强度完全不同，分类必须跟上。

很多行业已经有了自己的分类框架，直接拿过来用，能省一半功夫。

我问过不少安全负责人，他们最头疼的是从零开始画分类树。其实金融、医疗、政务、运营商这些重点行业，监管机构早就给你画好了骨架。你只需要往里填肉就行。

我建议你第一步先去查自己行业的分类标准，然后在那个骨架基础上加业务维度和属性维度的细化。直接套用框架的另一个好处是：监管检查时你拿得出一份“有依据”的方案。

注意：行业框架不是万能钥匙。比如金融体系里对于“交易信息”的定义很严格，但如果你所在的企业只是金融科技的外包服务商，那你的数据跟银行的核心交易数据就不完全等同。分类得根据实际数据内容做二次裁剪。我见过一个外包团队直接把银行的分类表复制粘贴，结果被监管发现分类不符，白忙活两个月。