文/唐国华 叶羲陶

随着计算机应用的日益普及，特别是网络的迅速发展，如何在发展和推广网络应用的同时进一步提高访问控制的安全与效率，已经成为目前网络界所必须研究和解决的课题。针对不同应用的授权管理，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N 多个方案之间比较权衡，选择符合的方案。目前的授权管理一般有三种：

1.自主型访问控制方法。目前在我国的很多信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。

2.强制型访问控制方法。用于多层次安全级别的军事应用。

3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型系统的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

高校信息系统的对象包括学校所有校区、院系和部门、在校各类学生和家长、教职员工、毕业校友和国际友人，系统还涉及到上级主管部门和社会群体，用户数量多，类型复杂，采用基于角色的访问控制方法能够为高校信息系统建立一个高安全强度，更易于维护和管理，扩展能力极强的访问控制环境，并能够有效地控制管理复杂性，提供标准化和可以不断延伸的授权平台。但是，传统的基于角色的访问控制模型也存在着如下缺点：

1.模型粗糙，最小权限约束粒度还不够细化；

2.权限表示缺乏灵活性，难以实现拥有相同功能权限的用户访问不同的数据范围。

针对传统授权模型的缺点，吴江栋等人提出了基于RBAC的细粒度访问控制方法，在传统粗粒度权限管理的基础上加入“菜单－按键”对应关系使权限得以细化，但是并没有解决数据授权的问题；赵静等人提出了基于数据对象的权限访问控制模型，通过将角色分离为公有角色和私有角色，来划分用户的多个数据对象所具有的不同的功能权限，但模型的粒度只是到数据对象，而不能根据数据对象属性的不同来进行数据授权。

高校内部的业务管理相对还是比较复杂的，同一个人可能在多个部门的多个岗位任职，在相同岗位任职的可能是多人（相同部门或不同部门），同时高校内部单位众多，人员流动，职责变化频繁，为了适应高校的特定环境需求，通过扩展基于角色的授权访问控制模型，提出了基于角色的细粒度分级授权模型，通过引入业务规则和岗位实现灵活的数据授权和分级授权，有效弥补了RBAC模型的缺点，扩展了RBAC模型的动态性。

细粒度的分级授权模型

本章首先简单阐述传统的访问控制模型－RBAC（基于角色的访问控制模型），然后针对数据授权和分级授权对模型进行扩展，给出该模型的基本元素及相应函数，以及访问控制流程。

RBAC模型

RBAC的基本思想是引入角色的概念，用户和权限通过角色相关联，根据安全策略划分角色，对每个角色分配权限许可，对用户的授权通过赋予用户相应的角色来实现。使得用户和权限得到了逻辑分离，降低了安全管理成本和管理复杂性，使授权变得简单而灵活。图1是RBAC0基本模型。

RBAC包含三个实体：用户、角色和权限，其中，用户就是一个可以独立访问计算机系统中的数据或者用数据表示的其他资源的主体，一般情况下是指自然人；角色就是组织内部一件工作的功能或工作的头衔，表示该角色成员所授予的职责的许可；权限是对计算机系统中的数据或用数据表示的其他资源进行访问的许可。

用户与角色之间以及角色与权限之间用双双箭头相连表示用户角色分配和角色权限分配关系都是多对多的关系，即一个用户可以拥有多个角色，一个角色也可被多个用户所拥有。同样的，一个角色拥有多个权限，一个权限能被多个角色所拥有。用户建立会话从而对资源进行存取，每个会话将一个用户与他所对应的角色集中的一部分建立映射关系，这个角色会话子集称为会话激活的角色集。在一次会话中，用户可以执行的操作就是该会话激活的角色集对应的权限所允许的操作。

RBAC模型最突出的优点在于系统管理员能够按照学校的安全政策划分不同的角色，执行特定的任务。一个系统建立起来后主要的管理工作即为授权或取消用户的角色。用户的职责变化时只需要改变角色即可改变其权限；当组织功能变化或演进时，则只需删除角色的旧功能，增加新功能，或定义新角色，而不必更新每一个用户的权限设置。这极大地简化了授权管理，使对信息资源的访问控制能更好地适应特定单位的安全策略。

图1 RBAC模型

但是，RBAC模型仅仅解决了功能资源授权问题，对于数据资源授权，因为和业务紧密相关，必须在RBAC模型的基础上进行扩充，才能较好地解决数据资源授权问题。

图2 基于角色的细粒度分级授权模型

