📚 课程目录第2章身份与访问管理(IAM)

2. 身份与访问管理(IAM)：用户认证、角色与权限模型、RBAC与ABAC

身份与访问管理，说白了就是解决「你是谁」「你能干什么」这两个问题。在 Lakehouse 环境里，这个问题比传统数仓复杂得多——数据湖里可能有几百张表、几千个文件，还有各种计算引擎、ML 模型、API 端点。我见过不少团队，一开始觉得 IAM 不就是建个用户、给个权限嘛，结果上线后要么权限太松数据泄露，要么权限太紧业务跑不动。

嗯，这一章我们就把 IAM 的三个核心层拆开讲：用户认证、角色与权限模型、以及 RBAC 和 ABAC 的实战选择。

2.1 用户认证：Lakehouse 的第一道门

认证是 IAM 的起点。在 Lakehouse 里，用户不只是人，还有服务账号、应用程序、甚至 ETL 作业。我个人习惯把认证方式分为三类：

本地认证：用户名+密码，存储在 Lakehouse 自身的用户目录里。适合小团队或开发环境，但千万别用在生产环境——密码泄露、轮换困难、审计缺失，都是坑。
LDAP/AD 集成：对接企业已有的目录服务。大部分企业都有 Active Directory 或 OpenLDAP，Lakehouse 可以直接用 LDAP 协议做认证。我在项目中遇到过一个问题：LDAP 查询超时导致登录缓慢，后来加了缓存层才解决。
SSO / OIDC / SAML：这是生产环境的标配。通过 Keycloak、Azure AD、Okta 等 IdP 做单点登录，用户一次登录就能访问多个服务。Lakehouse 支持 OIDC 和 SAML 2.0，我建议优先用 OIDC——它比 SAML 轻量，而且对现代应用更友好。

我的建议： 生产环境一定要用 SSO + MFA（多因素认证）。我曾经帮一个客户排查数据泄露事件，最后发现是某个员工的密码被钓鱼了。如果当时启用了 MFA，这个事件完全可以避免。

认证流程大致是这样的：

用户访问 Lakehouse 前端或 API
系统重定向到 IdP 登录页
用户输入凭证（可能加上 MFA 验证码）
IdP 返回一个 JWT 或 SAML 断言
Lakehouse 验证的有效性，提取用户身份信息
认证通过，进入授权阶段

这里有个关键点：的过期时间。太短了用户频繁重新登录，太长了有安全风险。我一般设 1 小时，配合 refresh 做无感续期。

2.2 角色与权限模型：从粗粒度到细粒度

认证通过后，接下来就是授权——决定用户能做什么。Lakehouse 的权限模型通常分三层：

层级	控制对象	示例
Catalog 级	整个数据目录	谁能创建/删除数据库
Schema 级	数据库内的命名空间	谁能查看某个 Schema 下的所有表
表/列级	具体的数据表或列	谁能读取某张表的某几列

你想想看，如果只给粗粒度的 Catalog 级权限，那一个分析师可能能看到整个公司的财务数据。这显然不行。所以现代 Lakehouse 都支持列级权限和行级过滤。

核心原则：最小权限原则——每个用户只拥有完成工作所需的最小权限集。不要因为方便就给所有人「管理员」角色。

我记得有一次，一个数据工程师为了省事，把某个 ETL 作业的服务账号加到了「超级管理员」组。结果这个作业的代码里有 bug，误删了一个生产表。虽然数据能恢复，但花了整整 6 个小时。从那以后，我要求所有服务账号必须单独建角色，权限精确到表级别。

2.3 RBAC vs ABAC：怎么选？

RBAC（基于角色的访问控制）和 ABAC（基于属性的访问控制）是两种主流的授权模型。很多人问我哪个更好，我的回答是：看场景。

RBAC：简单、直观、好管理

RBAC 的核心是「角色」。你把权限打包成角色，然后把角色分配给用户。比如：

