2. 数据资产梳理与分类分级

数据访问权限治理的第一步，不是急着去配权限，而是先回答一个更基础的问题：我们到底有哪些数据，它们分别有多敏感、多重要？如果连数据资产清单都没有，权限策略就只能凭经验拍脑袋，最终要么管得太死影响业务，要么放得太松留下隐患。本节围绕“识别资产—建立目录—分类分级—映射权限”这条主线，讲清楚具体怎么做。

一、识别数据资产：从系统、库表到字段

数据资产识别要分层推进，避免一上来就陷入海量字段。通常按“业务域 → 系统 → 数据存储 → 库/表 → 字段”逐级下钻。以一家电商公司为例，业务域可划分为交易、用户、营销、财务、风控；交易域下有订单系统、支付系统；订单系统对应 MySQL 实例中的 order_db，其中 t_order 表包含 order_id、user_id、receiver_phone、receiver_address、amount 等字段。

识别时重点关注三类对象：结构化数据（关系库表、数仓表）、半结构化数据（JSON 日志、消息队列中的报文）、非结构化数据（合同 PDF、客服录音、身份证照片、对象存储中的文件）。很多团队只梳理了数据库，却漏掉了对象存储和日志平台，而后者往往藏着大量个人信息。

二、建立数据目录：让资产“可查、可追、可管”

数据目录是资产梳理的沉淀成果，本质是一张可检索的资产台账。它至少要回答：数据在哪里、谁负责、包含什么字段、敏感级别是什么、被哪些应用访问。一个可落地的目录通常包含以下字段：

目录不是静态文档，而应随元数据变更自动更新。实践中常通过采集数据库元数据、数据血缘和访问日志来持续维护，避免“建完就过期”。

三、分类分级：按敏感度与业务价值双维度

分类解决“是什么类型的数据”，分级解决“有多敏感/多重要”。两者结合才能支撑精细化权限。常见分类包括：个人信息、业务经营数据、财务数据、技术数据、公开数据。分级则建议采用四级模型：

• L1 公开：可对外发布，如商品标题、公开价格。
• L2 内部：仅限内部使用，如库存数量、运营报表。
• L3 敏感：泄露会造成较大影响，如手机号、收货地址、订单金额。
• L4 核心：泄露会造成严重危害，如身份证号、银行卡号、支付密码、生物特征。

分级不能只看字段名，还要结合业务价值。例如“用户收货地址”单看是个人信息，但结合订单频次可推断消费能力，业务价值高，应定为 L3。分级结果要落到字段级，因为同一张表里不同字段敏感度可能差异很大。

四、用数据发现工具扫描结构化与非结构化数据

人工梳理难以覆盖海量数据，需要借助数据发现工具自动扫描。对结构化数据，工具通过连接数据库读取元数据和样本数据，用正则、字典和机器学习识别敏感字段。例如扫描 t_order 表时，可配置规则：字段名匹配 phone|mobile 或样本值匹配 ^1[3-9]\d{9}$，命中即标记为“手机号-L3”。

对非结构化数据，工具通常先做文件类型识别和内容抽取，再对文本做敏感信息匹配。例如扫描对象存储中的合同 PDF，抽取文本后匹配身份证号、银行卡号模式；扫描客服录音则需先做语音转写，再对转写文本做识别。扫描结果应输出为清单，包含命中字段、命中规则、样本示例和置信度。

扫描任务示例（伪配置）：
数据源：mysql-prod/order_db
扫描范围：t_order, t_user, t_payment
规则集：PII_CN（手机号、身份证、银行卡、地址）
输出：asset_scan_result.csv
字段：表名, 字段名, 命中规则, 敏感级别, 置信度, 样本脱敏值

五、输出分类分级清单并映射到权限策略

扫描和人工确认后，形成最终的分类分级清单。清单要能直接驱动权限策略，核心映射逻辑是：敏感级别决定访问控制强度。例如：

• L1：可对内部全员开放读权限，无需审批。
• L2：按角色授权，部门内可读，跨部门需申请。
• L3：按最小必要授权，需数据Owner审批，访问留痕，默认脱敏展示。
• L4：严格白名单，需双人审批，强制加密存储与传输，禁止批量导出。

映射时要落到“谁、在什么条件下、能对哪些字段做什么操作”。例如订单服务读取 t_order 时，可访问 order_id、amount，但 receiver_phone 需脱敏为 138****1234；风控服务因业务需要可申请查看完整手机号，但需单独审批并记录访问日志。

完成映射后，还要建立复核机制：每季度对分类分级清单做一次复核，重点检查新增字段、业务变更和权限漂移。只有让清单与权限策略保持同步，数据访问治理才不会沦为一次性项目。