#### 3.5 选型权衡矩阵
| 评估维度 | RBAC | ABAC | ReBAC |
|----------|------|------|-------|
| **表达能力** | 中等（角色扁平） | 高（多属性组合） | 高（关系遍历） |
| **性能敏感度** | 低（O(1)查表） | 中高（策略引擎评估） | 中（关系图查询深度） |
| **维护成本** | 低（角色配置） | 高（策略规则管理） | 中（关系图同步） |
| **审计可追溯性** | 好（角色ID） | 差（属性上下文易丢失） | 好（关系路径可追踪） |
| **跨租户复用** | 困难（角色命名冲突） | 容易（属性包含租户ID） | 容易（关系图隔离） |
| **典型SaaS落地** | 用户管理、仪表盘 | 多级审批、动态数据脱敏 | 协作空间、文档共享 |
#### 3.6 落地步骤（选型与原型验证）
1. **需求归约**：列出所有授权规则，按“是否可抽象为角色”、“是否依赖关系”、“是否依赖环境属性”分类
2. **原型评估**：针对 top-5 高频场景，分别用三种模型构造最小授权流程，测量性能与规则条数
3. **风险点检查**：
- RBAC：是否存在“一人多角色冲突”？角色是否超过 50 个？
- ABAC：策略评估延迟是否超过 5ms？策略冲突检测工具是否就绪？
- ReBAC：关系图深度是否超过 3 层？递归查询是否可控？
4. **混合策略**：80% 场景可用 RBAC，对特殊场景叠加 ABAC 或 ReBAC 作为策略扩展点（通过策略引擎插件）
5. **验收标准**：
✓ 所有授权规则可被两种以上模型表达（冗余验证）
✓ 最坏情况下授权延迟 < 20ms（压力测试）
✓ 新增一种资源类型时，权限配置变更不超过 10 行规则或 2 个角色操作
💡 实践建议： 如果团队刚起步，优先用 RBAC 构建最小可行权限系统，再预留 ABAC 或 ReBAC 的扩展接口（如策略决策点 PDP）。不要一开始就上 ABAC/ReBAC 全量，避免陷入规则维护沼泽。
⚠️ 常见陷阱： 试图用单一模型覆盖所有场景。例如用 RBAC 模拟“只允许同一部门的员工查看”，会导致角色爆炸（每个部门需要一个角色）。此时应引入 ABAC 的属性判断或 ReBAC 的部门-员工关系。同样，用 ReBAC 表达简单的“管理员/编辑者”也会增加不必要的复杂度。
#### 3.7 信任链路与安全边界
在 SaaS 架构中，无论选择哪种模型，信任链路都应遵循**正向决策、反向撤销**原则：
- **信任链**：身份提供商 (IdP) → 认证网关 → 权限决策点 (PDP) → 资源服务 (RS)
- **控制流**：每一次请求必须经过 PDP 的完整策略评估，不允许跳过或缓存超过 TTL 的决策结果
- **租户隔离边界**：三种模型均需在策略上下文（Context）中注入 `tenant_id` 字段，确保跨租户查询被策略引擎拒绝
- **典型风险**：ABAC 中未显式检查 `tenant_id` 导致的租户穿透；ReBAC 中关系图未做租户分区导致的越权访问
#### 3.8 本章总结
| 模型 | 核心优势 | 最大风险 | 推荐场景 |
|------|----------|----------|----------|
| RBAC | 简单、成熟、工具链完善 | 角色爆炸、灰度权限困难 | B端标准管理后台 |
| ABAC | 灵活、动态、细粒度 | 策略失控、性能瓶颈、审计困难 | 金融、医疗等法规敏感场景 |
| ReBAC | 直观、符合业务关系、可审计 | 关系图复杂度、递归查询 | 协作工具、社交网络、多级资源嵌套 |
> **下一阶段**：当确定了基础模型组合后，我们将进入第4章，讨论如何在多租户环境下为不同模型设计实体与属性，包括租户标识的注入策略和表结构设计。