浅谈RBAC/WEB

LUPA 2007-09-14

展开全文

大致规划权限管理文章的框架：（RBAC/Web）

1、浅述权限管理的现在

2、重点论述ＲＢＡＣ

3、结合实际进行设计

4、自己的一些感受

参考：

　http://csrc./rbac/

　　http://www.list./

　　http://www./sigsac/sacmat.html

http://www./pubs/contents/proceedings/series/rbac/

http://icecloud./blog/archives/000147.html

正文：

1、浅述权限管理的现在

对于在企业环境中的访问控制方法，一般有三种：

第一种：授权（Authorization），也叫做自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。

第二种：多级安全（Multilevel Security），也叫做强制型访问控制方法。用于多层次安全级别的军事应用。

第三种：基于角色的访问控制方法（RBAC），是目前公认的解决大型企业的统一资源访问控制的有效方法。

其显著的两大特征是：

1.减小授权管理的复杂性，降低管理开销。

2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

访问控制的一般策略：（如图）

2、重点论述ＲＢＡＣ

下面是RBAC 原理结构示意图：

名词解释：

1、 USERS：可以是人，设备，进程。

2、 ROLE(角色)：是指具有一定技能、可以执行某些工作的人员（或资源）集合。通过给成员赋予不同的角色，对成员的多职能进行表达，提供约束成员不同权限范围变化的依据。（是粗粒度和细粒度(业务逻辑)的接口）它具有层次关系和继承的特性。角色层次的上方是具有较高权限的角色，而下方则代表较低权限的角色。

3、 Permission(许可)：描述了角色对OP 或OB 所具有的权限，其反映的是授权的结果。比如授予角色A 对资源B 有读的权限，则代表了一个许可的存在，这个许可表示：角色A获取了对资源B 读的许可。针对object（OB）来说，其描述的是permission 和object 之间的一种关联关系，而这层关系则表示了某一角色对某一资源客体（object）所具有的权限及权限状态；针对operation（OP）来说，其描述的是permission 和operation 之间的一种关联关系，而这层关系则表示了某一角色对某一操作（operation）所具有的权限及权限状态）

4、 Assignment(分配)：分配（assignment）则包含两个方面，用户分配（user assignment）和许可分配（permission assignment）。用户分配表示的是，将用户或用户组分配给特定的角色。许可分配表示的是，为角色分配访问许可（访问object 和opertiaon 的许可）。

5、 Sessions（会话）:这跟WEB的SESSION的不同。这里的Session是用户与激活的角色集合之间的映射。

6、 Constraints（限制）：对user分配角色或角色分配许可加入条件限制。如：1、在user分配角色时，可以根据需求，限制某些角色无法同时分配给同一个user.2、限制角色的user,如：总经理只能由一个担任。3、先决角色（prerequisite roles）。也就是在有这个角色之前必须要有一个角色存在。

上图中描述了一个会话代表某段时间user和role间的一个映射关系。User先透过建立的会话（可以不只一个）映射到role上，而角色再映射到事先被许可的许可上，这些映射都须满足存在于user、role、role层次间的限制。

RABC模型分为是个四个模型

1、Core RBAC

图中的ops代表operations obs代表objects,叫客体，即规定的需要保护的资源，又称目标。

2、Hierarchal RBAC

这个模型是在角色间衍生出层次性的关系。如图2，这样就可以把一些较为基本的权限分配给层次较为低的角色，再利用继承的方式继承权限，这样就免去了每个角色都要重复一些基本的权限分配行为，从而减轻了维护上的负担。

同时，Hierarchical RBAC 又可以分为：

1、 General Hierarchical RBAC（一般性层次模型）：指上层的角色可以继承下层的所有权限，而且没有任何限制。

2、 Limited Hierarchical RBAC（限制性层次模型）：指上层的角色继承下层的权限是有限制范围的。

后面两种模型是权责分离（Separation of Duty）的。权责分离主要是防止使用者拥有的权限过多，而造成资源滥用或者利益冲突（conflict of interest）的情况发生。

3、Static Separation of Duty Relations（静态权责分离）

又称强互斥。指具有冲突的角色不能同时分配给同一个使用者，以避免利益冲突（conflict of interest）

4、Dynamic Separation of Duty Relations（动态权责分离）

图中的DSD：Dynamic separation of duty的缩写。

动态权责分离又称为弱互斥。指使用者可以同时拥有相互冲突的角色，但是使用者不能在统一时间担任。

在RBAC中的各个模型中，都是由一下成分所组成：

1、一些基本的元素。（a set of basic element sets）。

2、一序列的RBAC的关系，也包含了包含有效的笛卡儿积的子集。（a set of RBAC relations involving those element sets (containing subsets of Cartesian products denoting valid assignments）

3、一些映射功能。为一个给定的实例确定的一种元素中产生成员的实例。（a set of Mapping Functions which yield instances of members from one element set for a given instance from another element set.）

3、结合实际进行设计

下面我就以时义浩维公司为例。在设计之前我们先要分清一些概念。

权限逻辑和业务逻辑？

业务逻辑就是情况由系统运行时的某些条件决定，如公司营销中心的直销部各成员进入系统只能看到自己所负责的区域销售记录，而权限逻辑？如直销部各成员不能看其他部门的成员的记录，这是有各自不同身份来决定的。

粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特

定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。

细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细

粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

系统设计的目标：

1、直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要。

2、简单实用，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

3、扩展，采用可继承在扩展上的困难。系统可以根据公司的发展而相应的扩展，从而达到可维护性。