基于上下文感知和用户组的访问控制模型

姚全营 姚淑珍 黄 河 谭火彬

(北京航空航天大学 软件学院，北京100191)

基于角色的访问控制(RBAC，Role Based Access Control)于1992年由文献［1］提出，其基本特征在于用户和访问权限之间引入了角色的概念.在进行访问控制时，将访问权限分配给角色，然后用户再通过所属的角色来获得该角色所拥有的访问权限.其中，用户与角色、角色和权限之间是多对多的关系.RBAC中用会话表示用户和角色之间的关系，用户通过建立会话激活角色，得到相应的访问权限，用户和会话是一对多的关系.

RBAC利用角色实现用户对资源的访问控制，提高了系统的资源管理能力和安全性.但随着系统应用动态要求的提高，传统的RBAC模型越来越不适应系统的访问控制要求，主要有以下一些局限性:①由于RBAC模型利用主体标识进行静态授权，并且没有规定权限在客体类上的应用范围，因此该模型缺乏足够的灵活性和动态性.例如在传统的RBAC模型中，用户一旦通过角色拥有了某类权限，无论其所处的环境如何变化，它都可以无限制地进行相应的操作.②很多系统在行业实际应用中，由于行业部门机构庞大，当为部门内部用户授权时就显得比较混乱，授权也显得不够灵活.而在RBAC的规范中没有提到关于用户是如何组织的，管理起来非常繁琐.

对于局限①，提出了一种带有上下文感知的动态访问控制［2］.因为在动态应用环境中，主体的访问除与自身的标识有关系外，还与其所处的上下文环境有关，这些上下文包括时间、安全级别和网络状况等.对于局限②，加入了用户组这一概念［3］，它是指一群用户的集合，这样可以使系统适合于分散式权限管理.当按树形结构方式将行业内所涉及的部门按行政或其他隶属关系进行组织时，授权就会清晰得多.

1 带有上下文动态感知的访问控制

上下文是普适计算中的一个概念［4］，于2000年由Anind.K.Dey提出.其定义为:对于描述一个实体状态或动作的特征以及该实体所操作的对象有用的所有信息.计算环境中有了上下文的参与，就把传统的计算环境转换成了有感知的环境，当上下文变化时，系统的访问结果也应发生变化.

文中的上下文感知信息指任何与安全相关的并且可以控制用户对客体访问的信息.带有上下文动态感知的访问控制采用“基于角色，结合上下文，在访问过程中提供动态实时的权限”.因此，在这种访问控制中角色的访问权限并非一成不变的，而是随上下文的变比而变化.提出了带有上下文动态感知的访问控制模型，如图1所示.

图1 带有动态访问控制的RBAC模型

该模型中的部分概念和定义［5］如下:

定义1 上下文信息CONS.用户或角色所处的当前应用环境信息.CONS={CONS1，CONS2，…，CONSn}，n≥ 1，∀i，j，i≠j，CONSi ≠CONSj，其中CONSi代表与应用中访问控制有关的安全环境属性.上下文服务器将每次检索到的上下文信息存储到上下文信息库中，并对上下文信息库进行实时更新.

定义2 上下文条件COND.它是由上下文值、上下文变量和运算符构成的一个布尔表达式，COND= ＜ CONSi＞ ＜OP＞ ＜Value＞，其中OP是逻辑操作符或用户自定义运算符，Value是管理员设定值.上下文条件用来比较当前上下文属性CONSi与设定上下文属性值Value是否一致，满足条件返回真，否则为假.

定义3 上下文约束规则CONR.是一个上下文条件决定规则表达式，用于描述复杂的安全要求，限制主体行为的规则.CONR=CL1∪CL2∪…∪CLn，CL=COND1∩COND2∩…∩CONDn，主体只有在满足特定的限制条件时才能执行相应的操作.例如，有上下文集合CONS={TIME，NUMBER，TRUSTLEVEL}，其访问规则为只有在时间段9:00～17:00之间并且编号在01～09之间的员工才能访问被保护的资源，否则要求用户具有高的信任级别，该规则可以表示为:CONR={TIME＞9:00∩TIME＜17:00∩ NUMBER ＞01∩NUMBER ＜09∩TRUSTLEVEL=NORMAL}∪{TRUST≥ HIGH}.

2 基于用户组的访问控制

用户组是具有某一类共同特征的若干用户组成的集合，一个用户可以属于多个用户组，一个用户组可以包含许多不同的用户.角色直接授权给用户组，而不是用户，所以传统的为用户分配角色就转化成为用户组分配角色，用户组内的用户继承所属用户组所拥有的角色.