分级授权问题的提出

对于一个高校来说，人员的调入调出、单位变更、工作职责变化都是日常工作，而随着人员的状态、单位、职责变更，相应的授权也应该同时发生变化，这样才能更好地保障系统和信息的安全性。学校的业务部门、院系众多，如果信息系统的授权都集中在校级系统管理员或者校级系统管理小组，那么工作量将非常大，而且往往不能及时更新用户授权，也不符合目前的管理体制，研究表明，角色/权限之间的变化比用户/角色关系之间的变化相对要慢得多，并且委派用户到角色不需要很多技术，可以由业务部门人员来执行，而配置权限到角色的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给他们委派用户的权限。基于以上研究，将系统管理员划分成校级系统管理员和部门级系统管理员，把用户到角色之间的关联用分级授权机制分配给部门级系统管理员，使得：

1.授权更及时：当部门内部的人员流动、职责变更时，在部门内部即可及时处理。

2.授权更准确：部门内部的人员要使用的系统角色通常部门内部会更清楚，分配人员角色时会更准确。

3.职责分明：校级系统管理员专注于角色、功能权限、数据权限及相关关联的设定和授予，以及部门级系统管理员的管理；而部门级系统管理员则专注于用户和角色关联关系的设定。

基于角色的细粒度分级授权模型定义

本模型对RBAC模型进行了扩展，引入了业务规则、部门、岗位三个对象，把业务规则和角色相关联，通过业务规则限定用户访问的数据范围；将岗位和部门相关联，部门系统管理员能够自行设置岗位，并设置岗位包含的角色，把本部门用户分配到相应的岗位上面。整个模型如图2所示。

当用户→角色和用户→岗位→角色两条路径发生重叠时，系统将按照取并集的规则进行处理。本模型由以下几部分组成：

模型中的主要函数关系包括：

1.部门岗位设置set_department_posts：DEPT→2post，其中，{post∈POST}，每个部门都能设置一组岗位集；

2.岗位角色设置set_posts_roles：POST→2role，其中，{role∈ROLE}，每个岗位都能设置一组角色集；

3.用户岗位分配assigned_users_posts：USER→2post，其中，{post∈POST}，每个用户都能分派到一组岗位集；

4.用户角色分配assigned_users_roles：USER→2role，其中，{role∈ROLE}，每个用户都能分派一组角色集；

5.角色功能权限分配assigned_roles_permissions：ROLE→2perm，其中，{perm∈PERM}，每个角色都能分派一组权限集；

6.角色数据权限分配assigned_roles_bussinessrules：ROLE→2buss，其中，{buss∈BUSS}，每个角色都能分派一组业务规则集；

7.用户角色合成users_roles_compose：SESS×USER→ 2role， 其中{role∈ROLE|ROLEassigned_users_posts(ROLE)∪ assigned_users_roles(ROLE)},会话中用户的角色合成是用户岗位角色和用户直接角色的并集。

模型访问控制流程

整个模型的访问控制流程如图3所示。

图3 访问控制流程

基于角色的细粒度分级授权模型的应用

中山大学研究生教育管理信息系统面向的用户包括研究生院、各院系、导师、学生，学生类型复杂，各院系在管理上都有各自的特点，小的院系一个研究生秘书就分管了全部学生，大的院系则根据年级、专业的不同，由多个研究生秘书分管。在研究生院内部，不同的业务管理部门分管不同的业务。因此，在授权访问控制上面必须有灵活的数据权限控制，同时还要能提供及时、准确的授权。

系统的安全访问需求

1.功能权限因用户的层次、分管业务的不同而不同。不同的用户只能操作自己权限范围内的功能模块。

2.数据权限需要有足够细的粒度和灵活性。根据深入业务调研，发现各个院系在管理上都非常灵活，可以根据院系、专业、研究方向、培养层次（硕士、博士）、年级、单双证、专业学位等粒度进行管理。

3.授权管理必须简单、可维护。中山大学是一所综合性高等学校，院系众多，内部人员流动、岗位变更频繁，用户授权必须是动态可调整的，而且院系内部的变动一般只有院系才能准确、及时掌握，因此，必须实现授权管理的简单可操作，让非专业人员也能进行授权。

图4 基于角色的细粒度分级授权数据库物理模型

数据库设计

基于细粒度分级授权模型定义，结合安全访问需求，建立基于角色的细粒度分级授权管理的数据库模型，如图4所示，图中只给出了各表的主要属性。

