访问控制模型对比：RBAC、RBAC+、ABAC
1. 模型定义
1.1 RBAC（Role-Based Access Control）基于角色的访问控制
权限授予用户的方式是： 用户 → 角色 → 权限 强调组织结构和岗位。
1.2 RBAC+（RBAC + Policy/Scope/Sub-RBAC）角色增强模型
本质仍是 RBAC，但加入限定条件（scope、数据范围）、角色继承、条件表达式等增强能力。 常见增强方式：
- 角色 + 数据范围（如：只能看本部门数据）
- 角色层级（L1 / L2 / L3）
- 角色绑定资源（如：仅管理某几个 appId）
1.3 ABAC（Attribute-Based Access Control）基于属性访问控制
权限由四类属性共同决定：
- Subject（主体，用户属性）
- Resource（资源属性）
- Action（操作属性）
- Environment（环境属性，如时间/IP） 通过策略引擎执行规则（如 OPA、Casbin、Axiomatics、AWS IAM 风格）。
2. 能力对比：RBAC vs RBAC+ vs ABAC
以下是企业 IAM 常用的评估表：
| 维度 | RBAC | RBAC+ | ABAC |
|---|---|---|---|
| 权限粒度 | 粗（基于角色） | 中（角色 + 条件） | 精细（属性级别） |
| 可扩展性 | 中 | 高 | 非常高 |
| 数据维度授权 | 基本不支持 | 支持（范围限制） | 强支持 |
| 动态授权 | 不支持，要改角色 | 部分支持 | 强支持（实时评估） |
| 学习成本 | 低 | 中 | 高 |
| 管理成本 | 低 | 中偏高 | 高 |
| 策略复杂度 | 简单 | 中等 | 高，可爆炸 |
| 性能 | 极高 | 高 | 中等（取决于策略引擎） |
| 适合规模 | 小团队 / 单系统 | 中大型企业 | 超大型、跨 BU 复杂组织 |
| 审计可读性 | 高（角色=责任） | 中 | 低（策略难读、难维护） |
3. 适用场景分析
3.1 适用 RBAC 的场景
RBAC 非常适合结构明确、稳定、单向授权场景：
适合：
- 企业内部系统（如 OA、人事、CRM）
- 用户角色简单且固定（管理员/运营/客服）
- 组织结构清晰（部门层级明确）
- 权限变化不频繁
不适合：
- 数据级权限复杂的业务
- 资源动态变化（如多租户、资源实例级权限）
典型例子：
- Jira 的 Project Roles
- 简单 CMS / SaaS 管理台
3.2 适用 RBAC+ 的场景（大部分企业实际用这个）
RBAC+ 是多数大型企业 IAM 的“黄金中间道路”。
适合：
- 多系统、多租户、多应用
- 大企业内部平台（Ops、监控、指标、日志、风控）
- 权限不仅要控制“能不能做”，还要控制“对哪些数据做”
- 租户/资源动态扩张较快，但仍需要可控的治理结构
典型方式：
- 阿里 RAM：角色 + Policy（可附加资源范围）
- 字节字节跳动 IAM：角色 + 域范围（Domain Scope）
- AWS IAM 的 Role + Inline Policy（轻度 ABAC）
RBAC+ 对企业来说优势明显：治理成本可控，扩展性好，安全性稳定。
3.3 适用 ABAC 的场景（超大规模与动态场景）
在权限无法通过角色管理、资源与用户属性高度动态化时，需要 ABAC。
适合：
- 大规模分布式系统，资源实例百万级
- 多租户 SaaS（要求实例级隔离）
- 数据细粒度管控（字段级、行级、列级）
- 需要动态策略（时间、IP、设备、地理位置、风险评分等）
- 安全等级要求高（金融、政府、电商核心系统）
典型例子：
- AWS IAM（最完整 ABAC 支持）
- Kubernetes（基于属性的 Admission 控制）
- 金融系统的行级权限控制
- 大型互联网公司的“风险感知、动态访问控制”
不适合：
- 权限模型简单的早期系统
- 小团队管理（策略难写、治理成本极高）
4. 优缺点分析
4.1 RBAC 优缺点
优点
- 模型简单易懂，学习成本低
- 维护成本低，适合 80% 的常规系统
- 性能极好，缓存角色即可
- 审计可读性强（角色 = 岗位责任）
缺点
- 粒度粗：无法满足数据级权限
- 角色爆炸：随着业务增长，角色数容易上千
- 动态、条件式授权基本无能为力
4.2 RBAC+ 优缺点（现实中最好用）
优点
- 保持 RBAC 简单易管
- 通过范围（Scope）、属性条件解决角色爆炸
- 可以实现数据级权限（部门、本人、子部门、多租户）
- 管理成本可控（比 ABAC 低很多）
- 易于审计，依旧有“岗位-权限责任”可追溯
缺点
- 灵活性仍然受限，不如 ABAC 任意组合
- 策略复杂度比纯 RBAC 高
- 不能处理过于动态的环境属性（如风险、IP、设备指纹等）
4.3 ABAC 优缺点（最高级但成本最高）
优点
- 最精细的权限控制，能覆盖所有复杂场景
- 实时动态判断（基于属性的评估）
- 不需要大量角色，减少角色爆炸
- 能做到字段级 / 行级 / 请求级访问控制
缺点
- 学习成本高、策略难写、难维护
- 可读性差：审计人员难以理解策略含义
- 治理成本高：策略冲突、策略爆炸
- 对性能要求高，需要高效策略引擎（如 OPA + 缓存）
- 系统引入成本高：资源、主体都要抽象属性模型
5. 落地建议：如何选择 RBAC / RBAC+ / ABAC?
根据你的 IAM 架构背景（你已有 UMS / Passport / SSO，正在做企业级 IAM），建议如下：
场景 1：内部中台、管理后台
优先：RBAC+ 理由：
- 角色为主
- 数据范围满足大部分需求
- 容易被业务和运维接受
- 成本和治理都可控
场景 2：多租户 SaaS 平台（对外）
优先：RBAC+ 或 ABAC（资源实例级） 尤其当每个租户资源完全隔离时：
- RBAC+ scope = tenant-id 已可满足 若要对资源实例进行动态授权，例如：
- 允许用户访问“自己创建的资源”
- 允许只能查看标签匹配的资源 则必须使用：
- ABAC + 条件策略（tag 级别）
场景 3：金融、电商核心风控、日志、指标系统
（你业务中提到有告警中心、指标、日志、Trace、知识库） 优先：RBAC+ + 部分 ABAC 例如：
- 告警系统需要按产品线/团队/服务隔离（RBAC+）
- 但某些行级数据需要基于属性（多环境、多集群、多标签）（ABAC）
这也是阿里 + 字节的标准做法： RBAC 打框架，ABAC 做补充策略。
6. 最终建议（架构落地路线）
如果你是要从零构建 IAM（配合 UMS、Passport、SSO）：
阶段性路线：
Phase 1：RBAC 基础权限体系
- 用户/角色/权限
- 菜单/页面权限
- 粗粒度 API 权限
Phase 2：RBAC+ 数据域能力
加入：
- Scope（部门、本人成员、租户、业务线）
- 角色继承、角色模板
- 权限组、资源包
这一步已经能覆盖大部分企业级平台。
Phase 3：ABAC 精细策略能力（按需开启）
对一些特别复杂的系统（日志、指标、告警根因分析）加入：
- 动态属性（标签、service、env、cluster）
- 条件表达式策略（tag in user.allowedTags）
- 风险感知（IP、设备、访问时间）
最终可形成混合式 IAM： RBAC 负责岗位职责； RBAC+ 负责数据域； ABAC 处理动态细粒度策略。