这样，在对用户授权的时候根据用户的身份，将用户包含到某个特定的用户组中，就完成了用户的授权.当用户的身份发生变化后，只需将用户从一个用户组移出，再移入另一个用户组，就完成了用户的重新授权，这大大减少了角色分配时的工作量，能够更加方便和灵活地对用户授权并且动态地添加用户，提高了权限控制的灵活性与可维护性.改进后的权限模型如图2所示.

图2 基于用户组的RBAC模型

该模型中的部分概念和相关定义如下:

定义4 用户集合USERS={u1，u2，…，um}，其中ui(1≤i≤m)为用户标识，即 ui=userId，如ZhangSan，LiSi等.

定义5 用户组集合 GROUPS={g1，g2，…，gn}，其中gi(1≤i≤m)为用户组的标示，即gi=经理组等.

定义6 角色集合ROLES={r1，r2，… ，rn}，其中ri(1≤i≤n)为系统中存在的角色，如administrator，Manager，Employee 等.

定义7 权限集 PERM={p1，p2，… ，pk}，其中pi(1≤i≤k)为系统中所具备的权限.例如对资源的Browse和Download权限.

结合图2，o1，o2与o3是系统中受保护的资源，财务组和人力资源组全是物理组，对应着具体的部门，经理组和雇员组属于逻辑组，是具有某一类共同特征的若干用户组成的集合，user1被分到财务组里的经理组，经理组又同时拥有Manager和Employee两个角色，Manger拥有浏览和下载o1，o2，o3的权限.

3 带有上下文感知的RGBACC

3.1 模型的定义

在原有的RBAC的基础上，再结合上面提到的上下文动态感知和用户组访问控制，本文提出了带有上下文感知的基于角色和用户组的访问控制(RGBACC，Role and Group Based Access Control with Context)模型，如图3所示.

图3 RGBACC模型

为了实现RGBACC模型，定义了以下集合:

定义8 用户集合USERS={u1，u2，… ，ux}，其中ui为用户标识，即 ui=userId，如ZhangSan，LiSi等.

定义9 客体集合 OBJECTS={o1，o2，…，oy}，其中oi为客体标示，即用户所能访问的客体.

定义10 角色集合ROLES={r1，r2，… ，rn}，其中ri为系统中存在的角色，如administrator，Manager，Employee 等.

定义11 权限集PREMS={(o，d)，(o，f)|o∈O}，其中d表示对客体的下载权限，f表示对客体的浏览权限.

定义12 密级标识SEC-IDENTITY={TS，C，S，G}，客体的密级标识含有该客体的名称、ID、所属部门、秘密等级等属性，其中秘密等级分为4个级别:绝秘级TS(Top Secret)、机密级C(Confidential)、保密级S(Secret)以及一般级G(General)，其级别顺序为TS＞C＞S＞G.

定义13 用户组集合 GROUPS={g1，g2，…，gn}，其中gi为用户组的标示，每一个用户组都对应着现实社会中的一个或者多个部门，如gi包含信息部、发展部等部门.

定义14 部门集合DEPARTMENTS={d1，d2，… ，dn}，其中dj为每个部门的标识，每一个部门都对应着企业中一个真实的部门，如dj对应着系统部.

定义15 用户环境集合ENVIRONMENTS={e1，e2，… ，em}，其中 ei为每个环境的标识，每一个环境信息都包括用户的IP地址，当前时间，当前日期等元素.

定义16 会话集合 SESSIONS={s1，s2，…sn}，其中sj为每一个会话的标识，当用户被赋予相应的角色并获得该角色所被赋予的相应权限的时候，就会激活一个会话.

3.2RGBACC的形式化描述

图3定义了RGBACC模型的基本元素和各元素之间的关系，该模型支持最小特权原则，体现了最基本的角色控制思想.RGBACC模型的形式化定义如下:

1)使用 USERS，ROLES，OBJECTS，PERMS，GROUPS， DEPARTMENTS， ENVIRONMENTS，SEC-IDENTITY，SESSIONS分别表示用户集合、角色集合、操作对象集合、操作权限集合、用户组集合、部门集合、环境集合、密级标识集合与会话集合.

2)URA⊆USERS×ROLES，表示用户与角色间多对多的指派关系，每个用户可以分配多个角色，每个角色可以指派给多个用户.

3)PRA⊆PERMS×ROLES，表示许可权与角色之间多对多的指派关系，每个角色具有多个操作权限.

4)GUA⊆GROUPS×USERS，表示用户组与用户之间多对多的指派关系，每个用户组可以包含多个用户，每个用户可以分配给多个用户组.

