题干与适用场景
公司把业务数据存放在对象存储、湖仓表和数仓中，分析师通过 SQL、Spark 和 BI 工具访问。当前权限靠人工工单和各引擎本地账号维护，离职撤权滞后，审计时无法还原跨账户查询。目标是自助申请、最小权限、列/行级保护、紧急访问和统一审计。
请设计数据访问治理层：如何分类和标记数据，谁能批准，策略在哪里执行，怎样覆盖多个引擎，如何处理 break-glass、撤权、缓存和导出，以及怎样证明“允许”和“实际读到”都可审计。核心考察数据平台治理与可运营性，因此归入 data。
面试官考察点
面试官看你是否把治理拆成目录、策略、执行、证据和运营闭环，而不是只说“加 RBAC”。高质量回答会区分身份、目的、资源标签、行列过滤和脱敏，并说明策略决策点与执行点的边界。
还要考虑跨服务一致性：同一用户从 Athena、Spark、BI 或导出任务访问时，授权和审计字段不能丢失。审计日志要能防篡改、可检索、有保留策略，并覆盖拒绝、管理员变更和紧急访问，而不只记录成功查询。
回答前需要澄清的问题
- 数据源、引擎、身份提供商和跨账户边界有哪些？
- 哪些列属于 PII、财务或受合同限制的数据，分类由谁维护？
- 访问是按角色、属性、用途、租户还是行列过滤组合决定？
- 审批是一次性、定期续期还是每次查询都需要？
- 紧急访问的最大时长、审批人和事后复核是什么？
- 能否记录实际扫描范围、返回行数、导出目标和服务身份？
30 秒回答框架
“我会先建立带 owner 的数据目录和敏感标签，再把用户身份、团队、用途、地区和资源标签输入统一策略决策点。执行点在各引擎或数据代理处落实列/行过滤和脱敏，审批产生有期限的授权。所有允许、拒绝、策略版本、查询资源、服务身份和导出动作写入集中且防篡改的审计流；紧急权限自动过期并触发复核。最后用撤权、跨账户、缓存和策略漂移演练证明实际访问与日志一致。”
分步骤深入解答
先做数据资产清单：表、列、文件路径、主题、租户和派生数据都要有 owner、分类、来源、保留期限和允许用途。标签不能只靠一次扫描； schema 变更、字段新增和业务规则变化都要触发复核。对无法确定的敏感字段采用保守标签，避免先开放后补救。
把授权拆为决策与执行。策略决策输入主体身份、组、属性、用途、设备/网络条件、资源标签和环境；输出允许、拒绝、过滤条件、脱敏规则、策略版本和过期时间。执行点可以是数据代理、引擎插件或表格过滤器，但必须保证绕过一个入口不能读到原始对象存储文件。
自助申请流程应展示数据用途、字段范围、期限和责任人。低风险、预批准用途可以自动授予短期角色；敏感数据需要数据 owner 或合规审批。授权采用最短期限和可续期机制，离职、团队变更和项目结束都触发撤权。把审批记录与实际策略版本关联，避免“工单批准了，但线上策略没变”。
行列级保护要说明语义：分析师可能看到脱敏邮箱和聚合结果，但不能通过 JOIN、导出或错误消息重建原值。租户过滤条件必须由可信身份注入，不能由用户提交一个 tenant_id 就获得访问。对导出、临时表、缓存和物化视图设置同等策略，避免原表安全而副本裸奔。
审计事件至少包含主体、有效身份链、目的、资源、列/行过滤结果、策略版本、引擎、查询或作业 ID、时间、来源账户、返回/扫描规模、导出目标和允许/拒绝结果。把事件写入低权限写入、受控读取的不可变存储，使用校验和或版本链检测删除和篡改。拒绝事件与管理员策略变更同样重要。
跨引擎和跨账户访问要传递原始用户与服务身份，不能只记录一个共享 ETL 角色。服务代用户访问时保留 delegation chain；跨账户事件同步到资源拥有方。对无法传递上下文的旧引擎，先隔离为高风险路径或限制数据范围，而不是宣称统一审计已完成。
设计 break-glass：只给经过强认证的少数角色，必须填写原因、自动过期、实时告警和事后复核；紧急权限不能绕过审计。策略发布采用版本、灰度和回滚，监控授权拒绝率、越权尝试、撤权延迟、无 owner 资产、审计缺口和高风险导出。定期用合成身份和蜜罐列验证“能否读到”与“是否被记录”。
高质量示范回答
“我会先建立数据目录、敏感标签和 owner，覆盖原表、派生表、对象路径和导出副本。策略决策点接收主体身份、团队、用途、地区和资源标签，返回允许、拒绝、行列过滤、脱敏规则、策略版本与过期时间；执行点部署在数据代理或引擎插件，并确保对象存储不能被绕过。
申请流程要求用途、范围、期限和责任人，敏感访问需要 owner 审批，所有授权短期化并在离职、项目结束时撤销。行列策略也应用于临时表、缓存和导出，避免通过 JOIN 或错误消息重建原值。
审计事件保留用户与服务身份链、资源、策略版本、引擎、查询 ID、过滤结果、规模、导出目标和允许/拒绝结果，写入不可变存储。Break-glass 自动过期、告警并复核。上线前用跨账户、撤权、旧引擎、缓存和蜜罐测试，证明实际读到的数据与审计记录一致。”
常见错误
- 只设计 RBAC → 无法表达用途、地区和列级限制 → 组合身份、属性、资源标签和过滤规则。
- 只保护查询引擎 → 用户绕过引擎读取对象存储 → 统一入口并封锁原始路径。
- 把共享 ETL 账号当作用户 → 审计无法追责 → 保留 delegation chain。
- 只记录成功查询 → 越权尝试和策略漂移消失 → 记录拒绝、变更和紧急访问。
- 授权永久有效 → 项目结束后仍能访问 → 最短期限、续期和自动撤权。
- 只保护原表 → 缓存、导出和物化副本泄漏 → 对所有派生路径执行同一策略。
- Break-glass 绕过审计 → 紧急通道成为后门 → 强认证、原因、自动过期、告警和复核。
- 只测策略结果不测实际数据 → 过滤器可能被绕过 → 用合成身份、蜜罐列和导出演练验证。
追问及应对
追问一：RBAC 和 ABAC 怎么选？
稳定团队边界可用角色，动态用途、地区、数据标签和时间条件需要属性。实践中通常组合两者，并限制策略复杂度与评审范围。
追问二：如何防止用户通过聚合重建敏感值？
限制小样本聚合、JOIN、差分查询和导出频率，必要时做阈值或噪声处理。具体规则依数据敏感度和业务准确性要求验证。
追问三：缓存里的数据怎么审计？
缓存键绑定主体和策略版本，记录填充与读取的身份链，撤权或版本变化时失效。无法携带用户上下文的共享缓存应禁止存敏感结果。
追问四：日志本身含有敏感查询内容怎么办？
记录结构化资源标识和摘要，避免保存完整 SQL、参数和原始数据；对审计字段分级保护、加密、限权和设置保留期限。
追问五：旧引擎不支持行列权限怎么办？
隔离旧引擎、只提供预过滤视图或迁移到代理路径，并把它标记为审计覆盖缺口。不能用“团队约定”替代执行控制。
追问六：如何衡量治理系统没有拖慢分析？
同时监控授权决策延迟、查询 p95、拒绝误报率、缓存命中和审批时延；低风险决策可缓存，但策略版本或身份变化要立即失效。
追问七：为什么要记录策略版本？
同一查询在策略更新前后可能得到不同结果。版本让审计能解释当时为何允许、拒绝或过滤，也支持回滚和事故复盘。