RBAC模型

http://www.family168.com/oa/springsecurity/html/ap08-rbac.html

RIA知识库 
flex 
RIA

 

访问控制策略一般有以下几种方式：

• 自主型访问控制（Discretionary Access Control-DAC）：用户/对象来决定访问权限。信息的所有者来设定谁有权限来访问信息以及操作类型（读、写、执行。。。）。是一种基于身份的访问控制。例如UNIX权限管理。

• 强制性访问控制（Mandatory Access Control-MAC）：系统来决定访问权限。安全属性是强制型的规定，它由安全管理员或操作系统根据限定的规则确定的，是一种规则的访问控制。

• 基于角色的访问控制（格/角色/任务）：角色决定访问权限。用组织角色来同意或拒绝访问。比MAC、DAC更灵活，适合作为大多数公司的安全策略，但对一些机密性高的政府系统部适用。

• 规则驱动的基于角色的访问控制：提供了一种基于约束的访问控制，用一种灵活的规则描述语言和一种ixn的信任规则执行机制来实现。

• 基于属性证书的访问控制：访问权限信息存放在用户属性证书的权限属性中，每个权限属性描述了一个或多个用户的访问权限。但用户对某一资源提出访问请求时，系统根据用户的属性证书中的权限来判断是否允许或句句

模型的主要元素

• 可视化授权策略生成器

• 授权语言控制台

• 用户、组、角色管理模块

• API接口

• 授权决策引擎

• 授权语言解释器

H.1. RBAC模型介绍

RBAC(Role-Based Access Control - 基于角色的访问控制)模型是20世纪90年代研究出来的一种新模型，但从本质上讲，这种模型是对前面描述的访问矩阵模型的扩展。这种模型的基本概念是把许可权（Permission）与角色（Role）联系在一起，用户通过充当合适角色的成员而获得该角色的许可权。

这种思想世纪上早在20世纪70年代的多用户计算时期就被提出来了，但直到20世纪90年代中后期，RBAC才在研究团体中得到一些重视。本章将重点介绍美国George Mason大学的RBAC96模型。

H.2. 有关概念

在实际的组织中，为了完成组织的业务工作，需要在组织内部设置不同的职位，职位既表示一种业务分工，又表示一种责任与权利。根据业务分工的需要，支援被划分为不同群体，各个群体的人根据其工作任务的需要被赋予不同的职责和权利，每个人有权了解与使用与自己任务相关的信息与资源，对于那些不应该被知道的信息则应该限制他们访问。这就产生了访问控制的需求。

例如，在一个大学中，有校长、副校长、训练部长、组织处长、科研处长、教保处长等不同的职位，在通常情况下，职位所赋予的权利是不变的，但在某个职位上工作的人可以根据需要调整。RBAC模型对组织内部的这些关系与访问控制要求给出了非常恰当的描述。

H.2.1. 什么是角色

在RBAC模型中，工作职位被描述为“角色”，职位所具有的权利称为许可权。角色是RBAC模型中的核心概念，围绕这一概念实现了访问控制策略的形式化。特殊的用户集合和许可权的集合通过角色这一媒介在某个特定的时间内联系在一起。而角色确实相对稳定的，因为任何组织的分工、活动或功能一般是很少经常改变的。

可以有不同的动机去构造一个角色。角色可以表示完成特殊任务的资格，例如，是一个医师还是一个药师；橘色也可以表示一种权利与责任，如工程监理。权利与责任不同于资格，例如，Alice可能有资格领导几个部门，但他只能被分配负责一个部门的领导。通过多个用户的轮转，角色可以映射特殊责任的分配，例如，医师可以转换为管理者。RBAC的模式及其实现可以方便的适应这种角色概念的多种表现。

在实际的计算机信息系统中，角色由系统管理员定义，角色的增加与删除、角色权利的增加与减少等uanli工作都是由系统管理员完成的。根据RBAC的要求，用户被分配为某个特定角色后，就被赋予了该角色所拥有的权利和责任，这种授权方式是强制性的，用户只能被动的接受，不能自主的决定为角色增加或减少权力，也不能把自己角色的权利转首给用户，显然，这是一种非自主型的访问控制模式。

H.2.2. 角色与用户组

角色与用户组有何区别？

两者的主要区别是：用户组是用户的集合，但不可许可权的集合；而角色却同时具有用户集合和许可权集合的概念，角色的作用是把这两个集合联系在一起的中间媒介。