5)GRA⊆GROUPS×ROLES，表示用户组与角色之间多对多的指派关系，每个用户组可以分配多个角色，每个角色可以指派给多个用户组.

6)DGA⊆DEPARTMENTS×GROUPS，表示部门与用户组之间多对多的指派关系，每个用户组可以属于多个部门，每个部门又可以指派给多个用户组.

7)DOA⊆DEPARTMENTS×OBJECTS，表示部门与对象之间多对多的指派关系，每个部门可以拥有多个对象，每个对象又可以属于多个部门.

8)DUA⊆DEPARTMENTS×USERS，表示部门与用户之间一对多的指派关系，每个部门可以拥有多个用户，每个用户只能属于一个部门.

9)EUA⊆ENVIRONMENTS×USERS，表示上下文环境与用户之间多对多的指派关系，每种上下文环境可以控制多种用户，每个用户可以被多种上下文环境控制.

10)SOA⊆SEC-IDENTITY ×OBJECTS，表示密级标识与操作对象之间一对多的关系，每种密级标识可以标识多个操作对象，每种操作对象只能被指定一种密级标识.

11)assigned_users:(r:ROLES)→2USERS，为角色r分配一个用户集合，assigned_users(r)={u∈USERS|(u，r)∈URA}.

12)assigned_permissions(r:ROLES)→2PRMS，为一个角色r分配一个操作权限集合，表示该角色r所拥有的权限，assigned_permissions(r)={p∈PRMS|(p，r)∈PRA}.

13)assigned_sec－identity(o:OBJECTS)→2SEC-IDENTITY，为一个操作对象o分配一个秘密等级，表示该操作对象 o所拥有的密级标识，assigned_sec-identity(o)={s∈SEC －IDENTITY|(s，o)∈SOA}.

14)session_users(s:SESSION)→USERS，会话s到该会话中激活的用户集合的映射.

15)session_roles(s:SESSION)→2ROLES，会话s到该会话激活的角色集合的映射，session_roles(si)⊆{r∈ROLES|(session_users(si)，r)∈URA.

16)avail_session_perms(s:SESSIONS)→2PRMS，在会话s中，每个用户具有一个操作权限集合，即

17)assigned_groups:(u:USERS)→2GROUPS，为用户u分配一个用户组集合，assigned_groups(u)={g∈GROUPS|(g，u)∈GUA}.

18)assigned_groups:(r:ROLES)→2GROUPS，为角色r分配一个用户组集合，assigned_groups(u)={g∈GROUPS|(g，r)∈GRA}.

19)assigned_departments:(g:GROUPS)→2DEPARTMENTS，为用户组 g分配一个部门集合，assigned_departments(g)={d∈DEPARTMENTS|(d，g)∈DGA}.

20)assigned_departments:(o:OBJECTS)→2DEPARTMENTS，为对象o分配一个部门集合，assigned_departments(o)={d∈DEPARTMENTS|(d，o)∈DOA}.

21)assigned_departments:(u:USERS)→2DEPARTMENTS，为用户u分配一个部门，assigned_departments(u)={d∈DEPARTMENTS|(d，u)∈DUA}.

22)assigned_enviroments:(u:USERS)→2USERS，为用户 u分配一个上下文环境集合，assigned_enviroments(u)={e∈ENVIRONMENTS|(e，u)∈EUA}.

4RGBACC模型的安全性描述

4.1 约束 RGBACC

约束RGBACC在RGBACC的基础上增加了约束的概念，如图4所示.在现实生活中，有时要求某些职务不能由同一人担任，这就是责任分离.一般其目的是通过指定具有不同技能和不同利益的人去完成一个完整的商业(工业，政府)行为.将这一点抽象到RGBACC系统中，就得到了约束RGBACC.约束RGBACC在RGBACC模型中添加了责任分离关系(separation of duty relationship).责任分离关系包括静态职者分离(SSD，Static Separation of Duty，也称为静态授权约束)和动态职责分离(DSD，Dynamic Separation of Duty，也称为动态授权约束).

图4 约束RGBACC

在基于角色访问控制中，分配权限时将相互冲突的角色分配给同一个用户可能产生利益冲突.可以通过使用静态授权约束来阻止这种类型的冲突，也就是说在指定角色给用户的过程中附加限制(作用于URA关系)，若两个角色被指定具有静态约束，则一个用户不能同时被指定给这两个角色.

SSD，即在系统初始化的时候，当角色分配给用户时判断是否已将冲突的角色给了同一个用户.即在RGBACC标准中，冲突的角色被定义为一个二元关系，就是说，任何一个用户只能拥有其中的一个.

SSD 的形式化描述［5］:

