1

基于角色的访问控制基础出家如初 , 成佛有余

http://www.yeeach.com

议题

访问控制基础

RBAC 模型

基于 RBAC 的系统实现

2

访问控制的概念和目标一般概念 :

―是针对越权使用资源的防御措施基本目标 :

―防止对任何资源（如计算资源、通信资源或信息资源）进行未授权的访问。从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么

未授权的访问包括―未经授权的使用、泄露、修改、销毁信息以及颁发指令等―非法用户进入系统―合法用户对系统资源的非法使用

3

主体、客体和授权客体（ Object ）：规定需要保护的资源又称作目标target)

主体（ Subject ）：或称为发起者 (Initiator) 是一个主动的实体规定可以访问该资源的实体通常指用户或代表用户执行的程序

授权（ Authorization) ： 规定可对该资源执行的动作例如读写执行或拒绝访问

一个主体为了完成任务可以创建另外的主体这些子主体可以在网络上不同的计算机上运行并由父主体控制它们；

主客体的关系是相对的

4

访问控制策略与机制

访问控制策略 (Access Control Policy): 访问控制策略在系统安全策略级上表示授权。是对访问如何控制 , 如何作出访问决定的高层指南

访问控制机制（ Access Control Mechanisms): 是访问控制策略的软硬件低层实现

访问控制机制与策略独立可允许安全机制的重用

安全策略之间没有更好的说法 , 只是一种可以比一种提供更多的保护 , 应根据应用环境灵活使用

5

访问控制策略

自主访问控制（ discretionary policies) ：基于身份的访问控制 IBAC(Identity Based Access Control)

强制访问控制 (mandatory policies), 基于规则的访问控制 RBAC （ Rule Based Access Control ）

基于角色的访问控制 RBAC （ Role Based Access Control ）

6

自主访问控制（ DAC ）基本思想

―基于身份的访问控制 IBAC(Identity Based Access Control)―对象（ object ）的创建者为其所有者（ owner ），可以完全控制

该对象―对象所有者有权将对于该对象的访问权限授予他人（ grantee ）

不同的 DAC 模型―Grantee 得到的权限能否转交他人？

Strict DAC: grantee 不能授权他人Liberal DAC: grantee 可以授权他人。根据 grantee 可以继续授权的深

度可以分为一级的和多级的―对象的所有权可否变更？―何人可进行权力的吊销（ revocation ）？

存在的问题―不易控制权限的传递―容易引起权限的级联吊销

强制访问控制（ MAC ）基于安全标记（ security labels ）

―安全标记是限制在目标上的一组安全属性信息项。在访问控制中，一个安全标签隶属于一个用户、一个目标、一个访问请求或传输中的一个访问控制信息

―最通常的用途是支持多级访问控制策略。在处理一个访问请求时，目标环境比较请求上的标签和目标上的标签，应用策略规则如（ Bell Lapadula 规则）决定是允许还是拒绝访问

基本假定（ tranquility ）―主体和客体的安全标记一旦指定，不再改变

存在的问题―配置的粒度大―缺乏灵活性

基于角色的访问控制 RBAC

基于角色的访问控制是一个复合的规则，可以被认为是 IBAC 和 RBAC 的变体。一个身份被分配给一个被授权的组

一些特点：―责任分离 (separation of duties)

―角色分层 (role hierarchies)

―角色激活 (role activation)

―用户角色关系的约束 (constraints on user/role membership)

9

访问控制的一般策略

10

RBAC与传统访问控制的差别

增加一层间接性带来了灵活性

11

议题

访问控制基础

RBAC 模型

基于 RBAC 的系统实现

12

RBAC 模型标准

NIST （ The National Institute of Standards and Technology ，美国国家标准与技术研究院）标准 RBAC 模型由 4 个部件模型组成：

―1 ．基本模型 RBAC0 （ Core RBAC ）―2 ．角色分级模型 RBAC1 （ Hierarchal RBAC ）―3 ．角色限制模型 RBAC2 （ Constraint RBAC ）―4 ．统一模型 RBAC3 （ Combines RBAC ）

http://csrc.nist.gov/groups/SNS/rbac/

13

RBAC0 （ Core RBAC ）

RBAC0 定义了能构成一个 RBAC 控制系统的最小的元素集合。

五个基本数据元素 :

―用户 users(USERS) 、角色 roles(ROLES) 、目标 objects(OBS) 、操作 operations(OPS) 、许可权permissions(PRMS)

关系―多对多，用户被分配一定角色，角色被分配一定的许可权

会话 sessions

―是用户与激活的角色集合之间的映射

14

RBAC0 （ Core RBAC ） 用户（ User ）：访问系统中的资源的主体，一般为人，也可为 Agent

等智能程序 权限（ Permission ）：对计算机中某些受保护的资源的访问许可，是

一个广义概念―可以将权限理解成一个二元组（ Operation ， Object ）

角色（ Role ）：应用领域内一种权力和责任的语义综合体―可以是一个抽象概念，也可以是对应于实际系统中的特定语义体，比如组织

内部的职务等―针对角色属性的不同，某些模型中将角色进一步细分为普通角色（ Regular

Role ）和管理员角色（ Administrative Role ） 用户指派（ User Assignment ）：用户集到角色集的多对多的关系 权限指派（ Permission Assignment ）：权限集到角色集的多对多

