RBAC,ABAC,REBAC访问权限控制模型

619008336

关注

原创 2025-08-14 17:16:28 1.1k 阅读 AI 写同款· GEO 优化 ›

基于Zanzibar实现的ReBAC权限体系（1）- OpenFGA简介 OpenFGA 是一个面向开发人员的可扩展开源授权系统，允许为任何类型的应用程序实施授权，并随着复杂性的增加而平稳发展。受 Google 内部授权系统 Google 的 Zanzibar 的启发，OpenFGA 依赖于 Relationship-Based Access Control，它允许开发人员轻松实现 Role-Based Access Control，并提供额外的能力来实现 Attribute-Based Access Control。类型定义定义用户或其他对象可以与此类型相关的所有可能关系。阅读详情

1. RBAC

（Role-Based Access Control，基于角色的访问控制）

原理：

通过为用户分配“角色”，再为角色分配权限，实现权限管理。用户不直接拥有权限，而是通过角色间接获得。

优点：

结构清晰：易于理解和实现，适合组织结构明确的企业。
管理简便：权限集中于角色，新增/删除用户只需调整角色分配。
降低复杂度：避免为每个用户单独配置权限，减少管理开销。
支持最小权限原则：可通过精细的角色划分实现权限最小化。

缺点：

灵活性差：难以处理动态或上下文相关的权限需求（如“仅在工作时间访问”）。
角色爆炸：当业务复杂时，角色数量可能急剧增加（如“财务经理-北京-季度报表”）。
缺乏上下文感知：无法根据环境（时间、地点、设备等）动态调整权限。

适用场景：

企业内部系统、权限结构稳定、组织层级分明的场景。

2. ABAC

（Attribute-Based Access Control，基于属性的访问控制）

原理：

基于主体（用户）、客体（资源）、操作和环境的属性，通过策略规则动态判断是否允许访问。

优点：

高度灵活：支持复杂的、上下文相关的访问控制（如“部门经理且在工作时间可审批报销”）。
细粒度控制：可实现非常精细的权限策略。
动态决策：能根据实时环境（时间、IP、设备安全等级）调整访问权限。
可扩展性强：适合复杂、多变的业务需求。

缺点：

复杂性高：策略编写和维护难度大，需要专门的策略语言（如XACML）。
性能开销：每次访问都需要评估多个属性，可能影响系统性能。
调试困难：当访问被拒绝时，难以快速定位是哪个属性或规则导致的。
实施成本高：需要策略决策点（PDP）、策略执行点（PEP）等架构支持。

适用场景：

云环境、多租户系统、需要动态和细粒度权限控制的场景。

3. REBAC

（Relationship-Based Access Control，基于关系的访问控制）

注：有时也写作 ReBAC（Relationship-Based Access Control）

原理：

基于用户之间的关系（如“同事”、“下属”、“项目成员”）或用户与资源之间的关系（如“文件所有者”、“群组成员”）来决定访问权限。

优点：

自然表达社交/组织关系：适合社交网络、协作平台等场景。
高度动态：权限随关系变化自动调整（如退出群组则失去访问权）。
可组合性强：可通过关系链实现间接权限（如“经理的经理”）。
支持继承与传递：可定义关系的传递性（如“朋友的朋友”）。

缺点：

关系管理复杂：大规模关系网络的维护和查询成本高。
权限蔓延风险：关系链过长可能导致意外授权。
性能挑战：关系路径查找（如最短路径、可达性）在大数据量下可能较慢。
审计困难：权限来源可能不直观，难以追溯。

适用场景：

社交网络、协作工具（如Google Drive共享）、组织架构复杂的企业系统。

4.混合模型

在实际系统中，常采用 混合模型,以兼顾灵活性与管理效率。

RBAC + ABAC（角色+属性）

RBAC + ABAC 组合的核心思想：

RBAC 提供基础权限框架：用户通过角色获得“通常情况下的权限”。
ABAC 作为“策略过滤器”或“增强层”：在角色权限的基础上，根据上下文属性（时间、地点、设备、资源属性等）动态决定是否允许访问。

可以理解为：“你有这个角色，但还要看条件是否满足。”

优势	说明
结构清晰 + 灵活控制	RBAC 管“谁该有什么权限”，ABAC 管“什么时候能用”
减少角色爆炸	不需要为“高金额审批经理”等创建新角色，用属性控制即可
动态适应业务变化	新增资源只需打标签，策略自动生效，无需改角色
合规与审计友好	所有决策可追溯：基于角色 + 哪些属性触发了拒绝/允许

案例：

企业财务系统中的报销审批

RBAC 层面：
- 角色：部门经理
- 权限：可以审批本部门员工的报销单
ABAC 增强规则：
- 只有当报销金额 ≤ 5000 元 时，部门经理才能审批。
- 如果金额 > 5000 元，则需要 财务总监 角色 + 额外审批流程。
- 审批操作必须在 工作日 9:00–18:00 内完成。
- 用户必须从 公司内网 IP 或已注册设备 登录。

例如：即使你是“部门经理”，但如果：

报销单金额是 6000 元，你不能批；
现在是晚上 20 点，你也无法提交审批。

REBAC + ABAC（关系+属性）

REBAC + ABAC 组合的核心思想：

REBAC 定义“谁能访问什么”基于关系链：如“我是项目成员 → 可访问项目文档”，“我是A的经理 → 可查看A的绩效”。
ABAC 作为“过滤器”或“条件判断层”：即使存在关系，也需满足某些属性条件（时间、设备、资源敏感度等）才能真正访问。

可以理解为：“你和资源有关系，但还要看条件是否允许。”

优势	说明
表达复杂权限路径	支持“间接关系”授权，如“经理的经理”、“群组成员的成员”
动态上下文控制	在关系基础上叠加时间、设备、资源分类等条件，提升安全性,支持动态、临时、复杂的权限场景
减少硬编码权限	不需要为每个场景预设权限，而是通过关系图 + 策略引擎动态计算
支持权限继承与限制	例如“团队成员可编辑文档，但非工作时间不能编辑”

案例：

协作平台（如 Google Drive / Notion）中的文件共享

REBAC 层面：
- 文件 A 属于“项目组X”
- 用户 B 是“项目组X”的成员 → 因此 B 可以查看文件 A
- 用户 C 是 B 的直接上级 → C 可以“查看下属的所有工作文档”（通过组织关系链）
ABAC 增强规则：
- 如果文件标记为 classification=sensitive（敏感），则：
  - 必须使用 公司注册设备 才能下载
  - 禁止在 非工作时间（22:00–6:00） 访问
  - 访问者必须具有 security_level>=3 的属性
- 所有访问操作必须从 企业网络或VPN 内发起