在一个系统中，如果用户组的许可权和成员仅可以被系统安全员修改的话，在这种机制下，用户组的机制是非常接近于角色的概念的。角色也可以在用户组的基础上实现，这有利于保持原有系统中的控制关系。在这种情况下，角色相当于一个策略不见，与用户组的授权及责任关系相联系，而用户组是实现角色的机制，因此，两者之间是策略与实现机制之间的关系。

虽然RBAC是一种无确定性质策略的模型，但它支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。

责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计连个角色参加就可以了。

数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用，借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置 RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。

RBAC96是一个模型族，其中包括RBAC₀~RBAC₃四个概念性模型。基本模型RBAC₀定义了完全支持RBAC概念的任何系统的最低需求。RBAC₁和RBAC₂两者都包含RBAC₀，但各自都增加了独立的特点，它们被成为高级模型。在RBAC₁中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。RBAC₂增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

RBAC₁和RBAC₂之间是不可比的。RBAC₃被成为统一模型，它包含了RBAC₁和RBAC₂，利用传递性，也把RBAC₀包括在内。这些模型构成了RBAC96模型族。图ap08-01表示了族内各模型间的关系，图ap08-02是RBAC₃模型的概念示意图。

图 H.1. RBAC96内各模型间的关系

图 H.2. RBAC96模型族

H.3. 基本模型RBAC₀

RBAC₀的模型结构可以参看图ap08-02，但需要把途中的限制和角色等级两部分不包含在RBAC₀模型中。该模型中包括用户（U）、角色（R）和许可权（P）的那个三类实体集合，此外还有一个会话集合（S）。

其中用户代表一个组织的职员；角色表示该组织内部的一项任务的功能或某个工作职务，它也表示该角色成员所拥有的权利和职责；许可权是用户对系统中各课题访问或操作的权利，客体是指系统中的数据客体和资源客体，例如，目录、文件、记录、端口、设备、内存或子网都是客体。

许可权因客体不同而不同，例如，对于目录、文件、设备、端口等类客体的操作权是读、写、执行等；对应数据库管理系统的客体是关系、元素、属性、记录、库文件、视图等，相应的操作权是Select、Update、Delete、Insert等；在会计应用中，相应的操作权是预算、信用、转移、创建和删除一个账目等。

图ap08-02说明了关系用户指派UA（User Assignment）与许可权指派PA（Permission Assignment）的含义，两者都是多对多的关系。RBAC的关键就在于这两个关系，通过它们，一个用户将最终获得某些许可权并执行的权力。从图中角色的位置可以看粗，它是用户能够获取许可权的中间媒介。

会话集中的每个会话表示一个用户可以对应多个角色（指向角色有两个箭头）。在某个会话的持续期间，一个用户可以同时激活多个角色，而该用户所获得的许可权是所有这些角色的所拥有许可权的并集。

每个用户可以同时打开多个回话，每个会话都可以在工作站屏幕上用一个窗口显示。每个会话可以有不同活动角色的组合。RBAC₀的这一特点将受到最小特权原则的限制。如果一个用户在一次会话中激活所有角色的权利超过该用户被允许的权利，将受到最小权利原则的限制。

H.3.1. RBAC₀模型的形式定义如下

定义1 RBAC₀模型由以下描述确定：

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

用户：S→U 每个会话s_i到单个用户user(s_i)的映射函数（常量代表会话的声明周期）。

角色：S→2^R 每个会话s_i到角色子集roles(s_i) {r|user(s_i, r')∈UA}（能随时间改变）的映射函数，会话s_i有许可权U_r∈roles(s_i){p|(p,r')∈PA}。

在使用RBAC₀模型时，应该要求每个许可权和每个用户至少应该被分配给一个角色。两个角色被分配的许可权完全一样是可能的，但仍是两个完全独立的角色，用户也有类似情况。角色可以适当的被看做是一种语义结构，是访问控制策略形式化的基础。

RBAC₀把许可权处理未非解释符号，因为其精确含义只能由实现确定且与系统有关。RBAC₀中的许可权只能应用于数据和资源类客体，但不能应用于模型本身的组件。修改集合U、R、P和关系PA和UA的权限称为管理权限，后面将介绍RBAC的管理模型。因此，在RBAC₀中假定只有安全管理员才能修改这些组件。

