2、权限模型基础：RBAC模型详解、ABAC模型简介、权限模型选型对比

聊到大屏权限，很多同学第一反应就是「给角色分配权限」。嗯，这个思路没错，但实际落地时坑不少。我这些年做安全架构，见过太多因为权限模型选型不当，导致后期改得头皮发麻的项目。今天咱们就把 RBAC 和 ABAC 这两个主流模型掰开揉碎讲清楚。

2.1 RBAC 模型详解

RBAC，全称 Role-Based Access Control，基于角色的访问控制。说白了就是：用户 → 角色 → 权限 这条链路。用户不直接跟权限挂钩，而是通过角色这个中间层来间接获得权限。

为什么要有角色这一层？你想想看，如果每个用户都单独配置权限，1000 个用户就得配 1000 次，而且改一次权限要改 1000 个地方，这谁受得了？角色就是用来做「权限分组」的。

2.1.1 核心三要素

  • 用户（User）：访问系统的主体，可以是人，也可以是服务账号
  • 角色（Role）：权限的集合，比如「大屏管理员」、「数据查看员」
  • 权限（Permission）：对资源的操作许可，比如「查看销售大屏」、「导出报表」

我习惯用一句话记这个模型：用户拥有角色，角色拥有权限。就这么简单。

2.1.2 RBAC 的三种变体

实际项目中，RBAC 不是一成不变的。我把它分成三个层次，大家可以根据项目复杂度选择：

变体 核心特点 适用场景
RBAC0 基础模型，用户-角色-权限 小团队、简单大屏
RBAC1 支持角色继承（上级角色拥有下级权限） 层级组织、多级管理
RBAC2 支持角色约束（互斥角色、基数限制） 金融、医疗等合规场景

举个例子。我在做一个政府大屏项目时，客户要求「市领导能看到所有区县数据，区领导只能看本区数据」。这就是典型的 RBAC1 角色继承场景。我们给「市领导」角色继承「区领导」的所有权限，再额外加上全市范围的数据权限，完美解决。

2.1.3 RBAC 的代码实现示例

下面是一个简化的 RBAC 权限校验逻辑，用伪代码表示：

// 用户登录后获取角色
User user = getUserById(userId);
List<Role> roles = user.getRoles();

// 判断是否有权限访问某个大屏
boolean hasPermission = false;
for (Role role : roles) {
    if (role.hasPermission("VIEW_SALES_DASHBOARD")) {
        hasPermission = true;
        break;
    }
}

// 权限校验结果
if (!hasPermission) {
    throw new AccessDeniedException("您没有查看该大屏的权限");
}

嗯，这里要注意：实际项目中千万别在业务代码里写这种循环判断。我建议用 AOP 或者过滤器统一处理，不然每个接口都写一遍，代码就烂了。

避坑指南：我曾经在一个项目中，把角色和权限直接硬编码在代码里。结果客户说「我要新增一个角色」，我改代码改到凌晨三点。从那以后，我坚持把角色-权限映射关系放在数据库或配置中心，绝不死在代码里。

2.2 ABAC 模型简介

RBAC 虽然好用，但有个硬伤：它只能基于「角色」做判断。如果权限规则涉及时间、地点、设备、数据范围等动态因素，RBAC 就有点力不从心了。

这时候 ABAC（Attribute-Based Access Control，基于属性的访问控制）就派上用场了。它的核心思想是：根据用户、资源、环境的多维属性动态计算权限。

2.2.1 ABAC 的四大属性

  • 用户属性：部门、职级、区域、安全等级
  • 资源属性：大屏类型、数据敏感度、所属部门
  • 环境属性：访问时间、IP 地址、设备类型
  • 操作属性：查看、编辑、导出、分享

举个例子。一个大屏系统，要求「只有销售部的员工，在上班时间（9:00-18:00），从公司内网访问，才能查看销售数据」。用 RBAC 实现的话，你得建一个「销售部内网员工」角色，再配合时间判断，很别扭。但用 ABAC，一条策略就搞定：

策略规则：
IF 
  user.department == "销售部" 
  AND environment.time BETWEEN "09:00" AND "18:00"
  AND environment.ip IN (公司内网IP段)
THEN
  PERMIT resource.type == "销售大屏"

你看，是不是很直观？ABAC 的灵活性就在这里。

2.2.2 ABAC 的优缺点

优点 缺点
粒度极细，支持复杂规则 策略管理复杂，容易失控
动态决策，无需预定义角色 性能开销大，每次请求都要计算
扩展性好，新增属性不影响现有规则 调试困难，规则冲突时难以排查
我的建议：ABAC 虽好，但别滥用。我见过一个团队把所有权限都写成 ABAC 策略，结果策略文件 2000 多行，没人敢改。我的原则是：80% 的通用权限用 RBAC，20% 的特殊场景用 ABAC 补充。

2.3 权限模型选型对比

好了，两个模型都讲完了。那问题来了：我的大屏项目到底该用哪个？

我直接给结论：90% 的大屏项目，用 RBAC 就够了。为什么？因为大屏的核心场景是「看数据」，权限需求相对固定。你想想看，一个销售大屏，无非就是「销售总监能看全国数据，销售经理能看本省数据，销售员只能看自己数据」。这种层级关系，RBAC 完全能搞定。

但如果你遇到以下场景，可以考虑引入 ABAC：

  • 权限规则频繁变化，每周都要改
  • 需要根据时间、地点、设备等动态条件做判断
  • 数据权限粒度极细，比如「只能看自己负责的客户」
  • 合规要求严格，需要审计所有访问决策

我整理了一个选型对比表，方便大家参考：

对比维度 RBAC ABAC
学习成本 低，容易理解 高，需要理解策略引擎
实现复杂度 简单，数据库几张表搞定 复杂，需要策略引擎或规则引擎
性能 高，缓存友好 中等，每次请求需计算
灵活性 中等，角色变更需重新分配 高，属性变更即时生效
维护成本 低，角色管理清晰 高，策略容易堆积
典型场景 企业内部系统、管理后台 云平台、多租户系统
核心建议：选型时别追求「最先进」，要追求「最合适」。我个人的经验是：先上 RBAC，等发现 RBAC 确实不够用了，再在局部引入 ABAC。别一开始就搞大而全的权限模型，容易把自己绕进去。

最后说一句：权限模型没有银弹。RBAC 和 ABAC 不是二选一的关系，而是可以组合使用的。比如我最近做的一个大屏项目，主体用 RBAC 管理角色和菜单权限，数据权限部分用 ABAC 做细粒度控制，效果很好。

嗯，这一章就到这里。下一章咱们聊聊权限模型的具体落地实现，包括数据库设计、缓存策略、以及如何做权限审计。到时候我会分享一些我在项目中踩过的坑，保证实用。

← 上一章 📖 返回目录 下一章 →