谁动了我的数据——数据权限和安全管理怎么做？

-- 数据分级元数据表
CREATE TABLE meta_data_classification (
  table_name STRING COMMENT '表名',
  column_name STRING COMMENT '字段名（NULL表示表级别分级）',
  security_level STRING COMMENT '安全级别 L1/L2/L3/L4',
  data_category STRING COMMENT '数据类别 PII/FINANCIAL/BEHAVIORAL/PUBLIC',
  mask_policy STRING COMMENT '脱敏策略 NONE/HASH/MASK/ENCRYPT',
  owner STRING COMMENT '数据负责人',
  review_date DATE COMMENT '上次审核日期',
  notes STRING
);
 
-- 示例数据
-- | dim_user | email | L4 | PII | MASK | Wood | 2024-01-01 |
-- | dim_user | country | L2 | PUBLIC | NONE | Wood | 2024-01-01 |
-- | dws_revenue | revenue | L3 | FINANCIAL | NONE | Wood | 2024-01-01 |

-- 基于角色的权限控制（Hive/Databricks语法）
 
-- 创建角色
CREATE ROLE data_analyst;
CREATE ROLE data_engineer;
CREATE ROLE data_admin;
 
-- 给角色分配权限
-- 分析师：只能SELECT DWS/ADS层
GRANT SELECT ON DATABASE dws TO ROLE data_analyst;
GRANT SELECT ON DATABASE ads TO ROLE data_analyst;
 
-- 工程师：可以SELECT和INSERT DWD/DWS/ADS层
GRANT SELECT, INSERT ON DATABASE dwd TO ROLE data_engineer;
GRANT SELECT, INSERT ON DATABASE dws TO ROLE data_engineer;
GRANT SELECT, INSERT ON DATABASE ads TO ROLE data_engineer;
 
-- 管理员：全部权限
GRANT ALL ON DATABASE ods TO ROLE data_admin;
 
-- 把用户分配到角色
GRANT ROLE data_analyst TO USER analyst_alice;
GRANT ROLE data_engineer TO USER engineer_bob;

② 行级权限（Row-Level Security）：同一张表，不同用户只能看到自己负责的数据。比如美国区运营只能看美国的数据，日本区运营只能看日本的数据。

-- 行级权限示例（概念SQL）
-- 通过视图实现行级过滤
CREATE VIEW v_revenue_by_region AS
SELECT *
FROM dws_revenue_daily
WHERE country IN (
  SELECT country FROM user_data_access
  WHERE user_name = CURRENT_USER()
);
 
-- user_data_access 表
-- | user_name | country |
-- | alice | US |
-- | alice | CA |
-- | bob | JP |
-- alice只能看到US和CA的数据
-- bob只能看到JP的数据

③ 列级权限/动态脱敏：敏感字段对特定角色自动脱敏。分析师看到的email是***@***，管理员看到的是真实邮箱。Databricks Unity Catalog和阿里云DataWorks都支持动态脱敏。

审计追踪

权限控制是「事前预防」，审计追踪是「事后追溯」。需要记录：谁在什么时间查了什么表的什么数据。

-- 数据访问审计表
CREATE TABLE meta_access_audit_log (
  audit_id STRING,
  user_name STRING COMMENT '访问者',
  action STRING COMMENT 'SELECT/INSERT/DELETE/EXPORT',
  table_name STRING COMMENT '访问的表',
  query_text STRING COMMENT 'SQL语句',
  row_count BIGINT COMMENT '返回的行数',
  access_time TIMESTAMP,
  client_ip STRING COMMENT '访问IP',
  is_sensitive BOOLEAN COMMENT '是否涉及敏感数据'
);
 
-- 审计分析：发现异常访问
SELECT user_name, table_name, COUNT(*) AS access_count,
  MAX(access_time) AS last_access
FROM meta_access_audit_log
WHERE is_sensitive = TRUE
  AND access_time >= DATE_SUB(CURRENT_DATE, 7)
GROUP BY user_name, table_name
HAVING access_count > 100  -- 7天内访问敏感表超过100次
ORDER BY access_count DESC;
-- 异常高频访问可能是数据泄露风险

