RBAC权限管理模型(转)

文档已补充完，特别感谢高海东提出宝贵的意见。当然，这还不是结束。我们还会陆续的完善这个模型，包括安全策略、资源归属控制、责任分离关系等等等等吧。。

 

1.     概念

访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主访问控制（Discretionary Access Control, DAC）和强制访问控制（Mandatory Access Control, MAC）。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。

 

自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和取消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。对于这些组织，公司或代理机构是事实上的系统客体和处理他们的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。

 

强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下：“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除）为基础”。

 

什么是基于角色访问控制（Role-Based Access Control, RBAC）？NIST 有如下定义。

访问是一种利用计算机资源去做某件事情的的能力，访问控制是一种手段，通过它这种能力在某些情况下被允许或者受限制（通常是通过物理上和基于系统的控制）。基于计算机的访问控制不仅可规定是“谁”或某个操作有权使用特定系统资源，而且也能规定被允许的访问类型。这些控制方式可在计算机系统或者外部设备中实现。

 

就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色（比如医生、护士、出纳、经理）。定义角色的过程应该基于对组织运转的彻底分析，应该包括来自一个组织中更广范围用户的输入。

 

访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个医院系统中，医生角色可能包括进行诊断、开据处方、指示实验室化验等；而研究员的角色则被限制在收集用于研究的匿名临床信息工作上。
   
    控制访问角色的运用可能是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。

 

2.     核心对象模型设计（RBAC0）

根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、控制对象（Resource Class）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：

1.        控制对象：是系统所要保护的资源（Resource Class），可以被访问的对象。资源的定义需要注意以下两个问题：

a)        资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。

b)        这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：

                         i.              一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。 例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。

                       ii.              另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。

 

2.        操作（权限）：完成资源的类别和访问策略之间的绑定。

3.        用户：权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。

4.        用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。

5.        角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。

6.        分配角色权限PA：实现操作和角色之间的关联关系映射。

7.        分配用户角色UA：实现用户和角色之间的关联关系映射。

 

 

3.     HR数据权限模型设计初稿

3.1.   访问主体

在本系统中访问主体是员工和用户组。

如图3.1.1中每个主体都有多个角色。每个角色又可能同时属于多个主体。

公司、部门、职位一定有对应的一个用户组，但用户组不一定是公司、部门、职位当中一个，也可能是虚拟出来的一个组，比如：工会组织、公司篮球队等等。

 

 

（图3.1.1）

 

3.2.   分配用户角色（Users Assignmen）

如图3.1.1这里的Users指的是所有访问主体。用户组、员工。

用户组是可以无限制扩充的。

无论添加几个主体到最后都会映射到角色（roles）表中，成为多个角色。

然后对角色分配访问权限控制。

 

3.3.     操作

操作（权限）=访问模式+资源（resource class）

如图3.3.1，比如：页面A有个查询员工信息的功能，我们在这里把他看成一个“访问客体”，被权限控制的资源（resource class）。再假设访问模式中有个“运行”模式，那么两者组合起来就是有个有效的操作（权限），然后把这个权限赋予角色，就OK了。

 

 

（图3.3.1）

 

3.4.     分配角色权限（Permission Assignment）

3.3节中提到，根据资源和访问模式、我们这里就有了很多操作，也就是权限。

那么我们只需要把这些权限分配到角色就可以了。如图3.4.1

 

 

（图3.4.1）

3.5.     资源类别（Resources Class）

 

根据以上的描述可以看出来，在本模型中主体是可以无限制扩充的。那么客体呢？我们可以看到，不管你有多少客体，到最后也都是分解成了多个资源类别（和主体一样，把每个主体都分解成了多个角色），然后和访问模式组成了操作（权限），最后赋给角色。

我们再分析下资源类别模型。

我认为我们系统的资源类别可以分为2个方向，页面功能和流程。

比如：员工资料查询，这个页面上就有查询这个客体资源类别。

而员工转正流程中又有直接主管审批这个资源。

那么我们把资源类别（resources class）设计成如图3.5.1

 

 

（图3.5.1）

 

 

功能模块表中存放“流程”或“页面功能”。

“功能模块类别”用来区分，这条记录是“页面功能”还是“流程”。

一个流程有多个审批操作。我们可以放到资源类别中。

页面功能同理。

 

 

4.     小结

该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。如表4.1

用户 能力	员工1	员工2	员工3	员工4
查看自己部门员工通讯录	部门员工	部门员工	部门员工	部门员工
查看自己部门员工全部资料	部门经理
查看自己公司员工通讯录	部门员工	部门员工	部门员工	部门员工
查看自己公司员工全部资料			档案管理员

（表4.1）

 

图4.1为整个权限模型。

 

（图4.1）

 

5.     思考

5.1.   相对角色