SSD⊆(2ROLES× N)，∀(rs，n)∈SSD，∀t⊆rs:|t|≥n⇒ ∩r∈tassigned_users(r)= ∅.

DSD，指相冲突的角色可以同时给一个人，但是在一次会话中不能同时扮演两个冲突的角色.

DSD的形式化描述:

DSD⊆(2ROLES× N)，∀rs∈s2ROLES，n∈N，(rs，n)∈DSD⇒n≥2，|rs|≥n，并且∀s∈SESSIONS，∀rs∈2ROLES，∀role_subset∈2ROLES，∀n∈N，(rs，n)∀DSD，role_subset⊆rs，role_subset⊆session_roles(s)⇒|role_subset|＜ n.

4.2 安全属性定义

这些安全属性主要实现了对角色基数、角色继承与角色职责分离关系的限制，对实际系统的开发具有较强的指导作用.下面给出这些安全属性的形式化定义:

1)每个角色的授权用户数不能超过该角色的基数(cardinality):∀r∈ROLES⇒|authorized_users(r)|≤ cardinality(r).

2)角色自己不能直接或间接地继承自己:∀r∈ROLES⇒┐(r→+r).

3)分配给同一用户的两个角色之间不具有直接或间接的继承关系:∀u∈USERS，∀r1，r2∈ROLES，r1，r2∈assigned_roles(u)⇒┐(r1→+r2).

4)两个静态互斥的角色不能被赋予给同一用户:∀u∈USERS，∀r1，r2∈ROLES，(r1，r2)∈SSD，r1∈assigned_roles(u)⇒r2∉assigned_roles(u).

5)每个角色不能与自己具有静态职责分离的关系:∀r∈ROLES⇒(r，r)∉SSD.

6)静态职责分离关系是具有对称性的:∀r1，r2∈ROLES，(r1，r2)∈ssd⇒(r2，r1)∈SSD.

7)具有静态职责分离关系的两个角色之间没有继承关系:∀r1，r2∈ROLES，r1→+r2⇒(r1，r2)∉SSD.

8)一个角色不能同时继承具有静态职责分离关系的两个角色:∀r，r1，r2∈ROLES，r→+r1，

9)若一个角色的父角色与另一角色R具有静态职责分离关系，则该角色与R也具有静态职责分离关系，形式化描述:∀r，r1，r2∈ROLES，

10)用户的活动角色集合是该用户授权角色集合的一个子集:∀u∈USERS，active_roles(u)⊆authorized_roles(u).

11)用户不能同时激活具有动态职责分离关系的两个角色:∀u∈USERS，∀r1，r2∈ROLES，r1，r2∈activate_roles(u)⇒(r1，r2)∉DSD.

12)两个角色不能同时具有静态职责分离或动态职责分离关系:∀r1，r2∈ROLES，(r1，r2)∈DSD⇒(r1，r2)∉SSD.

13)角色不能与自身动态职责分离:∀r∈ROLES⇒(r，r)∉DSD.

14)动态职责分离关系具有对称性:∀r1，r2∈ROLES，(r1，r2)∈DSD⇒(r2，r1)∈DSD.

15)具有动态职责分离关系的两个角色间无继承关系:∀r1，r2∈ROLES，r1→+r2⇒(r1，r2)∉DSD.

16)角色不能同时继承具有动态职责分离关系的两个角色:∀r，r1，r2∈ROLES，r→+r1，r→+r2⇒(r1，r2)∉DSD.

17)上述安全若角色的父角色与角色R具有动态职责分离关系，则该角色与R也具有动态职责分离关系，形式化描述为:∀r，r1，r2∈ROLES，r→+r1，(r1，r2)∈DSD⇒(r，r2)∈DSD.

规则比较详细地描述了角色之间的继承性、静态职责分离与动态职责分离等关系所应满足的一些约束条件.

4.3 安全访问规则

在一些访问控制中，这些安全访问属性主要实现了对用户基本访问控制、访问范围控制、动态环境控制.下面给出了这些安全的访问控制规则:

1)用户被赋予的角色所拥有的权限应该大于或者等于所访问的被密级标识的对象的秘密等级:∀u∈USERS，∀r∈ROLES，∀p∈PRMS，∀s∈SEC-IDENTITY，r∈assigned_roles(u)，p∈assigned_permissions(r)，s∈ assigned_secrects(o)⇒p≥ s.

2)该用户所能访问对象的范围是该用户所属的部门与该用户所属的用户组的部门的并集，再交上该用户所访问的对象所属的部门:∀u∈USERS，∀g∀GROUPS，∀o∈OBJECTS，∀d1，d2，d3∈ DEPARTMENTS，g∈ assigned_groups(u)，d1∈assigned_departments(u)，d2∈assigned_departments(g)，d3∈assigned_departments(o)⇒UserAccess⊆ (d1∩d2)∪d3.

