权限模型
- RBAC（Role-Based Access Control） ○ 按“角色→权限”授权，用户绑定角色，角色拥有权限。 ○ 例：财务角色可查看对账；运营角色可编辑商品。
- ABAC（Attribute-Based Access Control） ○ 按“属性表达式”授权：主体（用户）属性、资源属性、动作、环境（时间/地点/设备）等组成策略。 ○ 例：用户部门=资源部门 且 当前时间在工作时段 才能读。
- ACL（Access Control List） ○ 每个资源上维护“可访问主体列表及其权限”。 ○ 例：文档 A 允许 user_1 读写，允许 group_sales 只读。
核心差异
| 维度 | RBAC | ABAC | ACL |
|---|---|---|---|
| 授权粒度 | 角色级（中等） | 条件级（最细，灵活） | 资源级（细，但分散） |
| 维护方式 | 维护角色和权限映射 | 维护策略表达式与属性字典 | 每个对象维护名单 |
| 动态场景 | 一般，需要建很多角色适配 | 强，天然支持时间/地点/级别等 | 一般，需逐对象改列表 |
| 可审计性 | 强，审计角色→权限清晰 | 中，需要记录策略判定依据 | 弱/中，分散在对象上 |
| 扩展到行/列级 | 需配合数据权限或 ABAC | 原生支持（属性即行/列条件） | 可做，但运维成本高 |
| 典型应用 | 企业后台、SaaS 多角色 | 安全/合规/多维条件场景 | 文件共享、按对象授权 |
优缺点对比
| 权限模型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| RBAC（基于角色的访问控制） | 角色稳定、权限边界清晰的后台系统；SaaS 的租户内角色管理 | 易理解、易审计、运维成本低；菜单与接口权限映射自然 | 面对细粒度、多条件权限需求时，容易出现角色爆炸（成百上千个角色） |
| ABAC（基于属性的访问控制） | 基于用户、资源、环境等多维条件进行权限判定；适用于租户、部门、属地等数据隔离，以及合规、零信任、行级/列级权限控制 | 灵活性高，单条策略可覆盖大量场景；天然支持动态上下文 | 策略设计与属性治理复杂；可解释性和排障难度较高；评估链路较长，通常需要缓存优化 |
| ACL（访问控制列表） | 针对特定对象的临时分享与协作，如文档、文件、相册、项目权限 | 符合“分享给谁”的直觉；支持极细粒度的对象级权限控制 | 对象数量较多时管理复杂；权限审计与回收成本高；难以表达批量授权策略 |
如何选择
只需角色分权（管理员/运营/财务等），且权限不复杂 → 选 RBAC。
需要数据级别的隔离或动态约束（部门/地域/级别/时间/设备） → 选 ABAC，或 RBAC + ABAC 组合。
需要按单个对象分享给具体人（文档/仪表盘/工单） → 选 ACL，或在 RBAC/ABAC 之上对特定资源叠加 ACL。
多租户 SaaS 常见组合：
租户边界/行级隔离：ABAC（tenant_id 必须相等等条件）
租户内功能授权：RBAC（角色→权限）
文档/报告临时共享：ACL
简单示例
RBAC（权限点）
权限命名：order:read、order:approve
角色映射：manager → [order:read, order:approve]
判断：user.roles 含 manager 且 action=order:approve → allow
ABAC（属性表达式）
allow if user.dept == order.dept and user.level >= 3 and env.time in [09:00–18:00] and action == “read”
ACL（对象名单）
order/123: { allow: [user:alice:read, group:ops:read, user:bob:write] }
常见坑与规避
- RBAC 角色爆炸：用角色层级/权限聚合，别把数据维度塞进角色；把数据条件交给 ABAC。
- ABAC 属性失真：属性字典不统一、来源不可信；先做属性治理（来源、口径、更新、授权）。
- ACL 权限漂移：对象多且多人维护，定期做“可见性审计/分享过期回收”。