RBAC

Role-Based Access Control Models

参考论文：论文地址
本文是经阅读上述论文后所作的概述总结

概述

RBAC(role-based access control)是基于角色系统的，角色由用户扮演，并且每一角色对应着相应的权力，这是区别于用户组(user groups)的，因为用户组只是被定义为由一些用户所组成，不对应着相应的权力。

简单介绍

RBAC的概念随着多用户和多应用在线系统的发展而提出，它的中心思想就是权力与角色对应，而用户又将会被分配为适当的角色。
在组织中根据不同的工作职能分为不同的角色，而基于用户的责任和条件将角色赋予其身上。用户可以实现角色间的转换，而角色也会根据不同情况被给予或被收回权力。
角色通常比较稳定，而用户和权力之间由角色所关联产生的联系是短暂的。
RBAC在各个方面都有其应用价值。

背景

RBAC的主要目的是为了减轻安全管理和检查的压力。在过去和现在，应用是基于内编码的RBAC构建的。所存在的操作系统和环境是很少提供RBAC应用级别使用上的支持。其挑战在于识别独立于应用程序的极其灵活的工具，但实现和使用起来简单，最小化的定制来支持广泛的应用程序。
RBAC的复杂变化希望能够很好地建立角色间的联系、角色与权力间的联系、用户与角色间的联系。角色间的联系可以被用来执行安全策略，包括职责的分配和授权。这些关系必须被编码进应用软件，使用RBAC，可以为每一个安全域指定它们一次。

• 安全域：是指网络中具有相同的安全保护需求并相互信任的区域或网络实体的集合。

可以事先定义好角色与权力之间的关系，这样更便于为用户分配事先定义好的角色。研究发现，给用户分配和收回现有角色要比创造新角色或改变角色-权力间的分配关系更可取。分配角色给用户要比分配权力给角色技术含量低。当然，在没有RBAC时，也是困难的。
RBAC支持了三个著名的安全原则：

• 最小特权原则，只有该角色完成任务所需的权力被赋予该角色
• 职责分离原则，确保互斥角色（一个用户不能分配到两个相互制约的角色）来完成一项敏感任务，例如签发支票时，必须有客户经理和会计人员的参与
• 数据抽象原则，权力是抽象的不那么直接，例如对于账户的贷记和借记，而不是读写执行权力

虽然支持了，但在具体实现中也会违背。

RBAC对于所有的访问控制也不是万能的，有些复杂的可能需要基于RBAC来进一步构造。

角色和相关概念

就像概述中所说的角色由用户扮演，并且每一角色对应着相应的权力，这是区别于用户组(user groups)的，因为用户组只是被定义为由一些用户所组成，不对应着相应的权力。
在Unix操作系统中，组和成员是被定义在两个文件，/etc/passwd和/etc/group中的，而权力是和单独的文件和目录捆绑在一起的，也就是说相当于每个文件都有个权限表，表里记录着哪个用户组有哪些权力。这样要知道一个组里有哪些权力就需要遍历整个文件系统。另外，权力的分配是高度分散的，Unix文件系统的一个子树的管理员可以分发该子树的权力给用户组。
由前述讨论可知，角色应该具有两个特征：

• 比较容易确定角色的关系和角色所拥有的权力
• 控制角色关系和角色所拥有的权力的能力应该集中于少部分用户手里

角色和隔层(compartments)之间的关系：隔层是被用于机密国防和政府部门的安全结构的一部分。与角色的语义内涵类似，在隔层下的信息具有语义内涵。然而，隔层往往用于单向信息流，角色并不假定这种特殊的策略。

可自由支配的访问控制(DAC)和强制型的访问控制(MAC)之间存在着不同。

• 自主访问控制依据主体的判断力授予访问权限，客体的拥有者对客体进行管理，可以按自己的意愿有选择地与其他用户共享文件

• 强制访问控制完全取决于权限，而权限由管理员设置或操作系统自动按照相关严格策略进行设置，用户所创建的资源，用户也不能完全控制。而RBAC是独立与其两者共存的。

