真假孙悟空的故事300字:RBAC的读书笔记

访问控制的研究及其在CNGI下的实现方案

 一 、背景

随着网络技术的发展和网上应用的日益增加，信息安全问题日益凸现当前信息安全技术主要包括密码技术、身份认证、访问控制、入侵检测、风险分析与评估等诸多方面在实际应用中，这些安全技术相互支持与协作，各自解决安全问题的某一方面但目前人们关注的重点是密码技术、身份认证、入侵检测等，访问控制技术没有得应有的重视事实上访问控制技术是一个安全信息系统不可或缺的安全措施，对保护主机系统和应用系统的安全都有重要意义。

访问控制技术起源于70年代，当时是为了满足管理大型主机系统上共享数据授权访问的需要但随着计算机技术和应用的发展，特别是网络应用的发展，这一技术的思想和方法迅速应用于信息系统的各个领域在30年的发展过程中，先后出现了多种重要的访问控制技术，它们的基本目标都是防止非法用户进入系和合法用户对系统资源的非法使用为了达到这个目标，访问控制常以用户身份认证为前提，在此基础上实施各种访问策略来控制和规范合法用户在系统中的行为。

 二 、传统访问控制技术

自主访问控制

自主访问控制随分时系统的出现而产生，其基本思想是：系统中的主体可以自主的将其拥有的对客体的权限部分或者全部授予其它主体。其通常通过访问控制列表（ACL：AccessControlList）来实现，包括基于行（主体）的DAC和基于列（客体）的DAC。基于行的DAC在每个主体上都附加一个该主体可访问的客体的明细表，而基于列的DAC则在每一个客体上都附加一个可以访问该客体的主体的明细表。其实现简单，在早期得到了广泛的应用。但是由于其允许访问权的传递，使得传递出去的访问权难以管理。另外其无法保护受保护资源的副本。最后，其用于管理主客体数量巨大的系统将造成开销巨大，效率低下的问题，难以满足大型应用，特别是网络应用的需要。

强制访问控制
   强制访问控制最初源于对信息机密性的要求以及防止特洛伊木马之类的攻击，其最开始应用于军方系统中。其通过对主体和客体分配固定的安全属性，利用安全属性来决定主体是否可以对客体的进行访问。安全属性是固定的，任何用户或者用户进程都无法改变自身或者其它主/客体的安全属性。另外，强制访问控制通常和自主访问控制结合使用，主体只有通过了强制访问控制和自主访问控制检查后才能访问客体，因而可以防止特洛伊木马之类的程序窃取信息。

其本质是基于格的非循环单向信息流政策。其具有两个关键规则：不向上读，不向下写，即信息只能由低安全级向高安全级流动，任何反向信息流动都是被禁止的。

虽然其通过增加访问限制来增加了信息的机密性，但是也不可避免的降低了系统的灵活性，另外其不能实施完整性控制，这限制了它在网络中的应用。再者，现代计算机中不可避免的存在大量的逆向潜信道，如：共享内存，大量的Cache，这也影响了其的广泛应用。

 三 、新型访问控制技术

基于角色的访问控制

基于角色访问控制RBAC（Role Based AccessControl）的概念早在七十年代就已经提出，但在相当长的一段时间并没有得到人们的关注。进入九十年代，安全需求的发展使RBAC又引起了人们的极大关注。

在RBAC中，在用户和访问许可权之间引入角色（Role）的概念，用户与特定的一个或多个角色相联系，角色与一个或多个访问许可权相联系，角色可以根据实际的工作需要生成或取消，而用户可以根据自己的需要动态地激活自己拥有的角色，避免了用户无意中危害系统安全。

目前以有多种模型，主要分为：

l  由Sandhu等人提出的RBAC96/ARBAC97/ARBAC02模型族

l  角色图模型

l  NIST（National Institute of Standard and Technology）模型

l  OASIS（Open Architecture for Securely Interworking Service）模型

l  SARBAC（Scope Administrative RBAC）模型

以下将就各模型分别介绍，并对比其优缺点

 1.     RBAC96

其成员间关系如下图所示：

1)         基本模型RBAC0（Core RBAC）