会话是由单个用户控制的，在模型中，用户可以创建会话，并有选择的激活用户角色的某些子集。在一个会话中的角色的激活是由用户来决断的，会话的终止也是由用户初始化的。RBAC₀不允许由一个会话去创建另一个会话，会话只能由用户创建。

H.4. 角色分级模型RBAC₁

RBAC₁模型的特色是模型中的角色是分级的，不同级别的角色由不同的职责与权力，橘色的级别形成偏序关系。图ap08-03说明了角色等级的概念。在途中位置处于较高处的角色的等级高于较低位置角色的等级。利用角色的分级概念可以限制继承的范围（scope）。

图 H.3. 角色分级的概念

图中项目成员的等级最低，角色程序员和测试员的等级都高于角色项目成员，并都可以继承项目成员的权利；角色管理员具有最高的等级，它可以继承测试员和程序员的权利。为了满足实际组织中一个角色不完全继承另一个角色所有权利与责任的需求，模型中引入了私有角色的概念，如图中的测试员'和程序员'分别是测试员和程序员的私有uese，它们可以分别继承测试员和程序员的某些专用权利。

显然，角色的等级关系具有自反性（自己可以继承自己）、传递性（A继承B，B继承C，则A继承C）和反对称性（A继承B，B继承A，则A=B），因此是偏序关系，下面是RBAC₁的形式定义。

H.4.1. 定义2：RBAC₁由以下内容确定

U、R、P、S分别表示用户集合、角色集合、许可权集合和会话集合。

PA P×R表示许可权与角色之间多对多的指派关系。

UA U×R表示用户与角色之间多对多的指派关系。

RH R×R是对R的偏序关系，称为角色等级或角色支配关系，也可用≥符号表示。

用户：S→U 每个会话s_i到单个用户user(s_i)的映射函数（常量代表会话的声明周期）。

角色：S→2^R 每个会话s_i到角色子集roles(s_i) {r|(r'≥r)[user(s_i, r')∈UA]}（能随时间改变）的映射函数，会话s_i有许可权U_r∈roles(s_i){p|(r''≤r)[(p,r'')∈PA]}。

H.5. 限制模型RBAC₂

RBAC₂模型是在RBAC₀模型增加限制后形成的，它与RBAC₁并不兼容。RBAC₂定义如下：

H.5.1. 定义3：

除了在RBAC₀中增加了一些限制因素外，RBAC₂未加改变的来自于RBAC₀，这些限制是用于确定RBAC₀中各个组件的值是否是可接受的，只有那些可接受的值才是允许的。

RBAC₂中引入的限制可以施加到RBAC₀模型中的所有关系和组件上。RBAC₂中的一个基本限制时互斥角色的限制，互斥角色是指各自权限尅一互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

例如，在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。又如，在公司中，经理和副经理的角色也是互斥的，合同或支票只能由经理签字，不能由副经理签字。在为公司建立的RBAC₂模型中，一个用户不能同时兼得经理和副经理两个角色。模型汇总的互斥限制可以支持权责分离原则的实现。

更一般化而言，互斥限制可以控制在不同的角色组合中用户的成员关系是否是可接受的。例如，一个用户可以既是项目A的程序言，也可以是项目B的测试员和项目C的验收员，但他不能同时成为同一个项目中的这3个角色。RBAC₂模型可以对这种情况进行限制。

另一个用户指派限制的例子是一个角色限制其最大成员数，这被称为角色的基数限制。例如，一个单位的最高领导只能为1人，中层干部的数量也是有限的，一旦分配给这些角色的用户数超过了角色基数的限制，就不再接受新配给的用户了。

限制角色的最小基数实现起来有些困难。例如，如果规定占用某个角色的最小用户数，问题是系统如何在任何时刻都能知道这些占用者中的某个人没有消失，如果消失的话，系统又应该如何去做。

在为用户指派某个角色A时，在有的情况下要求该用户必须是角色B的一个成员，B角色成为角色A的先决角色。先决角色（Prerequisite Roles）的概念来自于能力和适应性。对先决绝对的限制成为先决限制。一个通俗的例子是，一个数学副教授应该从数学讲师中提拔，讲师是任副教授的先决角色。但在实际系统中，不兼容角色之间的先决限制的情况也会发生。