一组参考模型

为了理解RBAC的不同维度，作者定义了一组的四个概念模型，四个概念模型的关系如下：

RBAC0是基础模型，它是对于支持RBAC的任何系统的最低要求，RBAC1和RBAC2是在RBAC0的基础上添加了一些独立特性，也被称为高级模型。
这些模型的重要特征如下图所示：

RBAC1添加了角色层次结构的概念

• 角色层次：角色可以从其他角色继承权力

RBAC2增加了约束，对RBAC不同部分的可接受配置施加了限制
RBAC3合并了RBAC1和RBAC2

现在详细来看每一个模型，假设只有一个安全管理员来确定模型的各种集合和关系

基础模型-RBAC0

模型中有三个实体，分别被称为用户(U)、角色(R)和权力(P)，图中也有会话集合(S)

• 用户，简化看成一个用户是一个人，当然也可以被泛化为有智力的自动的代理者（例如机器人，甚至电脑网络）
• 角色，是组织内的职务，与授予角色成员权力和责任有关
• 权力，是访问系统中某一或多个对象特定模式的批准，是权力拥有者可以在系统中执行某些操作的象征

在本篇文章中，否定权限被建模为约束
因为权力往往取决于系统的细节，所以在模型中在某些程度上被视为未解释的。每个系统都保护其中抽象的对象，例如OS中通过读写执行来保护文件、设备、端口等。

像图2中所示，user assignment（UA）和permission assignment（PA）都是多对多的关系

• 一个用户可以有多个角色，一个角色可以对应多个用户
• 一个角色可以有很多权力，同一个权力可以被分配给多个角色

RBAC的关键就在于这两个关系上，最终也就是一个用户可以拥有权力，相比于直接给用户分配权力，添加角色作为中介可以更好地控制访问和检查。
每一个会话是一个用户到可能的多个角色的映射，每个会话和一个用户相关联，当用户建立了一个会话时，多个角色通过该会话与用户关联，此时用户可用的权限是对应的多个角色上所拥有的权力的并集。在整个会话期间，这种关联不变。但一个用户在同一时间可以有多个会话，例如在屏幕上的不同窗口里，然后会话间所持有的角色集合不同。这种特征支持了最小特权原则。

注意：这里所说的用户所建立的会话中的角色都是之前那个安全管理员给该用户分配好的角色的子集，用户来决定在分配好的角色中激活和停用哪些角色

• 拥有多个角色的用户，在其中一个会话中可以调用角色集中的子角色来完成对应的任务，用户在需要时显式激活对应角色。

在RBAC0中，在给定会话中激活哪些角色完全取决于用户，在RBAC2中会进一步限制。RBAC0也允许在一个会话期间动态激活和禁用角色。
在文章中，形式化地描述了上述关系：

在RBAC0中，权力仅仅被应用于数据和资源的操作，而不用于U、R、P、UA和PA的操作，因为之前假设了只能有一个安全管理员来确定模型的各种集合和关系，但会话是在单个用户的控制下，包括建立会话（激活和停用角色）和关闭会话。

角色层次-RBAC1

RBAC1中引入了角色层次(RH)，角色层次是在构建角色来反映组织的权力和角色的一种常用的方法。角色层次的例子如下图所示：

初级角色处在底部，高级角色处在顶部，如(a)图所示，Physician要比Health-care Provider高级，并且P继承了H的所有权限，除此之外P还有其他权限。继承是可传递的，在(a)中primary-care physician继承了Physician和H的权限，并且还有其他权限。
RBAC1的定义如下：


此时用户所建立的会话中可选的角色集中包含了比分配给他的角色级别低的角色集
某些情况下限制继承也是合理的，例如低级的角色所对应的工作未完成，此时让高级的角色没有权限访问也是合理的，可以定义一个全新的角色来实现这种目的，例如(b)与(c)的区别，这种新加的角色称为私人角色，因为一些私人权力被赋予了。在某些系统下，另一种实现方式是，控制继承权力来实现，即某部分不让高级的继承，这与私人角色也是不同的，因为私人角色的所获得的私人权力是被赋予的，没有干涉继承过程。

