1. 权限模型概述
1.1 访问控制基本概念
访问控制（Access Control）是信息安全体系的核心机制，其本质是“谁（主体）能对什么（客体）执行哪些操作（动作）”。在软件系统中，访问控制决定了用户能否读取某个文件、调用某个API、修改某条数据库记录。
访问控制的三要素：
- 主体（Subject）：发起访问请求的实体，如用户、进程、服务账号。
- 客体（Object）：被访问的资源，如文件、API端点、数据库表、微服务。
- 操作（Operation）：主体对客体执行的动作，如读、写、执行、删除。
访问控制策略通常围绕三个核心问题展开：
- 认证（Authentication）：确认主体身份是否真实。
- 授权（Authorization）：确认主体是否有权执行请求的操作。
- 审计（Audit）：记录访问行为，用于事后追溯与合规检查。
合规视角： 在GDPR、SOX、PCI-DSS等合规框架中，访问控制是强制性要求。例如，PCI-DSS要求“按需分配最小权限”，SOX要求“职责分离（SoD）”，这些都需要权限模型在架构层面提供支撑。
1.2 权限模型演进历史
权限模型的发展经历了从粗粒度到细粒度、从静态到动态的演进过程：
| 阶段 | 模型 | 核心思想 | 典型问题 |
|---|---|---|---|
| 1960s | DAC（自主访问控制） | 资源所有者自行决定谁可以访问 | 权限扩散失控，无法集中管理 |
| 1970s | MAC（强制访问控制） | 系统根据安全标签强制控制 | 灵活性差，不适合业务系统 |
| 1990s | RBAC（基于角色的访问控制） | 权限与角色绑定，用户通过角色获得权限 | 角色爆炸，细粒度不足 |
| 2000s | ABAC（基于属性的访问控制） | 根据主体、资源、环境属性动态决策 | 策略复杂，性能开销大 |
| 2010s至今 | RBAC+ABAC混合模型 | 角色粗粒度管控，属性细粒度补充 | 设计复杂度高，需合理划分边界 |
演进趋势： 从“谁”到“什么条件下”的转变。DAC/MAC关注“你是谁”，RBAC关注“你的角色是什么”，ABAC关注“你的属性+环境+资源属性综合判断”。混合模型则是在角色基础上叠加属性条件，兼顾效率与灵活性。
1.3 RBAC与ABAC核心区别
RBAC和ABAC是当前最主流的两种权限模型，它们在设计哲学、决策方式、适用场景上存在本质差异：
| 对比维度 | RBAC（基于角色） | ABAC（基于属性） |
|---|---|---|
| 决策依据 | 用户所属的角色 | 主体属性 + 资源属性 + 环境属性 |
| 权限粒度 | 粗粒度（角色级别） | 细粒度（属性级别） |
| 策略变更 | 需修改角色-权限映射 | 修改策略规则即可，无需改角色 |
| 性能 | 高（预计算，缓存友好） | 中低（运行时计算属性） |
| 管理复杂度 | 低（角色数量可控时） | 高（属性与策略规则多） |
| 典型场景 | 企业ERP、CRM、OA系统 | 云资源管理、数据脱敏、多租户 |
RBAC的核心公式：
用户 → 角色 → 权限
// 用户通过角色间接获得权限
// 角色是权限的集合ABAC的核心公式：
访问决策 = f(主体属性, 资源属性, 环境属性, 操作)
// 决策引擎根据策略规则计算布尔结果
// 示例：允许访问 if 用户.部门 == 文档.部门 AND 当前时间 in [09:00, 18:00]
常见误区： 不要认为ABAC可以完全替代RBAC。在大多数企业系统中，纯ABAC会导致策略规则爆炸、运维人员难以理解、性能瓶颈。混合模型才是工程实践中的最优解。
1.4 混合模型适用场景
RBAC与ABAC混合模型的核心思想是：用RBAC做粗粒度的权限骨架，用ABAC做细粒度的权限血肉。具体来说：
- RBAC层：定义角色（如管理员、审计员、普通员工），角色绑定模块级别的访问权限（如“访问财务模块”、“查看用户列表”）。
- ABAC层：在角色基础上叠加属性条件，实现数据级别的细粒度控制（如“只能查看本部门的财务数据”、“只能操作状态为‘草稿’的订单”）。
典型适用场景：
| 场景 | RBAC负责 | ABAC负责 |
|---|---|---|
| 多租户SaaS | 租户管理员、普通用户角色 | 只能访问本租户数据（租户ID属性） |
| 医疗信息系统 | 医生、护士、药剂师角色 | 只能查看自己负责患者的病历（患者-医生关联属性） |
| 金融风控系统 | 风控审核员、风控主管角色 | 审核金额超过100万需主管二次审批（金额属性+审批状态） |
| 内容管理系统 | 编辑、作者、审核员角色 | 只能编辑自己创建的文章（创建者属性） |
混合模型决策流程： 当用户发起请求时，系统先通过RBAC判断用户角色是否具备模块访问权限；如果通过，再通过ABAC引擎根据属性规则判断是否允许具体操作。这种“先粗后细”的决策链既能保证性能，又能实现灵活控制。
上图展示了混合模型的典型决策流程：用户请求先经过RBAC层进行角色检查，只有通过角色权限验证的请求才会进入ABAC层进行属性策略计算，最终输出允许或拒绝的决策。这种分层设计有效避免了ABAC引擎处理大量无关请求的性能问题。
架构建议： 在实现混合模型时，建议将RBAC决策缓存到Redis等内存存储中（角色变更频率低），ABAC策略规则使用表达式引擎（如Spring EL、Drools）动态解析。这样既能保证RBAC的高性能，又能保持ABAC的灵活性。