数据分类分级：企业数据资产盘点、分类标准与分级策略

各位同学，咱们进入第二章。上一章聊了跨部门共享的总体挑战，这一章得先把地基打牢——数据分类分级。说白了，就是搞清楚你手里到底有什么数据，哪些能随便给人看，哪些得锁进保险柜。

我见过太多项目，上来就画权限矩阵、搞审批流，结果连数据长什么样都没摸清。最后要么权限放得太宽，要么卡得太死，业务部门天天投诉。嗯，咱们先别急着跑，把家底盘清楚再说。

2.1 企业数据资产盘点——先搞清楚你有什么

数据资产盘点，听起来很行政，其实是个技术活。我个人的习惯是，把它拆成三步走：

1. 摸清数据源：数据库、文件服务器、SaaS 应用、API 接口……所有存数据的地方都列出来。
2. 理清数据关系：哪些表是主数据，哪些是交易数据，哪些是日志。别把缓存和归档混在一起。
3. 打上标签：给每个数据对象贴上业务域、敏感度、所有者、生命周期等元标签。

盘点的产出物，通常是一张数据资产地图。我习惯用表格来记录核心字段：

数据对象	所属系统	业务域	敏感度	所有者	存储位置
客户基本信息表	CRM	客户管理	高	销售部	MySQL 主库
员工工资明细	HRM	人力资源	极高	HR 部	Oracle 加密表
产品目录	PIM	产品管理	低	产品部	MongoDB
生产设备日志	MES	生产制造	中	生产部	时序数据库

这张表建好之后，你才能回答一个基本问题：哪些数据需要被保护，哪些数据可以自由流动？

2.2 数据分类标准——业务域 + 敏感度双维度

分类标准怎么定？我建议用两个维度交叉：业务域和敏感度。单看业务域，你分不清哪些是核心资产；单看敏感度，你又不知道数据属于哪个部门。

2.2.1 业务域分类

业务域就是数据在业务上的归属。不同行业不一样，但大体可以归纳为这几类：

• 客户管理：客户资料、合同、订单、售后记录
• 人力资源：员工档案、薪酬、绩效、招聘数据
• 财务与风控：财务报表、审计记录、合规文件
• 产品与研发：产品设计、源代码、技术文档、专利
• 供应链与生产：供应商信息、库存、生产计划、物流数据
• IT 与安全：系统日志、网络拓扑、安全策略、账号权限

你想想看，如果财务部的报表流到了销售部，问题不大。但如果客户名单流到了竞争对手手里……嗯，那就麻烦了。所以业务域只是第一层，还得叠加上敏感度。

2.2.2 敏感度分类

敏感度我习惯分四级，简单直接：

级别	定义	典型示例	泄露影响
L1 公开	可对外发布，无保密要求	产品宣传册、公司年报、公开 API 文档	无影响
L2 内部	仅限公司内部使用，不得外传	内部通讯录、项目计划、培训材料	轻微影响
L3 机密	仅限特定部门或项目组访问	客户合同、薪酬数据、未公开产品设计	较大影响
L4 绝密	极少数人可访问，严格审计	核心算法源码、并购计划、董事会决议	严重影响

2.3 分级策略——从理论到落地

分级标准定好了，怎么落地？我建议用数据分级矩阵来驱动权限策略。说白了，就是给每个数据对象打上“业务域 + 敏感度”的组合标签，然后映射到访问控制规则。

举个例子：

• 客户基本信息（客户管理，L2 内部）：所有员工可读，但不可导出。
• 客户合同（客户管理，L3 机密）：仅销售部 + 法务部可读写，其他部门需审批。
• 核心算法（产品研发，L4 绝密）：仅核心研发团队可访问，每次操作留审计日志。

这里我画了一张图，帮你理解整个分级策略的流转逻辑：

这张图把整个流程串起来了。从盘点开始，到业务域分类、敏感度分级，再到组合标签、权限映射，最后落到审计调整。每一步都环环相扣。

2.4 避坑指南——我踩过的几个坑

讲完理论，聊聊实战中容易翻车的地方。我直接说几个我亲身经历过的：

• 坑一：分级标准太细。我曾经设计过一套 8 级分类，结果没人记得住，最后全标成了“默认”。后来我改成 4 级，配合颜色标签（绿/黄/橙/红），大家一眼就能看懂。
• 坑二：忽略数据血缘。你给原始数据分了级，但经过 ETL 加工后的衍生数据呢？我见过一个案例，原始客户数据标了 L3，但报表团队把数据聚合后忘了重新定级，结果 L3 的数据被当成 L1 发给了合作伙伴。所以，数据血缘里的每一跳都要重新评估敏感度。
• 坑三：分级后不更新。业务是活的，分级也得跟着动。我建议每季度做一次分级复核，尤其是新产品上线、新法规出台的时候。

2.5 小结——打好地基，后面才稳

这一章的内容，说白了就是三件事：盘点清楚、分类合理、分级可执行。你把这三点做到位，后面做权限设计、审批流程、审计追溯，都会顺很多。

我个人习惯，每次启动一个新项目，第一周一定是拉着业务方和 IT 一起过数据资产地图。别急着写代码，先把分类分级对齐。这一步省了，后面全是坑。