在图ap08-03中，可以限制只有本项目的成员才有资格担任程序员的角色，通常在一个系统中，先决角色比新指派的角色的级别要低一些。但有的情况下，却要求只有当用户不是某个特殊角色时，才能担任另一个角色A。如，需要执行回避策略时需要这样做，例如，本课题组成员不应当是本项目成果鉴定委员会的成员。这类限制也可以推广到许可权方面。

由于用户与角色的作用会与会话联系在一起，因此对会话也可以施加限制。例如，可以允许一个用户被指派给两个角色，但不允许在同一时间内把该用户在两个角色中都激活。另外，还可以限制一个用户在同一时间内可以激活的会话的数量，相应的，对该用户所激活的会话中所分配许可权的数量也可以施加限制。

前面提到的继承概念也可以视为一种限制。被分配给低级别角色的权限，也必须分配给该角色的所有上级角色。或等价的，一个指派给较高级别的角色的用户必须指派给该角色的所有下级角色。因此从某种角度上讲，RBAC₁模型是冗余的，它被包含在RBAC₂中。但RBAC₁模型比较简洁，用继承代替限制可使概念更清晰。

实现时可以用函数来实现限制，当为用户指定角色或为角色分配权限时就调用这些函数进行检查，根据函数返回的结果决定分配是否满足限制的要求，通常只对那些可被有效检查和那些惯例性的一些简单限制给与实现，因为这些限制可以保持较长的时间。

模型中的限制机制的有效性建立在每个用户只有唯一标识符的基础上，如果一个实际系统支持用户拥有多标识符，限制将会失效。同样，如果同一个操作可以有两个以上的许可权来比准，那么，RBAC系统也无法实施加强的基本限制和责任分离饿限制。因此要求用户与其标识符，许可与对应的操作之间一一对应。

H.6. 统一模型RBAC₃

RBAC₃把RBAC₁和RBAC₂组合在一起，提供角色的分级和继承的能力。但把这两种概念组合在一起也引起一些新问题。

限制也可以应用于角色等级本身，由于角色间的等级关系满足偏序关系，这种限制对模型而言是本质性的，可能会影响这种偏序关系。例如，附加的限制可能会限制一个给定角色的应有的下级角色的数量。

两个或多个角色由可能被限制成没有公共的上级角色或下级角色。这些类型的限制在概念角色等级的权力已经被分散化的情况下是有用哦，但是安全主管却希望对所有允许这些改变的方法加以限制。

在限制和角色的等级之间也会产生敏感的相互影响。在图ap08-03的环境中，一个项目成员不允许同时担任程序言与测试员的角色，但项目管理员所处的位置显然是违反了该限制。在某种情况i下由高等级的角色违反这种限制是可接受的，但在其他情况下又不允许这种违反现象发生。

从严格性的角度来讲，模型的规则不应该是一些情况下不允许而在另一情况下是允许的。类似的情况也会发生在对基数的限制上。假定限制一个用户之多能分配给一个橘色，那么对图中的测试员的一个指派能够未被这种限制吗？换句话说，基数限制是不是只能用于直接成员，是否也能应用于继承成员上？

私有角色的概念可以说明这些限制是有用的。同样在图ap08-03的环境中，可以把测试员'，程序员'和项目管理员3个角色说明为互斥的，它们处于同一等级，没有共同的上级角色，所以管理员角色没有违反互斥限制。通常私有角色和其他角色之间没有公共上级角色，因为它们是这个等级的最大元素，所以私有角色之间互斥关系可以无冲突的定义。

诸私有角色之间的相同部分可以被说明为具有0成员的最大技术限制。根据这种方法，测试员必须被指派给测试员'这个角色，而测试员角色就作为与管理员角色共享许可权的一种工具。

在前面的讨论中，我们都假设RBAC的所有组件都是由单个的安全员来管理里。但是，对于一个大系统而言，系统中的角色可能成百上千，再加上它们之间的复杂关系，使得集中式的管理任务成为非常可怕的工作，因此通常由几个管理员小组来完成。能否用RBAC管理自己本身呢？

RBAC的管理模型示于图ap08-04。该图的上半部分本质上与图ap08-02相同，图中的限制时针对所有成分的，图的下半部分是对上半部分关于管理角色AR和管理许可权AP与正规角色集R和许可权集P是分别不可相交的。这个模型显示，正规许可权只能分配给正规角色（RBAC模型中定义的角色），管理许可权只能分配给管理角色。

H.7. 定义4

