4A arbac97.docx

4A arbac97.docx

《4A arbac97.docx》由会员分享，可在线阅读，更多相关《4A arbac97.docx（28页珍藏版）》请在冰豆网上搜索。

4Aarbac97

RBAC97模型的基于角色的角色管理

1前言

基于角色的访问控制（RBAC）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注（参考本刊物的姊妹篇[NyanchamaOsborn1999;Bertmoetal1999;Ferraioloetal1999]）。

在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。

这就极大地简化了权限的管理。

在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。

角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。

角色与角色的关系可以建立起来以囊括更广泛的客观情况。

RBAC是中性策略且灵活的，这种实施的策略可以通过对RBAC各部件的详细配置而得到。

RBAC的灵活性允许广泛范围的访问策略得以实施。

作为灵活性的体现，RBAC可以通过适当配置而实行传统的强制访问控制（MAC）[NyanchamaandOsborn1996;Somdhu1996]）和自主访问控制（DAC）[Sandhuandmanawer1998]）.

RBAC支持三个著名的安全原则：

最小权限原则，责任分离原则和数据抽象原则。

最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。

责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。

数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。

然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

对RBAC的管理很重要，必须仔细控制，以确保控制策略不会游离原始的目的。

在一个大的商业系统中，角色可能成千上百，而用户则可能是成千上万。

对这些角色、用户及它们相互关系的管理是一个艰巨的任务，它不可能集中在一个小的安全小组中去完成。

下放RBAC的管理权，而又不失广义上的集中式控制，对系统设计师和结构师来说是一个具有挑战性的目标。

分权过程中有可量测性的要求而且还要保持紧密的控制，两者之间的协调有很大压力。

对此问题的彻底的解决需求更近一步的研究并面临重大的理论问题（参考例子：

Harrisonetal[1976];Sanhu[1992];andSandhuandCanta[1995]）我们的工作为此目标提供一个实际而又意义的探索。

既然RBAC的最主要优点是方便管理，很自然地会问RBAC怎样管理自己呢？

相信RBAC管理RBAC是其长期成功中的一个重要因素。

本文的一个中心贡献就在于为基于RBAC管理提供一个广泛的模型。

RBAC有许多部件，这使得RBAC的管理多面化。

尤其是，我们要分割这些问题来讨论：

用户与角色的指派；角色与权限的指派；为定义角色的继承进行的角色与角色的指派。

这些活动都要求把用户和权限联系起来。

然而在很多情况下它们最好由不同的管理员或管理角色来做。

对角色指派权限是典型的应用管理者的职责。

银行应用中，把借款、存款操作权限指派给出纳角色，把批准贷款操作权限指派给经理角色。

而将具体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。

角色与角色的指派包含用户与角色的指派、角色与权限的指派的一些特点。

更一般来说，角色与角色的关系体现了更广泛的策略。

我们的管理模型称为RBAC97，他有3个部件：

URA97关注用户与角色的指派；PRA97关注角色权限的指派；RRA97处理角色与角色的指派。

RRA97本身具有若干个部件，它们由不同种类的角色所组成，将在第五节讨论。

文章的剩余部分如下组织；第2节回顾RBAC96模型，ARBAC97在此背景下展开。

第3、4、5节分别描述URA97、PRA97和RRA97。

第6节讨论ARBAC97的其他方面，包括实施和扩充，第7节总结本文。

2RBAC96模型

RBAC模型的常见家族称作RBAC962。

由Sandhuetal定义。

图1描述了在这个家族中最常见的模型。

简单起见，我们使用术语RBAC96既指模型家族也指家族中最常见的成员。

图1

图1的上半部分给出了对数据和资源进行访问的常规权限和角色；下半部分给出了管理角色和权限。

直观地讲，一个用户是指一个自然人或是一个自治的代理，一个角色是组织范围内的一个职位功能或职位名称，它包含赋予角色成员的权力和职责相关的语义。

