6.3 安全与访问控制

6.3 安全与访问控制

本节摘要：数据安全不是一道墙，是一套分级门禁：凭据怎么管（最外层）、账号权限怎么分（仓库层）、敏感列怎么收敛（模型层）、行为怎么审计（最内层）。dbt 不自带安全系统，但它的工作方式——配置即代码、环境可分离、分层可隔离——恰好是落实这四层门禁的理想载体。本节给一套可直接落地的分级方案，并把它与前五章的机制串联起来。

数据也有门禁

多数数据事故不是黑客干的，是自己人干的：用生产账号在本地随手一查、把含密钥的配置提交进仓库、离职员工的账号没回收、敏感手机号出现在十张宽表里。这些事故的共同点是边界不清——谁能碰什么、在哪里碰、碰了谁知道，都没有明确的答案。

访问控制就是把这些答案写成规则。dbt 项目里，安全设计落在四个层面，层层向内收缩暴露面：

四层的关系是漏斗：外层收窄入口，内层收窄暴露，审计兜住所有层的漏网之鱼。

第一层与第二层：凭据与角色

凭据管理的落地在 5.1 节已经立了规矩，这里补全实现细节：版本库里只存配置模板，真实凭据由环境变量注入；每个环境（开发、集成、生产）用各自的账号，不复用；账号按人分配、按项目授权，共享账号是审计的大敌——出了事查不清「是谁」。

角色划分借用 5.1 节的环境隔离，给出三角色基线：

角色基线（示意）
- 数据工程师：开发环境读写；集成环境读写；生产环境只读
              （生产写入只走部署账号与流水线）
- 分析师：开发环境读写自己区域；生产环境只读报表层模式
- 应用与 BI 服务账号：只读指定模式，权限按消费清单逐表授
​

两个设计意图值得点破：其一，人的账号在生产只读，写入能力只属于流水线使用的部署账号——这是「生产变更只能来自流水线」的权限化表达；其二，分析师只读报表层，不开放贴源层——不是不信任，而是让消费面收敛在文档与口径最完备的那一层，也顺便挡住「绕过分层直接查原始表」的口径漂移（1.3 与 3.1 节的伏笔在此收拢）。

第三层：敏感列收敛

这是 dbt 分层结构送给安全的一份厚礼。思路：敏感数据在贴源层就该被处理，不让它裸着流向下游。

落地手法是「贴源层脱敏、下游不落地」：清洗层模型里，手机号、身份证号这类直接标识符要么脱敏（哈希、掩码），要么干脆不透传；确有业务需要的场景（如客服工单核实身份），单独建一个受限模式存放解敏视图，授权收窄到具体角色。分层结构的问责边界因此清晰：下游所有模型只能拿到清洗层给它的形态，任何下游出现敏感明文，都是清洗层闸门没关紧，一处修复全链生效。

对照「不加收敛」的形态就能看出价值：敏感列随 JOIN 逐层扩散，三个月后在十几张宽表里随处可见——想收敛时,每张表都要动，等于重做一遍数据血缘审计。收敛的时间窗口就在贴源层，越晚越贵。

第四层：行为审计

前三层是预防，审计是追责与发现。最低成本的起点：仓库侧开启查询日志与访问日志（各家云仓库都有对应能力），保留期按合规要求定。审计回答的问题很朴素：谁在生产报表演化模式下跑过导出、哪个账号凌晨三点扫了全库、离职员工账号是否还有活动。

把审计与告警接起来是进阶动作：对生产敏感模式的访问设异常检测（非工作时段、超常规扫描量），异常即告警。多数团队在这一层投入有限，这没关系——前三层做扎实，第四层的压力天然就小；反过来只做审计不做收敛，等于装了摄像头却开着大门。

权限方案的两个落地疑问

团队小，四层都要做吗

