RBAC权限控制

RBAC权限控制

概念

• RBAC（Role-Based Access Control）基于角色的访问控制。
• RBAC可以概况为：判断【who是否可以对what进行how的访问操作】这个逻辑表达式的值是否为true的求解过程，即将问题转换为who、what、how的问题，who、what、how构成了访问权限三元组。
• RBAC支持公认的安全原则：
  1. 最小特权原则
     • 在RBAC模型中可以通过分配给角色权限的多少和大小来实现最小特权原则，即分配给某个用户对应的角色的权限只要不超过该用户完成其任务就可以了。
  2. 责任分离原则
     • 通过调用独立互斥的角色来共同完成敏感的任务，比如转账可以通过设立财务和审计两个角色来完成。
  3. 数据抽象原则
     • 将具体的业务抽象称为许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。
     • 我的理解是将业务抽象为一个个的许可权（是否有权限操作，比如转账许可权、消费许可权等），而不是增删改查。

RBAC模型

• 现在比较公认的是RBAC96模型，包括RBAC0~RBAC3四个概念性的模型。
  1. 基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。
  2. 高级模型RBAC1、RBAC2都包含RBAC0，但又各自增加了独立的特点。
     • RBAC1：增加了角色分级的概念，一个角色可以从另一个角色继承许可权。
     • RBAC2：增加了一些限制，比如互斥角色的限制，即在一次活动中一个用户只能被分配其中的一个角色，不能同时获得两个角色的使用权，比如在之前的转账例子中，一个用户不能既是财务又是审计。
  3. 统一模型RBAC3，即包含了RBAC1和RBAC2，又根据传递性也包含了RBAC0。

RBAC模型简述

1. RBAC0

• RBAC0模型中包括用户（U）、角色（R）和许可权集合（P）、会话集合（S）。
• RBAC0是权限管理的核心部分，其他模型都是建立在此基础上。

2. RBAC1

• 主要是增加了继承关系（等级关系），也就是说组员的权限，组长可以继承，这样组长既有组员的权限又有一些特殊的权限。

3. RBAC2
   *角色互斥，是指一个审批，组员发起，组长审批，那么一个用户就不能即是组员又是组长，也就是说同一个活动一个用户又发起又审批（责任分离），所以也可以看出来RBAC1和RBAC2是互不兼容的。
4. RBAC3

• 将RBAC1和RBAC2组合在一起，提供角色的分级和继承能力，但这也引起了一些新的问题。
  

数据库设计

1. RBAC的5张表

• 用户表、角色表、权限表，一个用户可以关联多个角色，一个角色可以对应多个用户，一个角色可以有多个权限，一个权限可以赋给多个角色，所以用户表与角色表、角色表与权限表都是多对多的关系，这样在三张表的基础上又加上用户角色关联表、角色权限关联表，组成了基础的5张表。
  
  2. 角色与用户组

  • 角色是一组权限的集合，当用户数量非常大的时候，给每一个用户授权时非常的麻烦，这时我们可以引入用户组的概念，每个用户组内有多个用户，然后通过给用户组授权来达到给组内用户授权的目的，这时组内用户的权限=用户组的权限+用户的权限。数据表结构如下：
    

    3. 权限

  • 权限对应于我们系统中一般分为资源权限、功能权限。资源权限是指按钮、图片的可见性等，操作权限是指文件的删、改，菜单访问等，两者界限比较模糊。通常做成“用户-角色-权限-资源”的授权模型，而在设计数据表时，可把功能操作和资源统一管理，直接与权限表关联。数据表结构如下：
    

  总结

  • RBAC是目前比较主流的权限设计模型，apache shiro、spring security都是RBAC的权限验证框架，在权限表中如果仅仅是1:1的对应关系，资源与权限关联表可以不要，另外在权限表中注意区分资源的类型。