一个权限是对系统中以特定模型访问一个或多个对象的批准或能够实施特定行为的某种特权。

先介绍显式成员、隐式成员、先决条件和先决角色x

显式成员：

（u,x）∈UA

隐式成员:

若存在x’>x,（u,x’）∈UA,则U是x的隐式成员

先决条件:

是一个由x，xba，^,V组成的一个布尔表达式

若存在x’>=x,（u,x’）∈UA,则x为真

若存在x’>=x,（u,x’）UA,则xba为真

先决角色x:

在URA97模型中我们会介绍

角色按偏序关系≥组织，所以如果x≥y那么角色x继承角色y的权限。

x的成员也是y的隐式成员。

在这种情况下，我们说x大于y。

每个会话将一个用户和多个角色相连起来。

基本思想是：

用户建立一个会话，激活该用户所在角色中（直接或间接地通过角色层次）的某个子集。

对RBAC的其它组件施加约束是RBAC96的一个重要方面。

有人认为约束是RBAC主要推动。

互斥的角色，如：

购买管理者和付款管理者，就是一个常见的例子。

在大多数组织中（除了很小的）同一个人不允许是两个角色中的成员，因为这可能会导致工作腐败。

这是著名的且历史悠久的责任分离原则。

约束是实施高层组织策略的一个强有力的机制。

一旦一定的角色被定义为相互排斥的后，就不必过多的关心个别用户到角色的指派，后者的活动就可代理并分散化，而不必担心破坏系统整个安全目标。

只要RBAC的管理完全集中在一个单独的安全管理员下，约束就是一个有用的方便；然而通过安全管理员细致工作也可最大程度地获得同样的效果。

但是，如果RBAC的管理被分散化（后面将讨论），约束将成为一个机制。

通过它，高级安全管理员能够约束使用管理特权的用户的能力。

这使得首席安全管理员可以制定可接受的宽广范围的约束，并将它作为强制性的要求施加给其余安全管理员和用户。

在RBAC97中假定约束在实施管理中将被实行。

在ARBAC97中特别定义的约束是另外定义的其他约束。

值得强调的RBAC96将角色和权限与管理角色和权限区分开，并使用后者来管理前者。

如何管理管理权限和角色呢？

可用管理角色和权限的第二层来管理第一层，如此等等。

我们认为这样的管理过程是不必要的。

对管理角色和权限的管理由首席安全管理员的直接控制或者部分代理给管理角色。

在本文中我们采取前一种策略。

RBAC96有许多组件。

RBAC的管理包括对这些组件的控制即创建、删除角色，创建、删除权限，指派权限给角色和将其回收，创建、删除用户，指派用户给角色和将其回收，角色层次的定义和维护，约束的定义和维护以及相应对管理角色和权限的所有这些控制。

一个全面的管理模型是相当复杂的并且很难一步形成。

ABRABC97采取逐步策略，通过用户－角色指派、权限－角色指派和角色－角色指派来开发不同的模型。

3用户－角色指派的URA97模型

在这一节我们开发URA97模型来管理用户－角色的指派。

分两步定义URA97：

授予一个用户的角色成员资格，回收用户的成员资格。

尽管很简单，但是URA97十分强大，而且大大超过了现存的用户－角色指派的管理模型。

它也可超出RBAC应用于对用户群指派。

在最简单的情况下，用户－角色指派可以完全集中于一单一首席安全管理员角色，这在现存的系统中已经较好地实现，但是这个简单的策略和大系统不匹配。

很显然，希望将用户－角色指派分散到某种程度。

在一些系统中，指派一个角色为低级安全管理员（JSO）是可能的，JSO的成员对一个或多个一般的角色如A、B、C具有管理控制权。

这样将有限的管理权指派给JSO的角色，不幸的是这些系统通常允许JSO角色对角色A、B、C进行完全的控制。

