4、数据目录的权限与安全：数据分级分类、访问控制策略、数据脱敏、审计日志

数据目录建好了，元数据也梳理清楚了，团队开始自助取数了。这时候有个问题就冒出来了——安全怎么办？

说实话，我在不少公司见过这种场景：数据目录搭得漂漂亮亮，结果上线第一天，销售部的同事看到了核心财务数据，实习生能下载全量用户手机号。嗯，这可不是我们想要的自助取数。

数据目录的权限与安全，说白了就是解决四个问题：数据该怎么分级？谁能看什么？敏感数据怎么处理？出了问题怎么追溯？ 这一章，我把这些年的经验拆开来讲。

4.1 数据分级分类：安全的第一道防线

数据分级分类，听起来像是个行政工作，实际上它是所有安全策略的基石。你想想看，连数据是什么级别都不知道，怎么定权限？

我个人习惯把数据分成五个等级：

等级	定义	典型示例	访问要求
L0	公开数据	产品介绍、公开报告	全员可访问
L1	内部数据	内部文档、非敏感运营数据	公司内部可访问
L2	敏感数据	用户昵称、订单金额	需授权，可脱敏展示
L3	高度敏感数据	手机号、身份证、邮箱	严格授权，强制脱敏
L4	绝密数据	密钥、支付密码、生物特征	极少数人，禁止导出

分类怎么做？我建议按数据主题来分：用户数据、财务数据、业务数据、技术数据。每个主题下再细分敏感字段。举个例子，用户数据里的「手机号」是 L3，「用户昵称」是 L2，不能一刀切。

4.2 访问控制策略：谁可以看什么

分级分好了，接下来就是定规则。访问控制策略，说白了就是回答三个问题：谁？能看什么？在什么条件下？

目前主流的方式有两种：

• RBAC（基于角色的访问控制）：把权限绑定到角色上，用户通过角色获得权限。适合大部分企业，管理成本低。
• ABAC（基于属性的访问控制）：根据用户属性、资源属性、环境条件动态判断。更灵活，但配置复杂。

我一般建议团队先用 RBAC 打底，等遇到复杂场景再引入 ABAC。比如：

# RBAC 示例：角色-权限映射
角色：数据工程师
  权限：读取 L0-L2 所有表
  权限：读取 L3 表（脱敏后）
  权限：写入 L0-L1 表

角色：数据分析师
  权限：读取 L0-L2 所有表
  权限：读取 L3 表（脱敏后）
  权限：无写入权限

角色：业务主管
  权限：读取 L0-L3 所有表（原始数据）
  权限：读取 L4 表（需审批）

还有一个容易被忽略的点：行级权限。比如销售总监只能看自己团队的业绩，不能看其他团队的。这在数据目录里怎么实现？

我常用的做法是：在数据目录的元数据中记录「数据域」和「数据所有者」，然后在查询时自动拼接过滤条件。比如：

-- 用户查询时，系统自动追加
WHERE department = '当前用户所属部门'

这样用户看到的数据就是「过滤后」的，他自己都不知道被限制了——体验好，安全也到位。

4.3 数据脱敏：敏感数据的「马赛克」

数据脱敏，就是给敏感数据打马赛克。但马赛克怎么打，有讲究。

我把它分成两类：

类型	方式	适用场景	示例
静态脱敏	数据入库前就脱敏	测试环境、数据分发	手机号 138****1234
动态脱敏	查询时实时脱敏	生产环境、自助查询	身份证 110**********1234

在数据目录里，我建议优先用动态脱敏。为什么呢？因为同一个数据，不同人看，脱敏程度可以不一样。比如：

• 数据分析师看用户手机号：显示 138****1234
• 客服主管看用户手机号：显示 13812341234（完整）
• 实习生看用户手机号：不显示（直接屏蔽）

这个逻辑怎么落地？在数据目录的元数据里，给每个字段打上「脱敏策略」标签：

{
  "field": "phone",
  "sensitivity": "L3",
  "masking_rules": {
    "default": "prefix_suffix",  // 保留前3后4
    "admin": "none",             // 管理员不脱敏
    "analyst": "prefix_suffix",
    "intern": "full_mask"        // 实习生完全屏蔽
  }
}

4.4 审计日志：出了事能追溯

安全体系最后一道防线，就是审计日志。说白了，就是记录「谁在什么时候做了什么」。

数据目录的审计日志，至少要记录这些信息：

• 谁：用户ID、角色、IP地址
• 什么时候：操作时间（精确到毫秒）
• 做了什么：查询了哪个表、哪个字段、用了什么过滤条件
• 结果：返回了多少行数据、是否脱敏
• 上下文：会话ID、操作来源（Web端/API/客户端）

我建议日志格式统一成 JSON，方便后续分析：

{
  "event_id": "audit_20250321_001",
  "timestamp": "2025-03-21T14:30:00.123Z",
  "user": {
    "id": "u_10086",
    "role": "analyst",
    "ip": "10.0.1.100"
  },
  "action": "query",
  "resource": {
    "table": "user_profile",
    "fields": ["name", "phone", "address"],
    "filter": "city = '北京'"
  },
  "result": {
    "rows_returned": 500,
    "masked": true
  },
  "session_id": "sess_abc123"
}

有了审计日志，你就能做几件重要的事：

1. 异常检测：比如某个用户突然在凌晨3点批量查询用户手机号，系统自动告警。
2. 合规审计：等保、GDPR 审计时，直接导出日志证明合规。
3. 事后追溯：数据泄露了，能快速定位到人、到操作、到数据。