6.3 安全与权限体系

6.3 安全与权限体系

本节摘要：安全圈有个行话叫纵深防御——不指望任何一道闸万无一失，而是让每道闸各拦一段。落到 Doris 就是三道：认证确认"你是谁"，授权圈定"你能碰什么"，脱敏修剪"你能看到什么内容"。本节按一次查询的行进顺序走完三道闸，给出报表团队可直接抄走的落地配置，并划出多租户场景下最常踩的两个坑。

学习目标

阅读完本节，你应当能够：

1. 为企业内网集群选择 LDAP 集成的接入路径并说明其运维收益；
2. 用角色中转的授权结构取代逐用户授权，把权限审计成本降一个量级；
3. 为同一张表给不同角色配置行级过滤与列级脱敏的组合策略；
4. 用审计日志回答"谁在什么时候看过敏感列"的合规质询。

三道闸的地图

一次查询从客户端到结果集，依次穿过三道闸。第一道认证，验证身份的真实性——本地账号密码、LDAP 目录、Kerberos 票据是三种常见形态；第二道授权，判定身份能触达哪些对象——库、表、视图、列，粒度逐级变细；第三道内容修剪——行级策略把不可见的行从结果里滤掉，列级脱敏把敏感值改写成遮蔽形态。三道闸的顺序不能乱：没有可信身份，授权无从谈起；没有授权边界，脱敏只是化妆。

把这张地图记熟，排障时能省大量时间。报表跑不通时先分清卡在哪道闸：连接被拒是第一道，表不存在提示多是第二道，数据"少了"或"打码了"是第三道——第三道最容易被误报为数据质量事故，值班同学对着空荡荡的结果集查了半天分区，其实只是行级策略在起作用。

第一道闸：认证方式的选择

内网自用集群，本地账号最简单，但账号生命周期要人肉管——员工转岗了、离职了，数仓这边的账号往往还活着。企业级环境的正解是把认证委托给统一目录服务：Doris 对接 LDAP 后，用户凭企业账号登录，密码策略、账号禁用、组织变动全部自动同步，数仓侧不再维护第二套口令。接入成本一次性，长期收益是"账号即组织架构"的自动对齐。

更高安全等级的场景（金融、政务、跨域网络）再上 Kerberos：票据机制防重放，通信全程认证加密。它的运维复杂度明显更高——密钥分发、时钟同步、票据续期都要人管——所以不建议一步到位，常见路径是开发测试环境 LDAP 起步，生产核心区按合规要求升级。无论哪种形态，服务账号（BI 工具、调度系统连数仓用的账号）要单独建、最小授权、定期换密，这批账号的泄露面比个人账号更大却最容易被忽视。

第二道闸：用角色中转，别逐人授权

授权模型的演进方向是从"用户-权限"直连转向"用户-角色-权限"的中转结构。直连结构的问题在于组合爆炸：五十个分析师、八百张表，任何一次岗位调整都是一批散落的授权变更，半年后没人说得清某个账号为什么有某张表的权限。中转结构把权限聚合到角色上，岗位对应角色，调整岗位只是换角色：

-- 建角色并授出报表所需的最小权限
CREATE ROLE report_analyst;
GRANT SELECT ON DATABASE dws TO ROLE report_analyst;
GRANT SELECT ON dws.dim_customer TO ROLE report_analyst;

-- 用户只挂角色 不直接持权限
GRANT ROLE report_analyst TO USER 'xiaowang';
​

两条纪律让这套结构长期不烂。其一，权限只授给角色，个人永不直授——例外情况用临时角色并注明到期时间。其二，角色数量克制：按岗位族建角色，一个团队三五个角色封顶；角色一旦细到"某人专用"，就退化回了直连结构。审计收益立竿见影：合规质询"分析师群体能看什么"，查角色定义即可，不用遍历用户清单。

第三道闸：行级过滤与列级脱敏的组合

前两道闸管"能不能进来"，第三道管"进来后看到什么"。行级策略在查询时动态注入过滤条件，同一张表不同人查出不同的行；列级脱敏在投影阶段动态改写，同一列不同人看到不同的值。两者组合才是完整的内容治理：

-- 行级 区域经理只见本区数据
CREATE ROW POLICY rp_region ON dws.fact_sales
AS RESTRICTING
TO ROLE region_manager
USING (region_code = current_user_region);

-- 列级 手机号对普通角色遮蔽中段
CREATE COLUMN MASKING POLICY mp_phone ON dws.dim_customer (phone)
AS MASKING FUNCTION mask_last_n(4)
TO ROLE report_analyst;
​

这套机制最锋利也最危险的特性是对查询方完全透明——用户的 SQL 一个字不变，结果却因人而异。锋利在于多租户隔离、跨部门共享不再需要复制多份表；危险在于结果差异是隐式的，业务方拿两份对不上的数对质时，没人提醒他们权限口径不同。所以落地时配套两条：策略清单集中登记并公示，让"你看到的数经过哪些修剪"可查可答；给报表加数据口径脚注生成机制，把生效策略名自动带进报表页脚。

图 6-3：一次查询穿过三道闸的完整路径

落地清单与两个高频坑

给准备上权限项目的团队一份顺序清单：先统一认证（LDAP 接入一次到位），再收敛授权（建角色、回收直授、公示角色矩阵），最后上内容修剪（先行级后列级，每上一条策略跑一轮回归）。三步的顺序不可颠倒——身份不可信时上的任何策略都是沙上建塔。

坑一，策略与视图叠加导致双重修剪。行级策略套在视图上，视图又建立在带策略的基表上，两层条件叠加后结果集可能空得莫名其妙。约定"策略只贴在一层"（通常贴基表），视图层只做口径加工不做权限。坑二，服务账号成了权限后门。给 BI 工具建的服务账号图省事授了管理员角色，全公司报表都从这个账号出——行级策略对它完全失效。服务账号按数据域拆分、各自最小授权，才能让第三道闸真正闸得住。

常见疑问

问：权限粒度越细越好吗？ 不是。粒度每细一档，策略数量、验证开销与出错概率同步上升——行级策略叠到一张表的多个角色上，排查"为什么少数据"的成本会超过收益。实务的成熟度标志是"能粗则粗"：能靠库级权限解决的不到表级，能靠表级解决的不上行列级，细粒度只留给真正敏感的核心表。

问：怎么排查"用户说少看了数据"？ 固定三步：先查该用户生效的角色集合（角色变更最常见），再查目标表上挂的策略清单（行级条件是否把他的行过滤掉了），最后查脱敏策略（列被遮蔽常被误报为"数据是空的"）。三步走完仍未解释，才考虑数据侧问题——多数时候凶手在权限侧。

本节要点回顾

• 三道闸各拦一段：认证管身份、授权管对象、脱敏管内容，顺序不可乱。
• 认证委托给目录服务：账号生命周期自动对齐组织，告别第二套口令。
• 权限只授角色不授人：岗位对角色，审计查角色，组合爆炸自然消失。
• 策略公示加脚注：透明修剪要配套可查的策略清单，防止口径误会。
• 服务账号单独治理：最小授权按域拆分，别让工具账号变成权限后门。

至此本章三块能力配齐。下一章换到值守视角：当集群指标异常时，运维的手该先伸向哪个开关。