管理许可权AP有权改变组成RBAC₀、RBAC₁、RBAC₂或RBAC₃的所有成分，但正规许可权P不能。管理许可权与正规许可权不相交，即AP∩P=。管理许可权和正规许可权只能分别分配给管理角色AR和正规角色R，并且AR∩R=。

图 H.4. 管理模型示意图

在图ap08-04的上半部可以对应RBAC₀、RBAC₁、RBAC₂和RBAC₃模型，类似地下半部可以对应ARBAC₀、ARBAC₁、ARBAC₂和ARBAC₃模型，此处的A表示“管理”。ARBAC₀~ARBAC₃形成了RBAC的管理模型族，成为ARBAC97。通常我们期望管理模型比RBAC模型本身简单一些，因此可以利用ARBAC₀管理RBAC₃，而不是用ARBAC₃去管理RBAC₀模型。

H.8. 在ARBAC97中，包括三种组件

URA87：用户-角色指派。该组件涉及用户-指派关系UA的管理，该关系把用户与角色关联在一起。对该关系的修改权由管理角色控制，这样，管理角色中的成员有权管理正规角色中的成员关系。把一个用户指定为管理角色是在URA97以外完成的，并假定是由安全员完成的。

PRA97：许可权-角色指派。该组件涉及角色-许可权的指派与撤销。从角色观点来看，用户和许可权有类似的特点，它们都是由角色联系在一起的实在实体。因此，可以把PRA97看做是URA97的对偶组件。

RRA97：角色-角色指派。为了便于对角色的管理，对角色又进行了分类。该组件涉及3类角色，它们是：

1. 能力（Abilities）角色——进以许可权和其他能力做成成员的角色。

2. 组（Groups）角色——仅以用户和其他组为成员的一类角色。

3. UP-角色——表示用户与许可权的角色，这类角色对其成员没有限制，成员可以使用户、角色、许可权、能力、组或其他UP-角色。

区别这三类模型的主要原因是可以应用不同的管理模型去建立不同类型角色之间的关系。区分的动因首先是对能力的考虑，能力是许可权的集合，可以把该集合中所有许可权作为一个单位指派给一个角色。类似的，组是用户的集合，可以把该集合中所有许可权作为一个单位指派给一个角色。组和能力角色都似乎可以划分等级的。

在一个UP-角色中，一个能力是否是其的一个成员是由UP-角色是否支配该能力决定的，如果支配就是，否则就不是。相反的，如果一个UP-角色被一个组角色支配，则这个组就是该UP-角色的成员。

对ARBAC97管理模型的研究还在继续之中，对能力-指派与组-指派的形式化已基本完成，对UP-角色概念的研究成果还未形式化。

H.9. RBAC模型的特点

符合各类组织机构的安全管理需求。RBAC模型支持最小特权原则、责任分离原则，这些原则是任何组织的管理工作都需要的。这就使得RBAC模型由广泛的应用前景。

RBAC模型支持数据抽象原则和继承概念。由于目前主流程序设计语言都支持面向对象技术，RBAC的这一特性便于在实际系统中应用实现。

模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体，便于设计者建立现存的或待建系统的RBAC模型。

RBAC模型仍素具访问控制类模型，本质是对访问矩阵模型的扩充，能够很好的解决系统中主体对客气的访问控制访问权力的分配与控制问题，但模型没有提供信息流控制机制，还不能完全满足信息系统的全部安全需求。

虽然也有人认为可以用RBAC去仿真基于格的访问控制系统（LBAC），但RBAC对系统内部信息流的控制不是直观的，需要模型外的功能支持。有关信息流控制的作用域原理将在第四章介绍，届时读者可以进一步理解RBAC模型的这种缺陷。

RBAC模型没有提供操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作次序的实体系统，例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到模型外去实现。

RBAC96模型和RBAC97uanli模型都故意回避了一些问题，如是否允许一个正在会话的用户再创建一个新会话，管理模型不支持用户和许可权的增加与删除等管理工作灯，都是需要解决而未提供支持的问题，这些问题都还在研究中，但是如果缺少这些能力的支持，模型的而应用也将受到影响。相反，访问绝阵模型提供了用户和权限修改功能，因此，不能说RBAC模型能够完全取代访问矩阵模型。

评论

2 楼 yupengcc 2012-07-14  

资料带走 3Q

1 楼 JUN001 2011-11-14  

  附带的资料很不错，谢谢分享~