面试官问'你们怎么做数据安全和权限管理'——出海业务绕不开的数据合规

-- RBAC权限设计
 
-- 角色定义
-- admin：全部读写权限（数据负责人，通常1-2人）
-- developer：开发库读写 + 生产库只读（数据开发）
-- analyst：DWS/ADS层只读（数据分析师）
-- viewer：ADS层只读 + 特定报表（业务方）
 
-- Databricks中的实现
GRANT SELECT ON SCHEMA dws TO analyst_role;
GRANT SELECT ON SCHEMA ads TO analyst_role;
-- 分析师不能直接访问ODS和DWD层（有原始敏感数据）
 
GRANT ALL ON SCHEMA dev TO developer_role;
GRANT SELECT ON SCHEMA ods, dwd, dws, ads TO developer_role;
-- 开发只能写dev库，生产库只读
 
-- 敏感表额外控制
REVOKE SELECT ON TABLE dwd_user_pii FROM analyst_role;
-- PII（个人身份信息）表只有admin和指定开发能看

-- DWD层数据脱敏SQL示例
INSERT INTO dwd_user_events
SELECT
  user_id,  -- 保留（内部标识，非PII）
  -- 手机号用SHA-256哈希，用于去重但不可逆向
  SHA2(phone_number, 256) AS phone_hash,
  -- 邮箱做部分掩码
  CONCAT(LEFT(email, 3), '***@',
    SPLIT(email, '@')[1]) AS email_masked,
  -- IP地址末段置零
  REGEXP_REPLACE(ip_address,
    '(\\d+\\.\\d+\\.\\d+)\\.\\d+', '$1.0') AS ip_masked,
  event_type,
  event_time,
  country_code
FROM ods_raw_events
WHERE dt = '${bizdate}';
 
-- 原则：ODS保留原始值（加密存储），DWD开始脱敏
-- 下游分析师只能看到脱敏后的数据

出海业务的GDPR合规：数据开发要知道的关键点

做出海业务，GDPR（欧盟通用数据保护条例）是绕不开的。数据开发不需要精通法律条文，但需要知道几个核心要求和对应的技术实现：

GDPR要求	通俗解释	数据开发要做什么
数据最小化	只收集必要的数据	ETL中只保留业务必需的字段，不盲目留存所有信息
用户删除权（被遗忘权）	用户有权要求删除他的所有数据	建立根据user_id从所有表中删除相关记录的能力
数据可携带权	用户有权导出自己的数据	能按user_id导出某用户在各表中的所有记录
存储限期	数据不能无限期保存	设置数据过期策略，定期清理超期数据
处理记录	记录数据是怎么被处理的	ETL的血缘和审计日志

其中最有技术挑战的是'用户删除权'。在分布式数仓中，一个用户的数据分布在ODS、DWD、DWS多个表中，要完整删除需要遍历所有包含user_id的表。这就又回到了血缘管理——你需要知道哪些表包含用户数据。

-- 用户数据删除（被遗忘权）的实现思路
 
-- 需要删除的表清单（从血缘系统中获取）
-- 所有包含user_id字段的表：
-- ods_raw_events, dwd_user_events, dwd_orders,
-- dws_user_daily, ads_user_profile
 
-- Delta Lake支持DELETE操作（传统Hive不支持）
DELETE FROM dwd_user_events
WHERE user_id = '${target_user_id}';
 
DELETE FROM dwd_orders
WHERE user_id = '${target_user_id}';
 
-- 聚合表（DWS）的处理比较复杂
-- 如果DWS是聚合数据，删除单个用户后需要重新聚合
-- 或者DWS只保留聚合后的统计值，不包含user_id
-- 后者是更好的设计——DWS层不保留PII字段

面试高频追问

追问一：开发环境能用生产数据吗？

这是一个很实际的问题。理想状态是开发环境不用生产数据，用脱敏后的数据或模拟数据。但现实中很多bug只能用真实数据复现。我的做法是：开发环境可以使用生产数据的脱敏版本——把PII字段全部替换为哈希或掩码值，其他业务字段保留真实值。这样既能复现数据相关的bug，又不泄露用户隐私。我在某出海硬件品牌专门建了一套脱敏复制脚本，每周把生产数据的脱敏版本同步到开发环境。

追问二：你怎么防止数据泄露？

数据泄露的渠道主要有三个：数据库直连导出、代码中硬编码敏感信息、日志打印敏感字段。对应的防护措施：第一，限制直连权限，分析师通过BI工具查询而不是直接连数据库；第二，代码Review时检查是否有硬编码的密码或API Key，用密钥管理服务（如AWS Secrets Manager）代替；第三，在日志框架中配置敏感字段过滤规则，自动掩码手机号、邮箱等字段。最重要的是定期做安全审计——检查权限分配是否合理、是否有异常的数据导出行为。

追问三：离职员工的权限怎么回收？

这是最容易被忽略的安全风险。'我的做法是和HR系统打通——员工离职当天，HR在系统中操作后自动触发权限回收：数据库账号禁用、VPN账号注销、代码仓库权限移除。如果没有HR系统对接，至少要有一个checklist——离职流程中包含'回收数据权限'这一项，由数据负责人签字确认。我在某出海硬件品牌经历过一次离职员工账号没及时回收的事情，虽然没有造成实际泄露，但事后我推动建立了自动化的权限回收流程。'

实战踩坑

我在某短剧出海公司遇到过一次数据安全事件。我们的广告投放数据需要和海外广告平台的API对接，API Key存在代码仓库的配置文件里。有一天，一个实习生在做代码清理时，不小心把包含API Key的配置文件推到了公开的代码分支上（虽然代码仓库是私有的，但这个分支的权限设置不当）。

// 安全事件过程
 
// 问题：API Key出现在代码仓库的配置文件中
// config.py:
// AD_PLATFORM_API_KEY = 'sk-xxxx...xxxx'  ← 硬编码的密钥
 
// 发现：代码Review时被另一个开发发现
// 幸运的是代码仓库是私有的，没有外部泄露
 
// 修复：
// 1. 立即轮换（Rotate）API Key
// 2. 清除Git历史中的敏感信息
//    git filter-branch --force --tree-filter ...
// 3. 将API Key迁移到环境变量/密钥管理服务
 
// 改进：
// 1. 在CI中加敏感信息扫描（git-secrets/truffleHog）
// 2. 代码Review checklist增加'无硬编码密钥'检查项
// 3. 所有密钥统一用密钥管理服务存储

教训：密钥永远不能出现在代码里，这是铁律。一定要用环境变量或密钥管理服务。另外，CI流程中加敏感信息扫描是必要的——靠人工Review不可能100%发现，但自动化扫描可以。

总结

数据安全讲三个层次：访问控制（RBAC最小权限）、数据脱敏（分层脱敏策略）、合规管理（GDPR关键要求）。面试时重点展示你的安全意识——密钥管理、权限控制、脱敏方案。如果有出海业务经验，讲GDPR的用户删除权实现是很好的加分项。最重要的是：数据安全不是安全团队的事，每个数据开发都要有'不泄露用户隐私'的意识和习惯。

下一篇聊一个高段位面试题：面试官问'你怎么做技术方案评审'——写方案比写代码更能体现你的段位

你们团队在数据安全上做得怎么样？踩过什么安全相关的坑吗？评论区聊聊～

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