数据管理员：可以创建/删除表、管理权限
数据工程师：可以读写表、运行 ETL
数据分析师：只能读表、运行查询

RBAC 的优点很明显：概念简单，容易理解，管理成本低。适合角色相对固定的场景。但缺点也很突出——当角色数量爆炸时，管理就变得混乱。我见过一个客户，他们定义了 200 多个角色，连管理员自己都搞不清每个角色有什么权限。

ABAC：灵活、精细、动态

ABAC 不看角色，看属性。属性可以是用户的（部门、职级、地理位置），也可以是资源的（数据敏感度、创建时间、所属项目），还可以是环境的（访问时间、网络 IP）。

举个例子：

# ABAC 策略示例
# 允许：销售部门的员工，在上班时间，读取敏感度为"内部"的数据
if user.department == "sales" 
   and resource.sensitivity == "internal" 
   and environment.time between "09:00" and "18:00":
   allow read

ABAC 的灵活性是 RBAC 无法比拟的。但代价是策略复杂、性能开销大、调试困难。我建议只在需要细粒度控制的场景用 ABAC，比如：

多租户环境（不同客户只能看自己的数据）
合规要求严格（比如 GDPR，需要按数据主体过滤）
动态权限需求（比如临时项目组）

避坑指南： 我曾经在一个项目里全盘采用 ABAC，结果策略写了几百条，每次权限变更都要改策略文件，测试周期很长。后来我改成「RBAC 为主 + ABAC 补充」的混合模式——80% 的权限用 RBAC 管理，只有那些真正需要动态控制的场景才用 ABAC。效果好了很多。

2.4 实战：在 Lakehouse 中实现 IAM

以 Apache Iceberg + Trino 为例，一个典型的 IAM 配置流程是这样的：

配置认证：在 Trino 中配置 OIDC 认证，对接企业的 Keycloak
定义角色：在 Lakehouse 的权限系统中创建角色（比如 analyst_role、engineer_role）
分配权限：给角色授予具体的 Catalog、Schema、表权限
映射用户：把 IdP 中的用户组映射到 Lakehouse 角色
启用审计：记录所有访问日志，定期审查权限

下面是一个简单的权限授予 SQL 示例：

-- 创建角色
CREATE ROLE analyst_role;

-- 授予 Schema 的读取权限
GRANT USAGE ON SCHEMA sales TO analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO analyst_role;

-- 列级权限：分析师只能看到非敏感列
GRANT SELECT (customer_id, order_date, amount) 
ON TABLE sales.orders TO analyst_role;

-- 行级过滤：分析师只能看 2024 年之后的数据
CREATE ROW FILTER sales_filter 
ON sales.orders 
USING (order_date >= '2024-01-01');

ALTER TABLE sales.orders 
SET ROW FILTER sales_filter FOR analyst_role;

-- 将角色分配给用户组
GRANT analyst_role TO GROUP "analysts";

小技巧： 我习惯在创建角色时加一个命名规范，比如 role_<部门>_<级别>。这样一看角色名就知道它是干什么的，管理起来方便很多。

2.5 IAM 架构总览

下面这张图展示了 Lakehouse IAM 的整体架构，从用户认证到权限评估的完整链路：

这张图把整个 IAM 流程串起来了。你想想看，从用户登录到最终访问数据，中间经过了认证、策略查询、决策、审计四个环节。任何一个环节出问题，要么安全失效，要么业务受阻。

核心要点回顾：

认证用 SSO + MFA，别用本地密码
权限模型用 RBAC 为主，ABAC 补充
最小权限原则是铁律
审计日志不能省，出事时它是救命稻草

嗯，IAM 这部分内容就到这里。记住，身份和访问管理不是一次性配置完就完事的——它需要持续维护、定期审查。我每个季度都会做一次权限审计，看看有没有僵尸账号、过度授权的角色。这个习惯帮我避免了好几次潜在的安全问题。