一、引言
大数据平台的价值来自开放：更多人能查到数据、复用数据、共享数据，业务分析和算法建模才会变快。但开放也会放大风险，尤其是用户身份、手机号、证件号、账户、位置、医疗健康、金融账户等敏感数据，一旦被越权访问、批量导出或二次传播，后果往往不可逆。
数据安全治理的核心不是“把数据锁起来”，而是把安全控制嵌入数据从采集、入湖、建模、查询、共享到审计的全过程。一个未经治理的数据平台，通常会出现几类问题：
| 风险 | 典型表现 | 后果 |
|---|---|---|
| 资产不可见 | 不知道哪些表有手机号、证件号、账户、位置数据 | 无法制定有效权限和脱敏策略 |
| 敏感度不清 | 所有字段都按普通字段处理 | 高敏数据被普通分析权限覆盖 |
| 权限过粗 | 只按库表授权，缺少行级、列级控制 | 用户拿到整表后看到不该看的记录或字段 |
| 脱敏缺失 | 测试、分析、报表直接使用明文 | 明文在更多链路中扩散 |
| 审计断裂 | 查询、导出、共享、策略变更没有统一日志 | 事后无法追踪责任和影响范围 |
| 合规滞后 | 平台能力与法律、标准要求脱节 | 处理敏感个人信息、跨境、共享时缺少证据链 |
安全治理要解决的不是“谁能不能访问一张表”这么简单，而是持续回答六个问题：数据在哪里、是什么级别、谁能访问、能看到什么形态、访问是否合理、出问题后能否追溯。
二、总体架构
这套数据安全治理架构把元数据、分类分级、权限策略、查询执行、审计日志和合规运营串起来，另外权限策略不要只绑在具体表名上，而要尽量绑定“标签、分级、身份、用途、场景”。
三、敏感数据识别
敏感数据识别是安全治理的入口。如果平台不知道哪些字段是敏感字段，后续的权限、脱敏和审计都会失焦。
在大数据场景中，敏感数据通常不是只存在于原始表中。用户手机号可能从 ODS 表进入 DWD 明细表，再进入宽表、画像表、特征表、报表缓存、临时表和导出文件。
常见识别方式可以分为四类：
| 识别方式 | 适用场景 | 优点 | 局限 |
|---|---|---|---|
| 字段名规则 | phone、id_card、bank_no、lat、lon | 快速、成本低 | 命名不规范时误报漏报较多 |
| 正则与格式识别 | 手机号、邮箱、身份证号、银行卡号 | 对结构化字段有效 | 不能理解语义，容易被脏数据干扰 |
| 统计与采样 | 唯一值比例、长度分布、字符模式 | 可发现命名异常字段 | 对小样本和加密字段效果有限 |
| 机器学习/语义模型 | 字段注释、表名、上下游语义 | 可覆盖复杂语义 | 需要训练、验证和人工复核 |
一个可落地的识别流程如下：
+-------------+
| 新表/新字段入湖 |
+------+------+
|
v
+------------------+
| 元数据采集与字段画像 |
+--------+---------+
|
v
+-------------------------------+
| 规则识别 + 采样识别 + 语义识别 |
+---------------+---------------+
|
v
+---------------+
| 生成候选标签 |
+-------+-------+
|
+-------v-------+
| 数据Owner复核 |
+-------+-------+
|
v
+----------------+
| 写入数据目录/标签 |
+----------------+
|
v
+----------------+
| 触发权限/脱敏策略 |
+----------------+
识别结果不应只写在文档里，而要进入元数据系统，成为权限引擎和审计系统可读取的标签。否则，“治理台账”和“查询控制”会分裂，安全策略无法自动生效。
四、分级分类
分类解决“这是什么数据”，分级解决“泄露后影响多大”。二者结合后，平台才能决定使用什么保护措施。
可以采用“业务分类 + 敏感类别 + 安全级别”的三层模型：
示例分级规则：
| 级别 | 数据示例 | 访问策略 | 脱敏策略 | 审计要求 |
|---|---|---|---|---|
| L1 公开 | 已公开字典、公开地区码 | 默认可读 | 无需脱敏 | 基础日志 |
| L2 内部 | 普通业务统计、非敏明细 | 按部门或项目授权 | 通常不脱敏 | 查询日志 |
| L3 敏感 | 手机号、邮箱、设备标识 | 最小权限、按用途授权 | 默认脱敏 | 访问审计 |
| L4 高敏 | 身份证号、金融账户、精确位置 | 审批、行列级控制 | 强脱敏或加密 | 强审计与告警 |
| L5 核心 | 核心经营指标、重要数据、核心数据 | 严格隔离、专人审批 | 专用环境处理 | 全链路留痕 |
在企业平台中，敏感个人信息不应只靠字段名识别。比如“行踪轨迹”可能由设备 ID、时间戳、经纬度、门店 ID、基站信息组合推导出来；单个字段看似普通，组合后可能变成高敏数据。
五、行列级权限
传统库表权限适合解决“能不能访问表”，但很难解决“能不能访问某些行、某些列、某些值”。例如，区域经理只能看自己区域的订单，客服只能看用户手机号后四位，风控模型可以读取明文特征但不能导出明文样本。只靠表级权限，要么放得过宽，要么切出大量冗余表，最终增加治理成本。
行级权限常见模型如下：
用户身份 + 组织属性 + 数据属性 => 可见行范围
示例：
user = zhangsan
department = 华东大区
role = 区域运营
查询 orders 表时自动追加：
WHERE region = '华东'
AND data_status = 'ACTIVE'
列级权限和动态脱敏常见模型如下：
字段标签 + 用户角色 + 访问场景 => 字段可见形态
phone_number:
- 数据安全管理员：明文
- 客服人员：138****5678
- 分析师：NULL 或 hash(phone_number)
- 外包人员：不可见
从工程实现看，行列级权限通常有三种落点：
| 方式 | 说明 | 适合场景 |
|---|---|---|
| 查询引擎插件 | 在 Hive、Trino、Spark SQL、Impala 等查询链路中拦截和改写 | 多引擎统一治理 |
| 安全视图 | 用 View 封装过滤和脱敏逻辑 | 少量共享数据集、规则较固定 |
| 数据服务网关 | 在 API 层做字段裁剪、脱敏和审计 | 数据服务、指标 API、在线查询 |
六、动态脱敏
脱敏不是简单地把字段替换成星号。一个成熟的大数据平台要支持“同一份数据，不同人、不同场景、不同用途看到不同形态”。
常见脱敏方式如下：
| 脱敏方式 | 示例 | 适用场景 | 注意点 |
|---|---|---|---|
| 掩码 | 138****5678 | 客服查看、工单排查 | 仍可能被组合识别 |
| 截断 | 只保留省市，不保留精确地址 | 区域分析 | 粒度要与分析需求平衡 |
| 泛化 | 年龄转年龄段 | 人群分析 | 过度泛化会损失分析价值 |
| 哈希 | hash(user_id) | 去重、关联分析 | 需要盐值管理，防止字典攻击 |
| 置空 | NULL | 无需使用该字段的场景 | 下游要能处理空值 |
| 加密 | 密文字段存储 | 高敏存储 | 查询和计算成本较高 |
动态脱敏的策略判断可以表达为：
脱敏策略的难点在于“上下文”。同一个字段在生产分析、测试开发、算法训练、客服查询、外部共享中的处理方式不同。平台最好把“用途”和“访问场景”纳入策略输入，而不是只看用户角色。
动态脱敏还要考虑性能。行过滤和列脱敏是在保护数据不可见性和查询优化之间做安全优先选择，可能影响查询性能；其建议包括使用简单 UDF、减少大表上的不同列掩码数量、减少 UDF 参数、优先使用 SQL 而非 Python UDF 等。
七、访问审计
权限和脱敏解决“访问前控制”，审计解决“访问后可追溯”。没有审计，安全治理无法闭环。
审计至少要覆盖五类事件：
| 审计对象 | 关键字段 |
|---|---|
| 查询行为 | 用户、角色、SQL、表、字段、时间、客户端、结果行数 |
| 脱敏命中 | 字段、标签、脱敏方式、策略 ID、是否返回明文 |
| 授权变更 | 谁给谁授权、授权范围、审批单、有效期 |
| 数据导出 | 导出人、导出数据集、行数、字段、目的地 |
| 异常访问 | 非工作时间、大批量查询、高敏字段频繁访问、跨部门访问 |
审计链路可以设计成这样：
审计日志的价值不只是事后追责，还包括策略优化。例如，如果某个高敏字段长期被大量分析任务访问，说明数据模型可能缺少安全替代字段；如果大量用户申请明文权限，说明脱敏后的字段不能满足业务需求，需要重新设计字段粒度或安全视图。
八、合规要求
合规不是法务部门单独完成的文档工作，而是平台能力、组织流程和证据链的组合。映射到大数据平台，可以得到以下工程要求：
| 合规要求 | 平台能力 |
|---|---|
| 分类管理 | 数据目录、敏感标签、分级分类、Owner 机制 |
| 加密与去标识化 | 存储加密、传输加密、Hash、Tokenization、动态脱敏 |
| 合理确定操作权限 | RBAC、ABAC、行列级权限、最小权限、权限有效期 |
| 合规审计 | 查询审计、授权审计、导出审计、策略变更审计 |
| 影响评估 | 敏感数据处理审批、用途说明、风险评估、评估报告留存 |
| 安全事件应急 | 泄露影响范围分析、访问回放、字段血缘追踪、通知机制 |
九、治理落地路径
数据安全治理不要从“大而全平台”开始，而应从高风险链路切入。
推荐路径如下：
阶段一：资产可见
- 接入元数据采集
- 建立表、字段、血缘、Owner
- 识别敏感字段并打标签
阶段二：策略可控
- 建立分类分级规则
- 接入统一权限中心
- 对高敏字段启用列级权限和动态脱敏
阶段三：访问可审
- 采集查询、授权、导出、脱敏命中日志
- 建立异常访问规则
- 形成合规审计报表
阶段四：流程内嵌
- 新表上线前自动识别敏感字段
- 数据共享前触发审批和影响评估
- 权限到期自动回收
- 策略变更可回溯
一个比较稳妥的落地原则是：先治理高敏字段，再治理高风险场景。比如先覆盖手机号、身份证号、金融账户、位置轨迹，再覆盖客服查询、批量导出、外部共享、测试环境同步、算法样本提取。
十、示例
假设企业有一张用户订单宽表：
dwd_user_order_wide
+-------------+---------------+-------------+-------------+-------------+
| user_id | phone_number | id_card_no | region | order_amount|
+-------------+---------------+-------------+-------------+-------------+
| U001 | 13812345678 | 110101... | 华东 | 299.00 |
| U002 | 13987654321 | 310101... | 华南 | 129.00 |
+-------------+---------------+-------------+-------------+-------------+
可以设计如下标签和策略：
| 字段 | 标签 | 级别 | 默认策略 |
|---|---|---|---|
| user_id | 个人标识 | L3 | 分析场景 Hash |
| phone_number | 手机号、个人信息 | L3 | 默认掩码 |
| id_card_no | 证件号、敏感个人信息 | L4 | 默认不可见 |
| region | 区域 | L2 | 可见 |
| order_amount | 交易金额 | L3 | 按角色可见 |
策略示例：
角色：区域运营
行级规则：region in 当前用户负责区域
列级规则：
phone_number -> 138****5678
id_card_no -> NULL
order_amount -> 明文
角色：客服
行级规则：仅可查工单关联用户
列级规则：
phone_number -> 后四位可见
id_card_no -> NULL
order_amount -> NULL
角色：风控算法工程师
行级规则：仅可查审批通过的数据集
列级规则：
phone_number -> hash(phone_number)
id_card_no -> hash(id_card_no)
order_amount -> 明文或分桶
对应查询路径：
用户提交 SQL
|
v
解析 SQL 涉及表与字段
|
v
读取用户身份、角色、项目、审批单
|
v
读取字段标签与数据级别
|
v
注入行级过滤 + 列级脱敏表达式
|
v
执行查询
|
v
记录审计日志与策略命中日志
这样，业务仍然可以使用同一张核心宽表，但不同用户看到的是被安全策略裁剪后的结果。
十一、常见误区
| 误区 | 问题 | 建议 |
|---|---|---|
| 只做库表权限 | 无法控制字段和行范围 | 引入行级过滤、列级权限和动态脱敏 |
| 只靠人工台账 | 策略无法自动生效 | 把分类分级写入元数据和标签系统 |
| 脱敏一刀切 | 分析价值下降，业务绕过平台 | 按角色、用途、环境动态脱敏 |
| 审计只存 SQL | 无法判断敏感字段是否命中 | 记录字段标签、策略 ID、脱敏方式 |
| 只管生产环境 | 测试、临时表、导出文件泄露风险更高 | 覆盖开发、测试、共享和导出链路 |
| 权限永久有效 | 人员转岗、项目结束后权限残留 | 设置有效期和自动回收 |