不必，但顺序不能乱。最小可用集是第一层加第二层：凭据不进库、人的账号在生产只读——这两条成本几乎为零（都是配置纪律而非建设工程），却挡住了最高频的两类事故。第三层（敏感列收敛）的紧迫度取决于数据里有没有直接标识符与合规要求：有个人信息或行业合规约束的，它从「可选项」升为「开工项」，且必须赶在数据扩散之前做（本节警告过的复利）。第四层（审计）在团队小时可以只开最低配置的日志保留，等规模与合规压力上来再补工具。一句话版本：一二层是纪律，从第一天开始守；三层看数据性质，四层看组织规模。

分析师只读报表层，临时要查明细怎么办

这是权限方案最常收到的反弹：「我就查个明细还要提申请？」堵死不如开门——开一扇受控的门。两个可行做法：其一，给报表层补一张「分析用明细宽表」，把常用的明细字段（脱敏后的）以物化形式放进报表层模式，分析师的自助查询落在这一张表上，扫描量可控、口径有文档；其二，走临时授权流程——限时（比如四小时）、限表、自动回收的临时只读权限，事后在审计日志里留痕。两种做法的共同点是承认「查明细」是正当需求，把它纳入边界管理，而不是逼着人去借越权账号。权限设计的成色，恰恰体现在这些边缘需求的处理上。

凭据泄漏了，应急顺序是什么

按「止损、换锁、查监控」三步走。止损：立即在仓库侧吊销泄漏的凭据——注意不是改代码里的引用，是让凭据本身失效；部署暂停，改用应急凭据恢复调度。换锁：评估泄漏范围时遵守一条铁律——凭据只要进过版本历史，删掉文件不等于删掉历史，一律当作已永久泄漏，全部轮换。查监控：调审计日志，看泄漏窗口内该账号的全部活动，重点核对非例行时段的导出与越权扫描，有痕迹按安全事故流程处理。这套顺序值得在平时演练一遍：泄漏时刻的慌乱程度，取决于动作有没有排练过，而不是取决于手册写得多细。

一个权限事故的复盘

背景：某团队一位分析师为了排查报表差异，用工程师分享的部署账号直连生产，执行了一条全表扫描的修正语句，误更新了几百行。事故本身损失可控（备份回滚），复盘时暴露的问题链才是重点：部署账号被共享（违反第一层）、人手在生产有写入通道（违反第二层）、敏感修正无审批记录（第四层缺失）。

操作与结果：团队按四层逐一整改——部署账号改为仅流水线持有，工程师的生产写入权限收回，修正类操作引入双人确认并留痕，敏感模式补开了访问日志。整改后同类操作在权限上已不可能发生，而不是「靠大家小心」。

解读：这次复盘的关键认知是事故的根因几乎总是「权限设计向便利妥协」——共享账号图省事、保留写入权限图灵活，都是便利优先于边界的决定。权限设计的正确顺序恰好相反：先定边界，再在边界内找效率，做不到就接受低效——低效是可见的成本，事故是不可见的成本加信任损失。

⚠️ 常见坑：「先跑起来，安全以后再说」在数据项目里的兑现方式通常是：半年后敏感数据已经扩散到几十张表，此时再谈收敛要动的范围是当初的十倍。安全的债和性能的债一样，利息是复利——贴源层的脱敏一天能做完，宽表里的敏感列三个月收不回来。

本节要点回顾

• 四层门禁层层收缩：凭据、角色、敏感列、审计，外层管入口内层管暴露。
• 人的账号生产只读：写入能力归流水线的部署账号，权限是流程的表达形式。
• 敏感列在贴源层收敛：下游只能拿到清洗层给的形态，一处修复全链生效，越晚越贵。
• 分析师只读报表层：消费面收敛在口径与文档最完备的一层，顺带挡住分层绕行。
• 审计是追责与发现：前三层扎实，第四层压力就小；只装摄像头不开门禁等于没设防。

治理三件套齐了。最后一节把镜头拉远：dbt 在整个数据栈里站在哪、和谁衔接、往哪里演进。