Day 25｜Apache Doris 安全与数据治理：认证、RBAC、行列权限、审计、加密与外部认证

课程阶段：第五阶段——运维与治理
建议学习时长：3～5 小时
实验基线：Apache Doris 4.0.8 Stable / 4.1.3 Latest
本文核验日期：2026-08-18

前二十四天，我们已经完成 Doris 的定位、建模、导入、查询优化、存储内核、容量规划、高可用、工作负载治理和故障排查。生产系统继续向前推进时，会遇到一组无法绕开的管理问题：谁能够登录，账号从哪里接入，能够访问哪些库表和列，能否跨租户查看数据，敏感字段怎样展示，链路是否加密，所有访问是否留下证据，数据加工关系能否追溯。

安全建设的价值体现在可证明性。一个合格的方案应当稳定回答六个问题：

1. 当前连接对应哪个真实主体；
2. 主体从哪个网络位置进入；
3. 主体被授予了哪些角色和权限；
4. 查询能够看到哪些行、哪些列和怎样的字段内容；
5. 访问与变更留下了哪些审计和血缘证据；
6. 权限到期、人员离职、系统迁移或安全事故发生时，怎样快速回收与恢复。

在 Day 16 的 SQL 生命周期中，语义分析阶段已经包含元数据和权限检查；在湖仓相关内容中，企业 Hadoop 环境还会涉及 Kerberos。Day 25 将这些分散能力组合成一套完整的安全与治理体系，并给出可以直接执行的实验、评审清单和验收方法。

一、今天要掌握什么

完成本篇后，学习者应具备以下能力：

• 能够解释认证、授权、数据控制、传输安全、审计与血缘之间的职责边界；
• 能够设计 Doris 内置账号、密码策略、来源网段和应急账号；
• 能够使用 Role 将权限组织成稳定的职责模型；
• 能够把权限范围控制到 Catalog、Database、Table、Column、Resource 和 Workload Group；
• 能够通过 Row Policy 实现区域、部门或租户级数据隔离；
• 能够通过列权限、Ranger Masking 和 SQL 脱敏函数保护敏感字段；
• 能够评估 LDAP/AD、LDAPS、Apache Ranger 和 Kerberos 的引入条件；
• 能够启用 MySQL SSL、mTLS 和 FE HTTPS，并验证客户端实际使用了加密连接；
• 能够启用 Audit Log，设计留存、访问控制和长期归档方案；
• 能够理解 Doris 4.x Data Lineage 的事件范围、投递语义和外部插件要求；
• 能够完成一份可审计、可回滚、可复核的生产安全方案。

本文以 Doris 4.x 官方文档为主线。官网在核验日将 4.1.3 标记为 Latest，将 4.0.8 标记为 Stable。具体功能需要继续关注小版本边界，例如 LDAPS 从 4.0.5 起支持，ldap_default_roles 在 4.0.7 与 4.1.3 起支持，Data Lineage 在 4.x 分支从 4.0.6 起提供。

二、从五个安全维度建立整体架构

Doris 官方安全概览将能力划分为身份、授权、数据、传输和审计五个维度。企业数据治理在这五个维度上继续增加分类分级、责任人、申请审批、生命周期、血缘和复审机制。

2.1 身份：确认访问者是谁

身份层负责把客户端提交的用户名、密码、来源地址映射为 Doris 内部的 User Identity。Doris 提供内置账号密码认证，也可以连接 LDAP/AD。身份设计需要关注账号唯一性、来源网段、密码策略、共享账号、服务账号和应急账号。

2.2 授权：确认允许执行什么操作

授权层根据 User Identity 检查权限。内置授权采用 RBAC，权限可以作用于全局、Catalog、Database、Table、Column、Resource、Workload Group、Compute Group 和 Storage Vault。已有 Ranger 平台的企业可以把授权策略集中到 Apache Ranger。

2.3 数据：确认能够看到哪些内容

表级 SELECT 权限只能回答“是否可以查询这张表”。实际生产经常还需要回答：

• 华东团队只能查看 EAST 区域；
• 租户 T001 只能查看自己的数据；
• 普通分析师不能读取工资、证件号和原始手机号；
• 同一列对审计员显示完整值，对业务人员显示掩码值。

Doris 对应提供 Row Policy、Column Permission 和 Ranger Data Masking。SQL 层还提供 DIGITAL_MASKING、MASK 等函数，适合在 View 或接口查询中生成脱敏输出。

2.4 传输：确认链路是否加密

生产环境至少需要检查三段链路：

