RBAC

Posted by SHENMIMOON 的博客 on August 10, 2016

RBAC

RBAC 是什么

RBAC：Role Based Access Control，基于角色的访问控制。

为什么需要 RBAC

在这样一种场景下:
> 需要通过限制某些 主体 对某些 资源 进行某些 操作 来保护系统

RBAC 被设计出来解决这一问题,并且实现三个安全原则: 最小权限原则，责任分离原则和数据抽象原则 (见百度百科)。

  1. 最小权限原则之所以被 RBAC 所支持，是因为 RBAC 可以将其角色配置成其完成任务所需要的最小的权限集。
  2. 责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。
  3. 数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

RBAC 如何实现权限控制

RBAC 对场景有以下抽象:

  • User:用户,操作主体.
  • Permission:权限,对某资源的某操作.
  • Role:角色,用户与权限之间的桥梁.

RBAC0

RBAC0 以上是RBAC0的典型实现,通过角色来组织权限,一个角色即一个功能所需最小权限集合的抽象,用户的角色集合即用户在系统中的全部职责.

这种方案的优势在于:

  • 隔离了用户和权限,用户的私有特性与权限的私有特性完全无关,相较于用户和权限的变动频率,角色本身的修改更少,因而可以减少处理变化的成本.
  • 结构简单易于实现.

而RBAC0的不足之处有以下几点:

  • 角色之间以及权限之间都是平行关系,而实际业务场景中,二者都有层级关系.
  • 新的用户需要分配所需的所有角色,新的权限需要分配给需要它的所有角色.

因此有了RBAC1的进一步设计.

RBAC1

RBAC1的重点是角色之间分级和继承组合关系. 角色分级以wiki的场景为例:

角色分级举例

在上图中,coo角色的权限等于其下权限的 并集 ,而BD角色的权限是上方各类BD权限的 交集 .
在新权限加入时只需分配给”BD”角色,所有的”上海BD”和”北京BD”角色就会拥有新权限,而新的用户只需分配”北京经理”即可获得”北京一区BD”和”北京二区BD”的所有权限.

RBAC1相对于RBAC0的实现难度稍有提升.通过RBAC1解决了角色之间逻辑上的层级关系表达的问题,同时大量减少了新的用户和权限加入时对系统的修改.
而实际应用中,角色之间的更复杂关系,例如互斥,只用RBAC1的方式并不能完全解决,而权限和用户之间也有着类似的限制,因此有了RBAC2.

RBAC2

RBAC2是RBAC0的扩展版,与RBAC1没有直接的关系.
RBAC2增加了约束的抽象:

  • Constraint:约束,强制性的规则,可以在角色赋予用户时,权限分配给角色时,以及用户在某一时刻激活一个角色时生效.
  • Session:会话,用户在某一时刻激活一个角色.

约束的定义表明了约束本身需要描述自己的生效方式和范围.可以类比为一个”函数”.
可以按照接受的”参数”类型分类为:

  • 时间约束:只受时间影响
  • 静态职责分离约束:不受Session影响.eg.分配角色权限只能给管理员角色分配;一个单位的最高领导只能为1人;一个数学副教授应该从数学讲师中提拔;
  • 动态职责分离约束:与Session有关.eg.一个用户可以既是项目A的程序员，也可以是项目B的测试员和项目C的验收员，但他不能同时成为同一个项目中的这3个角色

RBAC2显然实现起来更复杂,需要解析约束的定义,处理Session的校验和约束之间的相互作用,但是它能够描述实际应用中的复杂关系.
而用RBAC2的方式来考虑RBAC1的问题,也可以用角色之间的约束来实现.

RBAC3

RBAC3是RBAC1和RBAC2的综合,即能用RBAC1解决的问题用RBAC1解决,更复杂的约束遵循RBAC2(见Role-based access control): RBAC3

参考:

ACL:http://baike.baidu.com/view/18596.htm
AGDLP:https://en.wikipedia.org/wiki/AGDLP