约束-RBSA2

约束时RBAC的一个重要部分，一个常见的例子是相互分离的角色，例如采购主管与账务主管。这两个角色不能由同一人来担任（角色互斥），这就体现了职责分离的原则。
约束可以被应用在UA、PA和会话中的用户与角色的关系，约束可以给出这些关系是否是可接受的，约束的形式化定义如下：

最常提及的约束是互斥角色，在互斥角色集中，用户最多只能扮演其中的一个角色。当然互斥角色是对于UA来说的，对于PA来说，相同的权力不能给多个角色（以采购主管与账务主管在开支票这个权限上，通常来说只有账务主管有这个权力）

另一个UA方面的约束是一个角色最多只能赋予给多少人，例如一个部门只能有一个领导，另外一个用户可以扮演的角色的数量也是可以限制的。这些被称为基数约束。同样PA方面，一项权限可以被给予给多少个角色也是存在基数约束的。相反限定最小值往往比较难以实现。

另外还有一种约束称为先决角色，比如当一个用户要扮演角色A，他首先必须拥有角色B，角色B一般要比角色A低级。当然在PA方面也是成立的，比如一项权限要赋予给角色A，那么角色A首先得拥有另一项权限。

在用户标识和人之间必须是一对一的，UA约束才有效。同样，相同的操作不能由两个不同的权限批准执行。

约束也可以应用于会话，比如，在一个会话中，用户不能同时激活两个角色，还可以约束用户可以同时拥有的会话数量，一项权限被用于几个会话的数量也是可以约束的。

由上可知，角色层次也可以被看作为一种约束。这个约束就是一项权利被赋予给了一个低级角色，那么必须被赋予给其对应的高级角色。也可以说，一个用户被赋予了高级角色，那么他必须被赋予其相对的所有的低级角色。

合并模型

RBAC3是RBAC1和RBAC2的结合，既提供角色层次，也提供约束。在RBAC2中也讨论了其实角色层次也可以看作是一种约束。只不过在角色层次的基础上可以再添加其他约束。这种结合可能会产生一些需考虑的情况，如下图：

假设test engineer和programmer是互斥角色，那么project supervisor就违反了这种约束。在某些情况下，由更高级的角色来违反是可以接受的，但是有些情况是不行的。

不过可以通过引入私人角色来解决，如下图所示：

此时可以让test engineer’,programmer’和project supervisor是互斥的，因为他们没有公共的更高级的角色

管理模型

上述讨论的模型都是基于单个安全管理员，在大型系统中，往往需要一个小型的安全管理团队。
在这时很自然地会提出一个问题，RBAC如何管理自己？
作者提出的一种模型如下所示：

在此模型中，约束应用于RBAC中的任一部分，上半部分与我们之前所见的类似，增加了下半部分，用于对管理角色(AR)和管理权力(AP)的说明，普通权限只能给普通角色，而管理权限只能给管理角色，这是个内在约束。
作者认为在管理管理层次时，只需要一个主要的安全管理员就够了，不需要第二个管理层次来管理第一个。
管理者的权力包括：

• 修改UA
• 修改PA
• 修改角色层次关系

在一个管理模型中，授予这些管理操作的权限必须被显式定义。
在管理模型中，有一个很重要的问题就是如何界定管理者的权限范围？以下图为例：

(a)是普通角色层次，(b)是管理角色层次，CSO就是首席安全管理员，所谓的管理权限界定问题就是(a)中的普通角色应该被(b)中的谁管理。
我们可以说CSO可以管理(a)中所有的角色，假定SO1可以管理T1，但是我们不想让SO1可以继承似地来管理P，所以我们就界定SO1的管理范围为T1。另外界定范围还可以细分至权限和用户，比如SO1只能往角色T1中添加用户，但是删除只能由CSO进行。