RBAC0由四个基本要素构成，即用户（User）、角色（Role）、会话（Session）、授权（Permission）。在一个系统中，定义并存在着多个用户、角色，同时对每个角色设置多个授权关系，称之为访问许可权的授予（PermissionAssignment）。在RBAC中，用户和角色，角色和权限的关系是多对多的关系。通过定义角色分离了用户与权限之间的直接关联，方便管理员进行人员管理和授权。授权机制可以视之为在系统内通过特定的操作(Action)将主体与客体联系起来，语义可以是允许读、允许修改等。在一个系统中，根据系统的不同，客体的种类也不同，如在操作系统中考虑的客体一般是文件、目录、端口、设备等，操作则为读取、写入、打开、关闭和运行等。RBAC模型中授权就是将这些客体的访问权限在可靠的控制下连带角色所需要的操作一起提供给那些角色所代表的用户。通过授权的管理机制，可以给一个角色以多个访问许可权，而一个访问许可权也可以赋予多个角色，同时一个用户可以扮演多个角色，一个角色也可以接纳多个用户。

在一个RBAC模型的系统中，每个用户进入系统得到自己的控制时，就得到了一个会话。每个会话是动态产生的，从属于一个用户。只要静态定义过这些角色与该用户的关系，会话根据用户的要求负责将它所代表的用户映射到多个角色中去。一个会话可能激活的角色是用户的全部角色的一个子集，对于用户而言，在一个会话内可获得全部被激活的角色所代表的访问许可权。角色和会话的设置带来的好处是容易实施最小特权原则（Least-PrivilegePrinciple）。所谓最小特权原则是将超级用户的所有特权分解成一组细粒度的特权子集，定义成不同的“角色”，分别赋予不同的用户，每个用户仅拥有完成其工作所必须的最小特权，避免了超级用户的误操作或其身份被假冒后而产生的安全隐患。

2)         角色的层次结构RBAC1（Hierarchal RBAC）

RBAC1的特征是为RBAC0上引入了角色层次的概念。在一般的单位或组织中，特权或职权通常是具有线性关系的，而角色层次RH(RoleHierarchy)可以反映这种权利责任关系，原则上RH体现了上级领导所得到的信息访问权限高于下级职员的权限。

3)        约束模型RBAC2（Constraint RBAC）

RBAC2除了继承RBAC0的原有特征外，还引入了约束(Constraints)的概念。在绝大多数组织中，除了角色的层次关系外，经常要考虑的问题是类似于下列情况：一个公司的采购员和出纳员虽然都不算是高层次的角色，但是任何一个公司都绝不会允许同时分配给某个人员以这两个角色。因为很显然，这种工作安排必然导致欺诈行为的发生。因此有必要增加约束机制。

RBAC2定义了如下约束：

互斥角色（Mutually ExclusionRoles）：同一用户在两个互斥的角色集合中只能分配给以其中一个集合中的角色，这样支持了职责分离的原则：而访问许可权的分配也有约束限制，对访问许可权的约束可以防止系统内的重要的特权被失控地分散，从而保证强制控制的可靠实施。

基数约束（Cardinality Constraints）：一个用户可拥有的角色数目受限：同样，一个角色对应的访问许可权数目但受约束。

先决条件角色（PreconditionRoles）：用户为获得某些高等级角色必须首先拥有低等级角色，同理，某一角色必须具备了某些权限才能获得更高的权限。如：总会计师必须首先是会计师，要写文件必须首先拥有读文件的权限。

运行时约束（Run Constraints）：允许一个用户具有两个角色，但在运行中不可同时激活这两个角色。

 4)     RBAC3

RBAC3是RBAC1和RBAC2两者的结合，其结构如下图所示：

2.     ARBAC97（Administrative RBAC97）

ARBAC97模型是由 Sandhu等人提出的一种 RBAC模型，在该模型中着重强

调了用角色来管理角色的思想。图3.1是ARBAC97模型

图3.1  ARBAC97模型
 

 ARBAC97模型中包含3个子模型：用户一角色分配URA97模型，角色－权限分配PRA97模型，角色－角色分配RRA97模型。

l、                           URA97模型

图3．2中表示规则角色层次图，图3.3表示管理角色层次图，管理角色层次图中的管理角色被授权对规则角色层次图中的规则角色进行管理。

图3.3管理角色层次图
 
图3.2规则角色层次图
 
   

 首先定义一个概念——先决条件。所谓先决条件是指一个前提角色和约束，或者是前提角色与约束中的任何一个布尔表达式。