的关系会话（ Session ）：对应于一个用户以及一组激活的角色。用户每次必须通过建立会话来激活角色，得到相应的访问权限

RBAC0 （ Core RBAC ）

16

RBAC1 （ Hierarchal RBAC ）

RBAC1 引入角色间的继承关系。角色的结构化分层是反映一个组织的授权和责任的自然方式

角色层次图（ Role Hierarchies ）：在角色继承关系下，角色集实际上构成了一个层次图

角色间的继承关系可分为一般继承关系和受限继承关系。―一般继承关系：仅要求角色继承关系是一个绝对偏序关系，允许角色

间的多继承。―受限继承关系：则进一步要求角色继承关系是一个树结构，实现角色

间的单继承。

17

RBAC1 （ Hierarchal RBAC ）

18

RBAC1 （ Hierarchal RBAC ）示例

RBAC2 （ Constraint RBAC ）RBAC2 模型中添加了责任分离（ Separation of Duty ）关系

RBAC2 的约束规定了权限被赋予角色时 , 或角色被赋予用户时 , 以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

分类：

―静态职责分离（ Static Separation of Duty ）―动态职责分离（ Dynamic Separation of Duty

）

Static Separation of Duty静态职责分离（ Static Separation of Duty ）：指

定角色的互斥关系，用于用户指派阶段。避免同一用户拥有互斥的角色

SSD 定义了一个用户角色分配的约束关系，一个用户不可能同时分配 SSD 中的两个角色

优点：实现简单，角色互斥语义关系清楚，便于管理

缺点：不够灵活，不能处理某些实际情况

Static Separation of Duty

Dynamic Separation of Duty 动态职责分离（ Dynamic SD ）：指定角色的互斥关系，

用于角色激活阶段。允许同一用户拥有某些互斥的角色，但是不允许该用户同时激活互斥的角色。

优点：更灵活，直接与会话挂钩，适应实际管理需要

缺点：实现复杂，不易管理

Dynamic Separation of Duty

RBAC 模型的优点

模型的优点―通过角色配置用户及权限，增加了灵活性―支持多管理员的分布式管理，管理比较方便―支持由简到繁的层次模型，适合各种应用需要―完全独立于其它安全手段，是策略中立的（ policy-neutral ）

议题

访问控制基础

RBAC 模型

基于 RBAC 的系统实现

26

组织机构模型

27

组织机构模型的业务视角

业务视角：―核心元素：机构（部门 ) 、岗位、岗位权力、员工―组织机构树：任何组织机构的层级关系形成了一棵树，姑且叫组织机构树

―岗位树：与组织机构的树对应，每一个树节点都设有相应的岗位。姑且叫岗位树

―岗位权力：某个岗位具有相对的权责（权力、责任）―员工：员工定岗为某个岗位，因岗设人而非因人设岗

28

组织机构模型的系统视角

系统视角：

―核心元素：组织机构、角色、权限、用户 ( 操作员 ) 、用户组

―组织机构树：尤其是在处理集团、代理商等多层级关系结构

―系统角色树：参考 RBAC 模型中的角色分层、继承关系―资源树：在系统中所要授权的资源

例子：一级菜单 -> 二级菜单 -> 按钮

29

功能权限

功能权限一般指操作权限

功能权限解决能做什么的问题

粗略说来，界面上用于功能操作的按钮的权限都可以归为功能权限，包括：

―菜单项：系统管理菜单、账户管理菜单―功能操作按钮（与具体数据记录操作无关） ：增加、删除、

修改、查询

30

数据权限

数据权限主要是对数据记录的操作权限

数据权限解决能够对什么样数据进行操作的问题

例如：―订单记录包括如下信息：订单号、客户名、商户名、订单金额、创建时间、代理商佣金、手续费、状态

―销售只能够看见属于自己商户的所有数据―客服只能够看见所有订单的如下属性：订单号、客户名、订单金额、创建时间、状态

―财务能够查看所有订单的所有信息31

人员权限设计典型问题：性能

问题―在人员权限的角色、资源中涉及树的遍历，性能上存在较

大瓶颈解决方案

―LDAP

―缓存―key-value store

―数据冗余

32

人员权限设计典型问题：数据权限

问题―目前系统实现的数据权限都写死在代码中，导致可维护性很差

解决方案―通过动态生成 SQL 来解决

ibastis 配置文件方式将数据权限作为细粒度的资源，在资源表、权限表中设定使用单独的数据权限表来维护

―脚本语言： OGNL 、 BeanShell 、 Groovy

33

人员权限的一个设计实例

34

一个曾经的项目的设计实例

Kasai ： RBAC 的开源实现

What is Kasai?

―Kasai is a 100% Java based authentication and authorization framework. It allows you to integrate into your application a granular, complete and manageable permission scheme. The goal of the framework is to provide a simple-to-use-yet-powerful security environment for multi-user applications.

35

mysql-kasai.sqlKasai Physical Data Model.png

开源项目

Kasai

―http://kasai.manentiasoftware.com/

Open Source Identity Management Solutions Written in Java

―http://www.manageability.org/blog/stuff/single-sign-on-in-java

Spring Security （ aceig security ）―http://static.springsource.org/spring-security/site/

36

37

请提意见！