常见的数据安全风险

风险场景	影响	预防措施
账号共享/借用	无法追溯真实操作人	一人一账号+MFA认证
数据导出到本地	敏感数据离开安全环境	限制导出+水印+DLP
临时权限忘记回收	离职员工仍有权限	权限自动过期+定期Review
SQL注入/越权查询	访问超出权限的数据	参数化查询+行级权限
数据备份泄露	备份文件被未授权访问	备份加密+访问控制

面试高频追问

追问一：离职员工的数据权限怎么处理？

离职当天HR系统发起账号注销，自动触发所有系统的权限回收——包括数仓查询权限、BI平台权限、数据导出权限。关键是这个流程要自动化，不能靠人工通知。我们的做法是把权限管理和HR系统联动，员工离职后24小时内自动回收所有数据访问权限。另外每月做一次权限盘点——查看是否有已离职员工的账号还未注销。

追问二：怎么防止分析师把数据导出后泄露？

三层防护：一是限制导出——BI平台配置为只能看不能导出，或者限制导出行数（如最多1000行）。二是水印——导出的数据文件自动加上操作人信息的水印，一旦泄露可以追溯。三是DLP（数据防泄漏）——在网络层面检测是否有敏感数据通过邮件、云盘等渠道外发。小公司可能做不了DLP，但限制导出和水印是低成本可以做到的。

追问三：数据安全和数据治理是什么关系？

数据安全是数据治理的一个重要模块。数据治理关注的是「数据怎么管好」，安全关注的是「数据怎么保护好」。两者有交集——比如数据分级既是治理的基础（哪些数据重要），也是安全的基础（哪些数据敏感）。元数据管理为安全提供了数据分类和血缘信息，安全审计则为治理提供了使用情况的反馈。

实战踩坑

我在某知名出海硬件品牌遇到过一次权限管理的事故。有一个实习生在做数据分析时，误操作执行了一条DELETE语句，删除了DWS层一张核心表的最近3天数据。虽然我们有备份可以恢复，但恢复过程花了4个小时，期间核心报表数据为空。

排查后发现问题在于：分析师角色被赋予了DWS层的INSERT和DELETE权限（因为有些分析师需要创建临时表），实习生也被分配了这个角色。

-- 权限改进：细分角色
 
-- 改进前：分析师角色权限太大
-- GRANT SELECT, INSERT, DELETE ON DATABASE dws TO ROLE data_analyst;
 
-- 改进后：拆分为两个角色
-- 普通分析师：只能SELECT
CREATE ROLE analyst_readonly;
GRANT SELECT ON DATABASE dws TO ROLE analyst_readonly;
GRANT SELECT ON DATABASE ads TO ROLE analyst_readonly;
 
-- 高级分析师：可以在个人schema下建临时表
CREATE ROLE analyst_advanced;
GRANT SELECT ON DATABASE dws TO ROLE analyst_advanced;
GRANT ALL ON SCHEMA sandbox TO ROLE analyst_advanced;
-- sandbox是个人沙箱schema，可以随便建表删表
-- 但对生产表没有写权限
 
-- 实习生分配只读角色
GRANT ROLE analyst_readonly TO USER intern_charlie;

解决方案：把分析师角色拆分为只读和高级两种，生产表对所有分析师只开放SELECT权限。需要建临时表的分析师使用个人沙箱schema（sandbox），和生产表完全隔离。改完后再也没出现过误删生产数据的事故。同时对所有DDL操作（CREATE/ALTER/DROP/DELETE）开启审计日志，实时告警。

总结

数据安全管理的核心是「分级-分权-审计-防护」四层体系。面试时能讲清楚数据分级（L1-L4）、RBAC角色权限、行级/列级权限控制、审计日志，再加上一个「权限太大导致误删数据」的踩坑故事，就是满分答案。记住：安全的核心原则是最小权限——只给用户完成工作所需的最小权限。

下一篇是数据治理系列的最后一篇：面试中怎么讲数据治理项目？——STAR法则+数据治理面试答题模板。

你们公司的数据权限管理是怎么做的？有没有出过安全事故？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长