• MySQL/JDBC 客户端到 FE 9030；
• 浏览器或 HTTP 客户端到 FE Web/HTTP 接口；
• Doris FE 到 LDAP 服务。

三段链路分别对应 MySQL SSL/mTLS、FE HTTPS 和 LDAPS。启用某一项不会自动覆盖其他链路，验收时应逐段核对协议、证书、到期时间和失败行为。

2.5 证据：确认发生过什么

Audit Log 记录登录、查询和修改操作。Data Lineage 从成功的 DML 逻辑计划中抽取表级与列级依赖，发送给外部治理系统。审计帮助追责和调查，血缘帮助影响分析、口径追踪和变更评估。

三、认证与授权的四种组合

Doris 将认证和授权解耦。认证可以使用内置机制或 LDAP；授权可以使用内置 RBAC 或 Ranger。四种组合各有适用范围。

选择时应先确定企业身份源，再确定授权边界。LDAP 解决账号和密码统一，Ranger 解决策略集中管理。两者可以同时使用，也可以独立引入。

四、内置认证：User Identity、来源匹配和密码策略

4.1 User Identity 由用户名和 Host 共同组成

Doris 使用 username@'host' 唯一标识用户。Host 支持 % 模糊匹配；省略 Host 时默认为 %，表示允许从任意地址连接。

CREATE USER 'east_analyst'@'10.20.%'
IDENTIFIED BY "CHANGE_ME_Doris#2026";

来源限制属于账号安全的第一道边界。业务账号应限制在应用网段、跳板机或固定服务地址，@'%' 只适合经过明确评审的场景。

当同一个用户名匹配多个 User Identity 时，具体 IP 的优先级高于域名或宽网段，更窄的网段优先于 %。因此，密码确认无误仍登录失败时，需要执行：

SELECT current_user(), user();

current_user() 表示实际匹配到的创建身份，user() 包含真实客户端地址。两者能够快速发现 Host 匹配偏差。

4.2 默认用户必须立即治理

Doris 默认提供 root 和 admin，初始密码为空。生产安装完成后应立即设置强密码，并限制访问入口。默认超级用户对 Row Policy、列权限和 Ranger Masking 不生效，因此日常业务、BI、ETL 和验证任务都不应使用这两个账号。

建议建立三类管理账号：

• 日常平台管理账号：执行常规集群和对象管理；
• 安全管理账号：管理用户、角色、证书和策略；
• Break-glass 应急账号：离线保存凭据，只在身份平台或授权平台故障时启用。

应急账号的每次使用都要触发告警，并在使用后立即轮换密码和复核操作记录。

4.3 密码策略默认值较宽松

当前内置认证支持以下策略：

生产环境可以按企业规范执行：

SET GLOBAL validate_password_policy = STRONG;

ALTER USER 'east_analyst'@'10.20.%' PASSWORD_HISTORY 5;
ALTER USER 'east_analyst'@'10.20.%' PASSWORD_EXPIRE INTERVAL 90 DAY;
ALTER USER 'east_analyst'@'10.20.%'
FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 30 MINUTE;

ALTER USER 一次只修改一类账号属性，建议拆成多条命令，并把执行结果写入变更单。策略可以通过 SHOW CREATE USER 和 SHOW PROC "/auth/'user'@'host'" 核对。

忘记 root 密码时，可以临时在 FE 设置 skip_localhost_auth_check=true，重启后从 FE 本机无密码登录并重置。这个开关会放宽本地认证，完成恢复后应立即关闭、重启并保留完整审计记录。

五、LDAP/AD：统一身份和组授权

LDAP 集成提供三项核心能力：

1. 使用 LDAP 密码完成登录；
2. 把 LDAP Group 映射为同名 Doris Role；
3. 通过 ldap_default_roles 给所有 LDAP 用户提供基线角色。

5.1 登录优先级和临时用户

启用 LDAP 后，Doris 先使用 LDAP 校验密码。用户在 LDAP 中不存在时，再回退到本地密码。LDAP 校验成功而 Doris 中没有同名账号时，系统为当前连接创建临时用户；连接关闭后临时用户销毁，权限来自 LDAP Group 对应角色和默认角色。

这种机制简化了账号维护，也带来两项治理要求：

• Doris Role 名称要和 LDAP Group 的首个 RDN 对齐；
• 临时用户缺少匹配角色时，仅具备有限的基础访问能力，业务上线前需要完成组映射验证。

5.2 两段链路都要加密