3)用户当前的动态环境信息必须符合管理员为该用户所设置的环境信息:∀u∈USERS，∀e1，e2∈ENVIRONMENTS，e1∈getCurEnvi(u)，e2∈assigned_enviroments(u)⇒e1⊆e2.

4.4 互斥角色之间的约束条件

在RGBACC模型中，分配给同一个角色的各种权限必须满足功能权限的互斥关系，权限的互斥关系是在定义业务模块功能权限时就已经定义好了，对业务安全比较敏感的若干权限不应该分配给同一角色.为了方便定理的证明，定义了如下一些函数关系:

E:role×role—职责互斥的角色对的集合.

P［i］:授予角色 i的权限集合.

M［i］:授予角色i的用户集合.

A［s］:主体s当前激活的角色集合.

静态互斥:(∀u)(∀i，j)|i≠j:(i，j)∈E⇒u∈M［i］∧u∉M［j］

定理1［7］如果角色i和j互斥，那么不存在这样一个角色 k，k＞i∧k＞j，不存在一个公共的上界.

证明:假设存在一个角色k和互斥的角色i，j有这样的关系:

根据式(1)，得到

(i，j)∉E

这和假设矛盾，故结论成立. 证毕由定理1，可得到下面的一则推理.

推理1 在一个系统中如果存在互斥的角色，那么不能存在一个包含所有角色的根角色，即

这个推理的结论是:如果一个系统采用静态互斥，存在一个根角色的前提是:不存在互斥角色;如果一个系统采用动态互斥，存在根角色的前提是:所有角色不能同时处于激活状态，而且因为根角色继承所有角色，根角色永远不能被激活.

定理2［7］在一个系统中存在互斥角色i，j那么 P［i］和 P［j］(不相交或者 P［i］和 P［j］中至少有一项权限对方角色没有).

证明:如果系统实施完全互斥，根据

得:P［i］∩P［j］=∅

如果系统采用部分互斥，因为(∀i，j)(∃p)|i≠j:(i，j)∈E⇒(p∈P［i］⇒p∉P［j］)，所以P［i］和P［j］至少有一项权限对方角色没有成立. 证毕

这个定理的涵义是，互斥的角色可以存在一个共同的下界，它们可以共同是这个共同下界角色的父角色.

5 结论

本文扩展了传统的RBAC，提出了带有上下文感知的基于角色和用户组的访问控制模型RGBACC.RGBACC不仅继承了RBAC模型的优点，而且加入了上下文感知和用户组功能，不仅弥补了RBAC应用在动态系统中的缺陷，而且方便了用户的集中管理，提高了访问控制方面的性能，在今后的工作中，需进一步研究约束规则库的动态管理和约束规则，并把该模型应用到实践中.

References)

［1］Foster I，Kesselman C，Tuecke S.The anatomy of the grid:enabling scalable virtual organization［J］.International Journal of Supercomputer Applications，2001，2150:200 － 222

［2］姚寒冰，胡和平，李瑞轩.上下文感知的动态访问控制［J］.计算机工程与科学，2007，29(5):1－3 Yao Hanbing，Hu Heping，Li Ruixuan.Dynamic access control on context-aware［J］.Computer Engineering and Science，2007，29(5):1－3(in Chinese)

［3］叶小玲，吴敏.高效业务管理系统中权限模型的研究与实现［J］.计算机工程与设计，2010，31(2):351 －377 Ye Xiaoling，Wu Min.Research and implementation of permissions model in efficient business management system［J］.Computer Engineering and Design，2010，31(2):371 －377(in Chinese)

［4］Weiser M.The computer for the 21th Century［J］.Scientific A-merican，2001，265(3):94 －104

［5］张沙沙，姜华，谢圣献，等.基于上下文感知的RBAC动态访问控制研究［J］.计算机安全，2009(8):5－8 Zhang Shasha，Jiang Hua，Xie Shengxian，et al.Research of RBAC dynamic access control based on contexta ware［J］.Computer Security，2009(8):5 －8

［6］Gligor V D，Gavrila S I，Ferraiolo D F.On the formal definition of separation of duty policies and their composition［C］//Computer Society .Washington D C:IEEE，2007:172 －185

［7］杨晓静.RBAC模式中互斥角色的性质及其安全性［J］.计算机应用，2003，12(23):138 －142 Yang Xiaojing.The nature and safety of Exclusive role in RBAC［J］.Computer Application，2003，12(23):138 －142