URA97模型有两个组件：一个用来处理用户到角色的分配：另一个是用来处理用户成员的撤消。在URA97模型中，用户一角色分配是通过can—assign关系控制的，例如：

    can-assign（x，y, z）／／x：管理角色， y先诀条件，z：角色范围。

   举个例子来说，can-assign（PSO1，ED，｛E1｝）意味着一个管理角色PSO1成员（或者是一个高于PSO1角色的角色成员）能够分配一个用户到角色E1中，该用户要先满足具有ED角色。先决条件是一个前提角色和（或）约束的布尔表达式。例如，在先决条件 ‘ E1∧¬QE1’，‘ E1’是一个前提角色，而‘¬QE1’是一个约束。先决条件‘ E1∧¬QE1’暗示着属于E1而不属于 QE1的用户。在 URA97模型中，用户撤消是由 can一revoke关系控制着，例如：

    can-revoke（x，z）／／x：管理角色，z：角色范围。

举个例于来说，can—revoke（PSO，{PE1,QE1}）意味着管理角色PSO1成员（或者是一个高于 PSO1角色的角色成员）能够从角色 PE1或QE1中撤消用户。

该模块具有多步分配缺点。比方：一个新雇佣的工程师“John”要分配‘QE1’角色给他，按照上面的定义，“John”必须是前提角色‘E1’的成员，在“John”成为‘E1’之前，他必须是前提角色‘ED’的成员，同样的，在成为‘ED’成员之前，他必须是前提角色‘E’的成员，综上，“John”的角色分配必须按照如下次序进行：

分配“John”予‘E’角色→分配“John”予‘ED’角色→分配“John”予‘E1’角色→分配“John”予‘QE1’角色

该例子说明URA97模型需要进行多步用户分配。

同时也存在冗余角色分配信息。假设“Tom”是‘QE1’角色的一个成员，因此他也是‘E’，‘ED’，‘E1’和‘QE1’的严格成员，存储在URA中的相关信息如下图所示：

元组1，3，5并没有影响“Tom”的权限，因为‘QE1’继承了‘E1’，‘ED’，‘E’的权限，按照“Tom”的访问权限的角度来看，这三个元组都是多余的。只是由于管理的角度来看，这些表项才有存在的价值。

最后该模型还具有对用户池的组成限制。假设在这个例子中公司需要成立人事资源池H1，H2和H3，并假设新规则定义‘ProductionEngineer’必须从H1中挑选，‘QualityEngineer’必须从H2中挑选，如果不对角色层次进行更改是无法实现新规则。在URA97模型中，用户池是基于前提角色，而后者必须是角色层次的一部分。该例子说明用户池受限于角色层次。现实中有时需要一种灵活的用户池，这必将导致复杂的角色层次。

 2、             PRA97模型

PRA97模型主要讨论权限的分配与撤消。

PRA97模型与URA97模型有着相似的特征。PRA97有两个组件，一个用来处理权限到角色的分配，另一个是权限的撤消。这两个组件通过can-assignp和can-revokep来控制，例如：

can-assignp(x, y, z）／／ x：管理角色，y：先决条件，z；角色范围。

Can-revokep(x，z）／／  x：管理角色，z：角色范围。

举个例于来说， can-assignp（DSO，DIR,｛PL1，PL1｝）意味着一个管理角色DSO成员（或者是一个高于DSO角色的角色成员）能够获取分配给DIR角色的任何权限并把它分配给一个规则角色PL1。

PRA97中的撤消操作也是弱撤消。

正由于PRA97与URA97的相似性，同时也继承了类似与URA97的多步权限分配、冗余权限分配信息和对权限池组成限制的缺陷，同时还具有以下缺陷：

l        无法对权限池进行限制

假设存在can-assignp（SO1，R2，[R1，R1]），那么SO1就能将R2的任何权限授予R1，而无法对其进行限制。如何将R2中的一些特定权限授予R1？在PRA97中我们无法直接表达。通过“稳定成员资格（immobilemembership）”可以得到表述，但是该方法需要权限池的额外信息。

l        边界效应

该缺点是上一个问题的进一步深化。角色层次和角色范围如上图所示，如果存在can-assignp（PSO1，PL1，[QE1，QE1]），那么‘PSO1’就能将‘PL1’的任何权限授予‘QE1’，因此‘QL’就将继承‘QE1’的所有权限，因为‘QL1’是‘QE1’的一个双亲节点。这就是说‘PSO1’就能通过删除‘PL1’某些权限来删除‘QL’对应的权限，但是由图可见，‘QL’在‘PSO1’的管理范围之外，这必将导致权限的非法流向问题。