LDAP 客户端插件需要发送明文口令语义。客户端到 FE 应启用 MySQL SSL，FE 到 LDAP 应启用 LDAPS。当前 LDAPS 从 4.0.5 起支持，典型配置如下：

ldap_host = ldap.example.test
ldap_port = 636
ldap_use_ssl = true

自签 CA 需要导入 FE JVM TrustStore。证书路径、别名、密码和权限配置错误会导致 FE 无法连接 LDAP。上线前应演练 LDAP 不可达、证书过期、组成员变化和缓存刷新。

ldap_default_roles 在 4.0.7 和 4.1.3 起支持；本文基线 4.0.8 与 4.1.3 均可使用。角色必须先在 Doris 创建，配置中出现不存在的角色时，Doris 会忽略并记录告警。

5.3 缓存让权限变更存在传播时间

LDAP 用户和组信息会被缓存。组成员刚刚调整后，已有连接和缓存可能仍保留旧权限。生产流程应规定：

• 高风险回收先关闭连接或锁定账号；
• 需要时执行 REFRESH LDAP；
• 验证新连接的 Role 列表和查询结果；
• 记录权限真正生效的时间。

六、内置 RBAC：把权限设计成职责模型

RBAC 的结构是 Privilege → Role → User。Privilege 表示操作能力，Role 表示职责集合，User 表示执行主体。

6.1 常用权限项

Grant_priv 需要重点控制。Doris 2.1.2 以后，授权者除拥有对应层级的 Grant_priv 外，还需要自己持有即将授出的资源权限。这个规则可以降低空壳授权者扩散权限的风险。

6.2 角色设计原则

生产角色应围绕职责和数据域建立，例如：

CREATE ROLE role_east_reader COMMENT "East region analytics";
CREATE ROLE role_etl_writer COMMENT "Approved ETL writer";
CREATE ROLE role_security_auditor COMMENT "Audit reviewer";

角色命名建议包含业务域、职责和权限性质，例如 sales_reader、finance_sensitive_reader、ods_loader、security_auditor。长期避免把项目名、人员姓名和临时需求直接写成角色名，否则几个月后很难判断角色的真实责任。

角色授权完成后再授给用户：

GRANT SELECT_PRIV ON internal.sales.orders TO ROLE 'role_east_reader';
GRANT 'role_east_reader' TO 'east_analyst'@'10.20.%';

6.3 范围越大，暴露面越大

GRANT SELECT_PRIV ON *.*.* 会覆盖所有 Catalog、数据库和表。大多数业务账号可以从 Table 或 Column 层开始。平台级角色确实需要更大范围时，应记录职责、有效期、责任人和复审周期。

一个可落地的权限矩阵至少包含：

6.4 服务账号需要单独治理

ETL、BI 网关、调度平台和数据服务通常使用长期服务账号。服务账号缺少自然人的离职流程，很容易成为多年不变的高权限入口。建议为每个应用或任务域创建独立账号，禁止多个系统共用同一凭据，并记录以下属性：应用负责人、调用系统、来源 Host、目标对象、角色、最大连接数、使用的 Workload Group、凭据保管位置、轮换周期和下线条件。

服务账号的权限应围绕任务链路设计。只负责写入汇总表的任务，可以获得源表 SELECT 和目标表 LOAD；无需 ALTER、DROP 或 GRANT。读取型 API 账号只获得固定 View 或必要列的 SELECT。任务停止、系统迁移、服务重构时，应同步撤销角色和删除账号，避免“应用已经消失，凭据仍然有效”的遗留入口。

凭据管理建议接入企业 Secret 平台。应用启动时动态获取密码或短期凭据，配置文件只保存 Secret 引用。轮换过程需要支持新旧凭据短暂并行，确认连接池全部切换后再回收旧值。审计系统应能够把服务账号映射回具体应用和负责人，否则事件发生后只能看到一个无法解释的技术用户名。

6.5 授权变更要做差异评审

权限变更单不能只记录最终 GRANT 语句。评审应同时展示变更前、变更后和新增暴露面。例如，把 internal.sales.orders 的列级 SELECT 扩大为数据库级 SELECT，会影响当前库内未来创建的表，风险远高于增加一个明确列。自动化平台可以定期导出 SHOW ALL GRANTS，与权限矩阵做差异比较，识别越权、孤儿角色、无责任人账号和临时权限超期。

高风险变更还要加入反向测试：未授权账号应继续失败，原有限制行应继续不可见，敏感列应继续被拒绝或脱敏。只有正向查询成功，无法证明边界仍然存在。