JSO的A不仅可以把用户指派给A、B、C，而且可以从这些角色中删除用户，增加删除权限，而且，通过JSO的成员，将用户加到A、B、C没有控制。

最后，JSO成员可指派A、B、C为现存角色层次中任意低级角色（只要不引起循环）。

这和经典的自主思想相一致。

由此JSO的成员有效地设计为A、B、C角色的主人，因而可对这些角色进行想要的任何操作。

在URA97中，我们的目的是对那些通过哪些管理角色的指派可以加到一个角色中的用户施加限制，并清楚地将对添加和删除用户能力与对角色的其他操作区分出来。

先决条件这个概念是URA97的关键部分。

定义1，先决条件是一个由x、

、∧、∨操作组成的一个布尔表达式，x是一个常规角色（如x∈R），先决条件由用户u来核定，如果（

x´≥x），（u，x´）∈UA,则x为真；如果（x´≥x）,（u，x´）

UA，则　

为真。

对于给定的角色Ｒ的集合，用CR表示所有可能的在Ｒ中使用角色形成的先决条件的集合。

在小事件中，先决条件会成为同义语反复，先决条件的最简单的小事件是在一个单角色中成员的一个测试，在这里单一角色成为一个先决角色。

URA97授权模型

在URA97中用户－角色的指派是通过下面的关系来授权的

定义２，URA97模型通过关系can_assign

AR×CR×2R　来控制用户－角色的指派。

Can_assign（x,y,{a,b,c}）的意思是管理角色x的成员（或级别高于x的管理角色的成员）能够指派一个用户（此用户在常规角色中的当前成员或者非成员）满足先决条件y时成为常规角色a,b或c的一个成员。

为了分析can_assign关系背后的动机，我们来分析图2（a）中的角色层次和图2（b）中的管理角色层次。

图2（a）给出了在一个工程部门中的一般角色，有一个最低级的角色E，在这个组织中所有的职员属于E，在工程部门中有一个次低级的角色ED和最高级的角色DIR，在这之间是部门内两个工程的角色，左边是工程１，右边是工程２，每个工程有一个高级的工程领导角色（PL1和PL2）和一个低级的角色（E1和E2），两者之间，每个工程有两个不可比较的角色，生产工程师（PE1和PE2）和质量工程师（QE1和QE2）。

图2（a）符合我们的目的，当然在工程内部这个结构可以扩展成几十个甚至上百个项目，而且，每个项目依据各自的角色可以有不同的结构，此图也可以扩展成每个部门具有不同结构和管理策略的多部门结构。

而且在本图中不一定需要最高级的如D1R的角色。

相似的，不需要最低级的角色。

图2（b）描述与图2（a）相匹配的管理角色层次，最高级的角色是高级安全官员SSO，我们对比SSO更低级的管理角色感兴趣，这些角色组成了两个工程安全官员角色（PSO1和PSO2）和一个部门安全官员角色（DSO），他们的关系如图所示。

为了阐述，我们定义can_assign关系，如表１的角色列集所示，此例中的每个元组都有用于测试单个角色成员的最简单先决条件，称为先决角色。

角色PSO1对工程１的角色有部分责任，假定Alice是PSO1的一个成员，Bob是ED的一个成员，Alice可以给Bob分配E1、PE1、QE1任一角色，但不可以分配角色PL1，同样，如果charlie不是ED的成员，那么Alice不能给charlie分配工程１的任一角色。

所以如果用户已经是ED的成员，则Alice可使这个用户成为E1、PE1、QE1角色成员。

注意到如果Ａlice将PE1角色分给Bob，就不必明确的将Ｅ１分给Bob1，因为E1的权限通过角色层次关系被PE1继承。

就工程２而言，PSO2和PSO1相似。

角色DSO继承了PSO1和PSO2的权力，但可以进一步将ED的成员用户加给PL1和PL2。

SSO既能够将Ｅ中的用户加给ED，也能够将E