数据分类方法：从业务域到敏感度，再到分级
聊数据分类，我习惯先问一个问题：你为什么要分？如果目标是管权限、控风险，那分类只是手段，分级才是落脚点。但很多人一上来就照着敏感度打标签，结果业务部门根本不认——因为标签和他们的实际场景对不上。
所以，咱们得把分类方法拆开看。我个人经验里，最实用的两条线是：按业务域和按敏感度。两条线交织在一起，才能把数据管明白。
按业务域分类——让数据“找得到家”
业务域分类，说白了就是告诉你“这数据是干什么用的”。比如客户数据、产品数据、交易数据、财务数据……每个业务域的数据，天然有它自己的生命周期和使用习惯。
我在做金融项目时遇到过一件事：风控部门要调取客户交易流水，但数据组把流水归到了“运营日志”里，权限设得死死的。结果风控同学天天打报告申请，效率极低。后来我们按业务域重新归类——交易数据单独成一个域，权限策略跟着业务走，问题就解决了。
常见的业务域分类维度可以参考这张表：
| 业务域 | 典型数据示例 | 典型用户群体 |
|---|---|---|
| 客户域 | 客户档案、联系方式、偏好标签 | 销售、客服、售后 |
| 产品域 | 产品目录、定价、库存、规格 | 产品经理、供应链、仓管 |
| 交易域 | 订单、支付流水、退款记录 | 财务、风控、运营 |
| 财务域 | 账目、发票、成本、利润 | 财务、审计、高管 |
| 运营域 | 系统日志、监控指标、工单 | 运维、开发、SRE |
你看，每个域的数据访问模式完全不一样。客户域的数据需要精细到个人，交易域需要实时查询，财务域则要严格审计。如果不按业务域切分，一个粗放的权限模板根本兜不住。
按敏感度分类——给数据“上保险”
业务域分类解决的是“谁需要”，敏感度分类解决的是“谁不能看”。敏感度分级通常分成公开、内部、敏感、绝密四个档，但不同行业会微调。比如医疗行业会把“患者健康信息”单独拎出来，哪怕它属于敏感级，也要额外加密。
我在帮一家物流公司做数据治理时，发现他们把所有客户姓名都标成了“敏感”。结果电话客服查询地址时需要验证身份，每次都要走审批，一天能接一千通电话，根本跑不通。后来我们根据敏感度定义表做了细化：姓名+地址+身份证号组合才叫敏感，单独一个字段可以算内部级。这才把流程理顺。
判断敏感度的几个硬指标：
- 关联可识别性：这条数据能不能直接或间接识别到自然人？能，就往上提一级。
- 泄露影响面：泄露后会引发财务损失、声誉损失还是法律风险？影响越大，级别越高。
- 监管要求：比如《个人信息保护法》规定敏感个人信息有专门条款，你绕不过去。
敏感度分级不是拍脑袋，要有一个分级矩阵做支撑。矩阵的横轴是数据字段，纵轴是影响等级，交叉点打标。我通常用一个3×3的矩阵做初筛，然后再根据业务场景微调。
分类与分级的关系——别搞反了顺序
很多人问我：分类和分级，谁先谁后？我的回答一直是：先分类，后分级。为什么？
你想，如果不分类，你连数据在哪、归谁管都不清楚，分级就是瞎打标签。反过来，先按业务域把数据圈出来，再在每个域里做敏感度评估，才有针对性。比如“客户域”里，手机号是敏感级，头像图片可能是内部级——同一个域里的字段敏感度都不一样。
我用一张图来总结分类与分级的关系：
从图里你能看到：分类输出的是数据清单，分级输出的是敏感标签，两者必须合并才能生成有意义的权限策略。业务域决定谁有资格看，敏感度决定给不给他看那么多细节。
实践中怎么落地？我常用的三步法
- 圈地：和业务负责人一起，把所有数据按业务域打上第一层标签。这一步产出是“数据字典 + 业务域归属表”。
- 定级：针对每个业务域里的字段，逐个评估敏感度。可以用我之前提的3×3矩阵打初分，再人工复核高风险字段。
- 关联：把分类结果和分级结果合并，形成“业务域-敏感度”的二维矩阵，这个矩阵直接对接后续的权限模型。
举个例子：交易域里的“订单金额”字段，业务域是交易域，敏感度是内部级（因为只有内部员工需要看，不涉及个人隐私）。那权限策略就是：交易域的员工默认可以读，其他人需要审批。而交易域里的“买家手机号”，敏感度是敏感级，策略就变成：只有特定角色（客服主管）才能查看，而且需要脱敏显示。
嗯，到这里你应该能理解了：分类和分级不是两件事，而是同一件事的前后手。分类负责“划清边界”，分级负责“设好门禁”。两个动作少一个，权限模型都会漏风。