在传统的RBAC模型基础上，增加了业务规则表和业务规则明细表，来控制角色能够访问的数据资源范围，业务规则表通过业务规则对应实体以及表达式将业务规则明细表中的条件进行组合，示例：业务规则对应实体为“学生基本信息”，表达式：1 AND (2 OR 3)，其中数字对应的是业务规则明细表中的业务规则明细编号，业务规则明细见表1。

那么这条业务规则的含义表示角色访问的数据权限为法学院，并且年级为2013或者2014的学生基本信息数据。通过设定业务规则，能够灵活制定相应角色的系统数据操作权限范围。

表1 业务规则明细

在分级授权实现上，引入“岗位”的概念与实际部门结构相对应。校级管理员对部门级管理员的管理体现在于对部门级管理员管理权限的分配上，部门级管理员由校级管理员管理，校级管理员分配部门级管理员能够管理的角色和人员范围，部门级管理员具有一定的自治性，在其管理范围内，能够自主管理岗位、分配人员与岗位关联、分配岗位与所管理的角色关联。

用户权限获取

用户在客户端提交登录账号和密码后，通过认证后将用户信息存入当前会话中，根据当前会话的用户信息获取用户权限集合，采用如下伪码表示：

CPermSet GetUserPerm(String userName) //获取当前用户的权限集

{

CPostSet postSet = getAssignedUserPosts(userNa me);//获取用户的岗位集

CRoleSet roleSet = [];

for (int i=0; i

roleSet= roleSet.union(getAssignedPostRoles(postS et.get(i)));//根据岗位获取角色集

}

roleSet.union(getAssignedUserRoles(username);//将用户直接角色集和岗位角色集进行合并，形成用户最终角色集

CPermSet permSet = [];

for (i=0; i

permSet.union(getAssignedRolePerms(roleSet.get(i)));//根据角色获取权限集

}

return permSet;

}

数据权限获取

当用户点击某个功能菜单或者某个操作按钮时，权限系统会从权限库中检索出当前用户使用的这个功能菜单对应的角色所拥有的业务规则，使用此业务规则作为过滤条件对用户可操作的数据范围进行控制。

Map getUserPermData(String userName, String permUrl)

{

String roleNo = getRoleFromUserPerm(userName,permUrl);//通过用户名、资源url获取对应的角色编号String bussinessRuleNo = getAssignedRoleBusines sRule(roleNo);//通过角色编号获取业务规则编号

String bussinessRuleEntity = getBussinessRuleEnti ty(bussinessRuleNo);// /通过业务规则编号获取业务规则对应的对象实体

String bussinessRuleExpr = composeBussinessRu

le(businessRuleNo);//通过业务规则编号组装业务规则表达式

Map bussinessRule = {getBussinessRuleEntity(role No), bussinessRuleExpr};//将业务规则对应的对象实体和业务规则表达式组合成Map

return businessRule;

}

角色冲突问题的解决

一个用户可以分配多个角色，一个角色又能授予多个功能资源，有可能一个用户的两个或多个不同角色授予了同一个功能资源，如果没有数据授权，那么并不会产生角色冲突，但如果使用了数据授权，则会产生角色冲突。譬如，一个用户同时被分配了法学院研究生秘书和管理学院研究生秘书的角色，这两个角色都授予了“查询学生学籍”的功能资源，此时就会产生角色冲突。解决角色冲突可以通过两个办法：

1.由用户选择当前会话使用哪个角色，系统通过会话记录用户的当前选择，在本次会话的操作中，都使用当前选择的角色。

2.增加一个角色，如上面的例子，就可以增加“法学院、管理学院研究生秘书”这样的角色，在业务规则表中设置表达式：1 OR 2，在业务规则明细表中设置,见表2。

表2 业务规则明细

上述两种方案各有利弊，第1个方案可以有效利用系统已经设定的角色，但是需要用户选择，给用户带来使用上的不便。第2个方案通过业务规则的设定避免了角色冲突，无需用户选择，用户体验会更佳，但是增加了系统管理员的角色管理负担。因此，在实际建设过程中，要按照学校的自身特点加以选择。

基于角色的细粒度分级授权模型把系统角色和业务规则、功能权限相关联，能够实现灵活的细粒度数据授权，满足业务安全需求，同时，通过岗位的设置，将用户授权管理划分到二级部门，做到及时、准确的授权。经过在中山大学研究生教育管理信息系统上面的实践检验，该模型切实可行，取得了很好的应用效果。