在很多时候我们都会用到相对角色这个概念。比如：员工转正流程中就有个直接主管审批，那么这个直接主管这个角色就是一个相对角色。这个相对角色在数据库权限模型中其实也是一个角色，只用添加到角色表中给这个角色赋权限（操作）就可以了，但在开发过程中一定要注意相对角色的设定，特别是设定方法，公式。

 

5.2.   用户组的联想

用户组可以是组织架构中的实体单位。同时也可以是虚拟的，由用户自己添加、配置的一个角色的集合。角色又是权限的集合。

那么我们可以这么做，添加一个系统管理员组，然后通过角色为这个组，分配好应有的权限。以后如果有新的系统管理员，我们只需要放到这个组里面去就可以，没必要再重新配置一个用户。

这样就完全可以实现windows的权限管理了。

 

5.3.   角色的继承

给角色分配权限（操作）其实也是件比较复杂的工作。如果角色间存在一定的关系，可以直接把另外一个角色的权限直接复制过来，然后再添加自己需要的其他权限，这样不是会方便很多吗？

继承可分为两种方式，一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系（不能继承自己的子类），允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构（单继承）。

 

 

5.4.   资源实例（Resource Instance）

场景1：有一个功能页面，查询员工资料。可访问角色有“人事专员”和“部门经理”。“人事专员”进入可以查出全公司的所有员工资料。“部门经理”进入后，只能查出自己部门的员工资料。

场景1的解决方案：

1.        在功能模块（functionmodule）表中添加“查询员工资料”这个功能。

2.        在功能资源（functionresource）表中添加这个“查询员工资料”的两个资源，“部门经理查询”和“人事专员查询”。

3.        抽象成资源类别（resourcesclass）。

4.        资源类别（resourcesclass）和访问模式（accessmode）组合成2个操作（权限）。

5.        把这两个权限分别赋予部门经理组所拥有的角色和人事专员组所拥有的角色。

6.        在开发过程中就可以根据两个不同的资源，在这个页面做查询条件的处理。

 

场景2：有一个功能页面，部门花名册。可访问角色有“部门经理”和任何登录后的员工。根据员工部门自动显示所在部门的花名册。如果是“部门经理”，就显示一些“部门经理”可以看到的敏感信息。比如，工资。

场景2的解决方案：

1.        在功能模块（functionmodule）表中添加“部门花名册”这个功能。

2.        在功能资源（functionresource）表中添加这个“部门花名册”的一个资源，“部门经理花名册”。

3.        抽象成资源类别（resourcesclass）。

4.        资源类别（resourcesclass）和访问模式（accessmode）组合成1个操作（权限）。

5.        把这个权限赋予部门经理组所拥有的角色。

6.        在开发过程中进入这个功能页面，没有这个权限的显示一般花名册。有这个权限的显示部门经理花名册。

 

小结：

资源实例让我们在按钮级权限的基础上，加上了对记录和字段的控制。当然，你也可以把场景1和场景2结合起来。记录、字段一起控制，这个肯定是可以的。

再扩展下。场景二中，如果有一天部门经理所能看到的东西改变了，加一项或少一项，怎么办呢？难道去改代码？

其实在很多情况下，都是可以做死的。比如场景二中大家都只能看到自己部门的花名册。肯定不会有一天要看公司的花名册，如果真有这个需求，那么就应该再做个功能页面。叫做“公司花名册”。

但也有些情况，是要可以调整的。同样是场景二，部门经理能看到的东西。哪天公司想变变，这个也是有可能的。

其实这个功能实现起来也非常简单。如图5.4.1。

无论什么，到最后都会变成资源类别，我们直接给这个类别记录一些属性。到时候你只要根据这些属性显示就可以了，要变的时候把这些属性变了就行了。只要愿意，完全可以做个维护页面。

表资源设置（resourcesetting）记录一些访问条件。比如，这个资源按部门查询。如果需要你可以把他改成按公司查询。

表字段设置（fieldsetting）记录的是这个资源的字段信息。比如，部门经理可以看到“部门花名册”的字段。

  

（图5.4.1）

 

6.     总结

本模型的主要设计思想是把所有访问主体，包括部门、职位、公司、人等等。全部分解成一个或多个角色。

把所有访问控制客体全部分解成一个和多个资源类别（Resources Class）。

把资源类别加上访问模式（读、写、删、运行等）成为一个操作，也就是权限。

然后把这个权限赋予到角色。

这个模型支持页面级权限、按钮级权限、记录级权限、字段级权限和这几种权限的任意组合。

在角色的分配上。他本身是支持一个客体有多个角色，一个角色属于多个客体。支持用户组角色、角色继承、相对角色等。特别是用户组这个设计。部门、职位、公司这些组织都可以抽象成一个用户组，直接给这个组分配权限就可以了。但用户组不仅仅只有抽象实体组织这功能，他还可以无限制的扩展。比如可以添加一个虚拟的系统管理员组。他本身就是一个员工的集合，你可以以任何形式去组合人员。