IAM 基础理论：身份认证与授权模型

聊多云数据湖的打通，第一个绕不开的坎就是 IAM。说白了，IAM 就是云上的「门禁系统」——谁可以进、进了能干什么、干了有没有记录。我在项目中见过太多团队，一上来就撸权限策略，结果三个月后权限炸成一锅粥。嗯，咱们还是先把地基打牢。

身份认证 vs 授权：两个容易搞混的概念

很多人把认证和授权混着说，其实它们完全是两码事。

维度	身份认证（Authentication）	授权（Authorization）
核心问题	你是谁？	你能做什么？
典型手段	密码、MFA、证书、生物特征	策略、角色、属性规则
失败后果	无法登录	越权操作或数据泄露
云上常见实现	IAM User + 登录凭证	IAM Policy + Role

我记得有一次帮客户排查数据湖泄露事件，发现他们认证做得挺严——MFA 强制、密码策略拉满。但授权层完全是「全员管理员」，一个实习生都能删 S3 桶。你想想看，门锁再结实，屋里所有房间都不上锁，有什么用？

RBAC：最经典的授权模型

RBAC（基于角色的访问控制）是目前云上最主流的授权模型。它的核心思想很简单：用户不直接拥有权限，权限挂载在角色上，用户通过被赋予角色来获得权限。

我在设计多云数据湖权限体系时，习惯先画一张角色矩阵。举个例子：

角色	S3 读	S3 写	Glue 管理	KMS 解密	Athena 查询
数据湖管理员	✅	✅	✅	✅	✅
数据工程师	✅	✅	✅	✅	✅
数据分析师	✅	❌	❌	✅	✅
审计员	✅（只读）	❌	❌	❌	❌

RBAC 的好处是管理简单，适合组织架构相对稳定的场景。但它的短板也很明显——当权限粒度需要细化到「某个分区」「某个标签」「某个时间窗口」时，角色数量会爆炸。我曾经在一个金融客户那里看到 200 多个自定义角色，维护成本高得吓人。

ABAC：更灵活的授权方式

ABAC（基于属性的访问控制）就是来解决 RBAC 粒度问题的。它不看「你是什么角色」，而是看「你、资源、环境有什么属性」。

举个例子：

• RBAC 写法：数据分析师角色 → 允许读取 S3 桶
• ABAC 写法：如果用户部门=「风控」且资源标签=「风控数据」且访问时间在 09:00-18:00 → 允许读取

AWS 的 IAM 策略里支持基于标签的 ABAC，Azure 的 Azure AD 条件访问也是 ABAC 思路。你想想看，如果数据湖里有 100 个业务部门的数据，用 RBAC 你得建 100 个角色，用 ABAC 一个策略加标签就能搞定。

SAML 与 OIDC：两种主流联合身份协议

打通多云数据湖，最头疼的问题就是「身份孤岛」。AWS 有一套用户、Azure 有一套、GCP 又有一套。联合身份协议就是用来解决这个问题的——让一个身份源（比如企业 AD）的认证结果，被多个云平台信任。

SAML 2.0：企业级的老牌协议

SAML 基于 XML，核心是 断言（Assertion）。流程大概是：

1. 用户访问云平台（服务提供方 SP）
2. SP 把用户重定向到企业 IdP（比如 Okta、ADFS）
3. IdP 验证用户身份，生成 SAML 断言（XML 格式）
4. 用户带着断言回到 SP，SP 验证签名后建立会话

OIDC：现代应用的轻量选择

OIDC（OpenID Connect）建立在 OAuth 2.0 之上，用 JWT（JSON Web ）代替了 SAML 的 XML。它更轻量、更适合 API 和微服务场景。

核心流程：

1. 客户端向 IdP 请求认证
2. IdP 返回 ID （JWT 格式）
3. 客户端用 ID 向资源服务器证明身份

JWT 的好处是自包含——用户信息、过期时间、签名都在一个字符串里，不需要像 SAML 那样再查一次 IdP。

对比维度	SAML 2.0	OIDC
数据格式	XML	JSON（JWT）
传输方式	浏览器重定向（HTTP POST/Redirect）	HTTP 请求头 + 重定向
适用场景	企业门户、传统 Web 应用	移动端、SPA、API 网关
云平台支持	AWS IAM Identity Center、Azure AD	所有主流云 + Kubernetes
学习曲线	较陡（XML 签名、断言解析）	较平缓（JWT 库成熟）

本章知识体系总览

下面这张图把 IAM 的核心概念串起来了。你可以把它当作后续章节的导航图。

这张图把今天的内容分成了三层：上层是认证协议（SAML/OIDC），中层是授权模型（RBAC/ABAC），底层是云平台的具体实现。后面的章节，我们会一层层往下拆，最终落地到多云数据湖的实战配置上。