4. ReBAC 模型原理与构成：关系图谱、关系推断、关系传播

4.1 模型边界：ReBAC 解决什么问题

ReBAC（Relationship-Based Access Control，基于关系的访问控制）将权限决策从“用户拥有什么角色/属性”转向“用户与资源之间存在什么关系”。其核心边界在于：当授权逻辑天然依赖实体间的社交、组织、层级或图谱关系时，RBAC 或 ABAC 往往需要维护大量冗余关系属性或复杂策略表达式，而 ReBAC 通过关系图谱统一表达。

4.2 分层职责：关系图谱层的三块积木

ReBAC 架构通常划分为三层：

1. 关系存储层：以图数据库（如 Neo4j）或专用关系引擎（如 Google Zanzibar）保存实体节点与关系边。每条边为 (subject, relation, object) 三元组。
2. 推断引擎层：负责执行关系推断（Transitive Closure）和关系传播，根据预设的图规则推导出隐式关系。
3. 决策点层：接收请求 (用户, 动作, 资源)，在关系图谱中查询是否存在符合授权路径的关系链。

4.3 数据流与信任链路：关系推断如何执行

关系推断是 ReBAC 的核心机制。典型推断规则包括：

• 直接关系：用户 X 拥有资源 R 的 owner 关系 → 允许 delete。
• 传递闭包：用户 X 是部门 D 的 member，部门 D 是项目 P 的 owner → X 可读 P 的文档。
• 关系传播：用户 X 对资源 R 有 edit 关系，R 被共享给群组 G，X 是 G 的 member → X 可 edit R（需传播规则）。

数据流路径：

1. 请求到达决策点层，携带 (subject, action, resource)。
2. 决策点层将动作映射为所需的关系集合（如 “view” 映射为 viewer | editor | owner）。
3. 调用推断引擎执行图查询或闭包运算，返回可达的隐式关系路径。
4. 若存在任意一条路径，则授权通过。

4.4 ReBAC 关系图谱核心结构

4.5 选型权衡：何时选择 ReBAC

4.6 风险点

• 关系爆炸：每对实体间的关系边数量可能随用户规模平方增长，需设计压缩策略（如组节点、关系类型聚合）。
• 推断循环：错误配置的传递规则可能导致无限递归，必须设置最大跳数并用有向无环图约束。
• 数据一致性：关系图谱在分布式环境下的事务边界模糊，建议采用最终一致性 + 版本向量。
• 管理界面复杂：运营人员需理解图概念，运维工具需要提供可视化关系编辑器。

4.7 落地步骤

1. 关系建模：梳理实体类型（用户、组、资源）和关系类型（member、owner、viewer、editor 等），输出关系图 schema。
2. 选择图存储引擎：推荐开源 OpenFGA（符合 Zanzibar 规范）或 Neo4j 自建。
3. 定义推断规则：用 DSL 描述关系传递逻辑，如：

   define viewer: [owner, viewer]
   define editor: [owner]
   define owner: [owner]

4. 集成决策点：在 API 网关或业务服务中调用关系检查 SDK（如 OpenFGA Client）。
5. 性能压测：模拟多跳查询、高并发写入关系边，调优索引与缓存策略。
6. 运维可视化：提供关系图谱管理后台，支持关系边 CRUD 及路径测试。

4.8 验收标准