4. 数据分类维度：业务、技术与敏感性三重视角
聊到数据分类，很多团队第一个反应就是「按敏感性分」。这没错，但不够。
我接触过不少客户，一开始就急着打标签：这个字段是敏感，那个字段是公开……结果呢？技术侧落地时发现，根本不知道哪些数据属于哪个业务线，哪些数据该存到哪个库里。分类直接卡在半路上。
所以，我个人习惯把数据分类分成三个维度同时推进：业务维度、技术维度、敏感性维度。这三者像三根柱子，缺一根都站不稳。
4.1 业务分类维度：谁在用，用来干嘛？
业务分类是所有分类的起点。说白了，你要先搞清楚数据从哪来、到哪去、归哪个部门管。
我建议用一个简单的三层结构来走：
- 一级分类：按业务域分。比如客户域、产品域、交易域、风控域。
- 二级分类：按业务子域或业务流程分。比如客户域下面再拆成客户信息管理、客户营销、客户服务。
- 三级分类：按具体数据实体分。比如客户信息管理下面，就有客户基础信息表、客户联系信息表、客户账户视图。
为什么要这么细？
因为只有落到三级，你才能知道这张表是谁的业务资产，出了事找谁问责。
避坑指南：
- 别把业务分类做成「组织架构图」——部门改名了不代表业务变了，数据跟着组织架构改，你累不累？
- 我见过一个案例：一家银行把「对公客户」和「零售客户」分开，但CRM系统里对公有企业、零售有个人，混在一起，分类根本对不上。经验：业务分类要围着数据实体走，别围着部门走。
4.2 技术分类维度：数据长什么样、在哪存？
有了业务维度的蓝图，下一步就要看技术视角了。
技术分类主要解决两个问题：这份数据是结构化还是非结构化的？它存在 RDBMS、NoSQL、还是文件系统里？
我一般把技术分类切这么几层：
| 技术分类层次 | 维度 | 常见类别 |
|---|---|---|
| 第一层 | 数据结构 | 结构化、半结构化、非结构化 |
| 第二层 | 存储形态 | 关系型数据库、NoSQL、对象存储、云数据湖、本地文件 |
| 第三层 | 处理类型 | OLTP、OLAP、流式处理、批处理 |
举个例子：
- 一份客户订单表（结构化）存在 MySQL（RDBMS）里，属于 OLTP 场景。那它的技术标签就是：
结构化 | 关系型数据库 | OLTP。 - 一份用户行为日志（半结构化 JSON）存在 HDFS 下的数据湖里，按天跑批处理。技术标签就是：
半结构化 | 数据湖 | 批处理。
为什么要分这么细？因为不同技术类型的分类分级策略完全不同。
我之前有个项目，所有数据一股脑全打上「内部一般」，结果 MongoDB 里存的敏感明文日志，因为没做额外的技术分类，审计根本揪不出来。后来补充了「存储形态」这个维度，才把云存储里的非结构化数据单独拿出来做细粒度分级。
4.3 敏感性分类维度：数据到底有多「重」？
好，前面两条线串完了，最核心的敏感性分类就登场了。
很多人以为敏感性分类就是「内部公开」「敏感」「绝密」三级，但实际落地你会发现，光分三级根本不够用。
我推荐一个五级细分法：
| 等级 | 标识 | 举例 | 管控基调 |
|---|---|---|---|
| L0 | 完全公开 | 官网商品描述、公开报告 | 不设限，但必须防篡改 |
| L1 | 内部公开 | 公司制度、内部文档 | 仅限内部员工，不向外发 |
| L2 | 内部敏感 | 薪资、绩效、部门财务 | 按需授权，加密存储 |
| L3 | 高度敏感 | 身份证、手机号、信用卡号 | 强加密+脱敏+审计 |
| L4 | 绝密 | 密码、密钥、商业核心算法 | 最小权限+物理隔离+全链路监控 |
嗯，这里要注意：L2 和 L3 的边界最容易打架。我有一次在金融项目里，一群人吵了半天：「白名单客户的手机号算 L2 还是 L3？」我的建议是，用数据内容来判断，而不是上下文。手机号只要是个体可识别信息，就上 L3，不用分什么 VIP 客户和普通客户。
避坑指南：
- 有些团队喜欢把「敏感性分类」直接钉在数据表上。但我建议，你要同时考虑「静态敏感性」和「动态敏感性」。比如一张订单表，客户姓名是 L3，收货地址是 L2，你要做字段级的敏感性标签，别整张表一刀切。
- 我之前犯过一个错：给 CSV 文件打标签时，只看了文件名「运营报表2023Q1」，就标了 L1。结果文件里夹了用户手机号字段，直接翻车。从那以后，我要求所有非结构化文件必须扫描内容再定级。
4.4 三者的联动关系
这三个维度不是各自独立的，你得把它们串起来。我画过一张图，能快速讲明白这个逻辑，下面把它转成 SVG，你看一眼就懂了。
你看明白了吧？
业务分类决定了「谁在用」——这是权责基础。技术分类决定了「数据长啥样、在哪」——这是管控的物理条件。敏感性分类决定了「什么等级、怎么管」——这是安全策略的依据。
三者串起来，才是一套可直接落地的分类体系。