数据分类分级：把家底摸清楚，才能管得住
说实话，做了这么多年隐私合规项目，我见过太多公司一上来就问「我们要不要做数据脱敏？」「要不要上DLP？」。我的第一反应通常是：你知道自己有哪些数据吗？
连自己家里有多少金条、多少废纸都搞不清楚，怎么谈保护？这就是为什么我始终认为——数据分类分级，是整个隐私合规的基石。这块做不好，后面所有安全控制都是瞎忙活。
为什么必须做分类分级？
你想想看，如果一家医院把所有病患信息都锁在同一个保险柜里，感冒患者的病历和HIV检测报告享受同等待遇，这不是保护，这是资源浪费加管理灾难。
我个人习惯把数据分类分级比作「食材管理」：
- 先分门别类：牛肉放冷藏、酱油放调料架、鸡蛋小心轻放
- 再划分等级：松露和萝卜肯定不能扔同一个抽屉
分类：从业务视角梳理数据资产
分类是个「贴标签」的过程。说白了，就是给每类数据贴上「你是谁、干什么用」的牌子。
我在项目中通常采用两级分类法：先按业务场景粗分，再按数据属性细分。举个例子：
一级分类：客户数据
├── 个人身份信息（姓名、身份证号、住址）
├── 联系方式（手机号、邮箱、微信号）
├── 消费记录（购买历史、充值金额）
└── 行为偏好（浏览记录、点击流）
一级分类：业务运营数据
├── 产品资料（规格、价格、库存）
├── 交易日志（时间、金额、操作人）
└── 内部流程（审批意见、排期计划）
这里要注意一个坑——分类标准要统一。我曾经碰到过一个项目，市场部叫「客户画像」，技术部叫「用户特征库」，法务部叫「个人信息包」。同一个东西，三个名字。后面做权限策略配置时乱成一锅粥。所以我现在都建议：
- 建立统一的数据分类目录，各部门共用一套命名体系
- 每个分类加一个唯一ID，避免歧义
- 定期对分类做复核，业务变了分类也要变
分级：从风险维度确定保护强度
分完类，接下来要分级别。分级关注的是一旦泄露或滥用，会造成多大的损害。
目前业界比较通用的分级模型是五级制（也有人用三级，但我个人更推荐五级，颗粒度更细）：
| 级别 | 定义 | 典型示例 | 保护要求指标 |
|---|---|---|---|
| L5 绝密 | 泄露将造成灾难性影响（如：大规模社会事件、企业破产） | 核心算法源码、密钥管理主密钥 | 加密存储、双人操作、审计全覆盖 |
| L4 机密 | 泄露将造成严重损害（如：重大经济损失、法律诉讼） | 身份证号、银行卡号、病历 | 传输加密、访问审批、脱敏展示 |
| L3 敏感 | 泄露将造成中等损害（如：声誉受损、内部混乱） | 手机号、邮箱、家庭住址 | 权限控制、日志记录、定期审计 |
| L2 内部 | 泄露会造成轻度影响（如：内部效率降低） | 员工工号、部门架构、办公文档 | 基础身份认证、内部共享限制 |
| L1 公开 | 泄露无负面影响或已授权公开 | 公司官网信息、产品宣传册 | 无特殊控制，但需防止被篡改 |
从分类到分级的映射矩阵
分类和分级不是独立的。不同类别的数据，对应的默认级别也不一样。我习惯画一个矩阵表来管理这种映射关系：
| 数据分类 | 默认级别 | 特殊场景升降级条件 |
|----------------|----------|-------------------------------------|
| 个人身份信息 | L4 | 获得用户明示同意后可降为L3 |
| 联系方式 | L3 | 用于营销推送时保持L3，不得降级 |
| 消费记录 | L3 | 聚合统计后可降为L2 |
| 交易日志 | L4 | 脱敏后保留L2 |
| 行为偏好 | L3 | 可用于个性化推荐，但禁止公开 |
| 内部审批意见 | L2 | 涉及商业秘密时升级为L4 |
落地步骤：从零开始的分级实施流程
光有理论不行，得动手干。我分享一个经过多个项目验证的实施流程：
第一步：组建数据治理小组
别让安全部自己关起门来分。叫上业务、法务、技术一起定分类分级标准。谁的业务谁最懂，别替别人做决定。
第二步：盘点数据资产
这是最累的活。你得搞清楚数据存在哪儿（数据库？云盘？员工本地？），格式是什么（结构化？文本？图片？），谁在管。
第三步：打标签试点
选一个核心业务模块做试点。比如先搞定CRM系统中的客户数据。跑通流程再推广到全公司。
第四步：工具化自动化
手动打标签不现实。我建议用数据分类分级工具，配置识别规则自动打标。
# 一个简单的数据分类分级规则配置（YAML格式）
classification_rules:
- name: "身份证号检测"
pattern: "([1-9]\\d{5}(18|19|20)?\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}[0-9Xx])"
category: "个人身份信息"
default_level: L4
action: "自动加密并标记"
- name: "手机号检测"
pattern: "1[3-9]\\d{9}"
category: "联系方式"
default_level: L3
action: "访问需审批"
第五步：持续运营与复核
数据是活的。新产品上线、业务变更，都要重新评估。我习惯每季度做一次分级复核。
常见的工具与自动化手段
手动打标签太累，而且容易出错。我推荐用这些手段提效：
- 正则表达式引擎：检测身份证、手机号、邮箱等固定模式
- AI/ML分类器：基于内容语义的自动分类（适合非结构化数据）
- 数据目录平台：如Apache Atlas、Collibra、阿里云DataWorks
- DB审计与DLP联动：发现未打标的敏感数据自动触发告警