权限管理技术小结

基础技术简介

对于计算机系统的访问控制，一般有以下几种访问机制和类型：

1. 自主访问控制（DAC: Discretionary Access Control）

自主访问控制 Wikipedia
根据主体（如用户、进程或 I/O 设备等）的身份和所属组来限制对客体的访问。所谓的自主，是因为拥有访问权限的主体，可以直接（或间接）地将访问权限赋予其他主体（除非受到强制访问控制的限制）

自主访问控制可以让用户或管理员自主定义资源（如数据库、操作系统文件等）的访问权限，其中访问权限通常由 ACL（Access Control List）访问控制列表来定义。DAC 的一个典型例子为 Windows 的文件权限管理，用户可定义某一个文件的访问控制列表如下：

Windows_DAC.png

同时自主访问控制允许拥有客体权限的用户将权限分配给其它用户，这也是 自主 的主要含义。

但由于能够自主传递权限，在传递的过程中，可能导致用户间接获得本不该具有的权限，因此自主访问控制也是一种比较宽松的访问控制。

2. 强制访问控制（MAC: Mandatory Access Control）

强制访问控制 Wikipedia
主体和对象各自具有一组安全属性。每当主体尝试访问对象时，都会由操作系统内核强制施行授权规则——检查安全属性并决定是否可进行访问。通过强制访问控制，安全策略由安全策略管理员集中控制；用户无权覆盖策略，例如不能给被否决而受到限制的文件授予访问权限。

在历史上，MAC 强制访问控制经常用在专业的军用系统中，因此 MAC 有着高度严格的权限约束。MAC 强制访问控制只可由系统定义权限规则且由系统强制执行，用户与他们的进程不可修改权限规则。

MAC 强制访问控制的实现有 Linux 的 SELinux 和 AppArmor。

MAC 的权限控制严格，但同时灵活性不高，对于一般的互联网软件的适用度不高。

3. 基于属性的访问控制（ABAC: Attribute-Based Access Control）

Attribute-based access control Wikipedia
ABAC 也被称为 PBAC（Policy-Based Access Control），其定义了访问控制范例，通过使用属性组合的策略来向用户授予访问权限。

我们知道现实中存在着各种实体，不同实体可通过不同的实体特性进行区分，这些实体特性并称为属性。

在一个权限系统中，可能会涉及到主体、客体、权限、环境等概念，而这些概念实际上均可视为实体，更为重要的是可以通过属性来描述表达这些实体。即：使用属性统一描述和表达权限控制所涉及到的各类实体（其中包括访问策略也同样使用属性表达）。

ABAC 被视为权限控制的未来，与下文即将介绍的 RBAC 基于角色的访问控制相比，ABAC 拥有更为灵活与更为强大的权限控制能力。

尤其是在分布式的开放环境中，系统可能分布在不同的安全域之内，相互之间只能知晓彼此的部分信息。此时基于角色的权限控制将会存在极大的局限性：不同系统之间角色模型不可能完全重合，建立关联又将极其复杂。

但如果是以属性为粒度，那么系统之间则完全不需要了解彼此的“调用方”，权限判断完全基于“属性”。这使得 ABAC 具有足够的灵活性和可扩展性，提高了系统之间的可交互性和安全性。

因此 ABAC 在分布式开发环境下，具有传统访问控制不具有的细粒度控制能力和大规模主体动态授权能力，同时拥有极强的灵活性和可扩展性。但基于属性进行实体描述、策略表达、权限判断等需要较为复杂的模型设计与工程实现，固目前并没有在工程上得到广泛应用（如 Kubernetes 曾使用 ABAC，但由于实现的复杂且难以理解，之后转而使用 RBAC）。而 RBAC 依然是目前应用最为广泛和普遍的权限控制（RBAC 其实也只是 ABAC 的一种特例，角色 ID 可视为一个属性）。

4. 基于角色的访问控制（RBAC: Role-Based Access Control)
基于角色的访问控制是较为灵活也较为容易理解的一种访问控制策略，其通过权限赋予角色，角色赋予用户的方式将角色与用户解耦，从而用户与权限的灵活关联。

基于角色的访问控制是目前应用最为广泛的权限控制策略，固下文将单独详细的介绍该策略。

RBAC 访问控制

RBAC 基于角色的访问控制主要涉及到三种实体：

• 权限：对资源的访问权限，比如对某文件的读、更新等权限。在一些系统实现中，喜欢将其划分为页面权限、操作权限、数据权限等类型。但想到标签包含了分类，所以实际上是否可以不划分为页面权限、操作权限、数据权限。而只是在资源上打上页面、操作、数据等标签？
• 角色：权限的集合
• 用户：可被授予不同的角色

其中用户可以有 ”组“ 的概念，将用户分配到某个用户组，即可拥有该用户组下的权限，从而省去每个权限单独授予的步骤。

同时权限也可有 “组” 的概念，可以将一些使用场景相对固定的一组功能或权限封装成组。将其赋予某个角色，该角色将拥有该组下的所有权限。但是一般而言系统的权限是可控，所以实际情况中较少使用权限组。

RBAC 的实现模型

RBAC 在不同场景下会有一定的不同扩展，因此衍生出了几种不同的实现模型：

1. RBAC0
最基础、最原始的 RBAC 实现模型，同时也是下文中其它实现模型的基础。

RBAC0 模型如下图所示：

RBAC0.png

其中用户与角色，角色与权限为多对多的关系，用户可拥有不同角色，角色可包含不同权限。

RBAC0 包含了 RBAC 最基本的要素，通过角色实现了用户与权限的解耦，但除此之外也没有其它多余的关系或约束。

2. RBAC1
在许多业务场景中，角色之间是具有上下级或继承的关系的。例如在一家中大型企业里，通常有员工、组长、部门总经理等角色，且角色之间存在着上下级关系。

RBAC1 在 RBAC0 的基础上引入了角色的继承关系，能够使的角色之间层次更加分明，实现角色的分层分组。

RBAC1 模型如下图所示：

RBAC1.png

3. RBAC2
角色之间除了简单的继承关系，有时还存在一些约束关系。例如某些角色不能同时存在或拥有，即角色之间是互斥的。

RBAC2 在 RBAC0 的基础上引入了对角色的约束和限制。这些限制可大体分为两类：

• 静态职责分离 SSD
  • 互斥角色：不能同时拥有互斥角色
  • 基数约束：用户拥有的角色数有一定限制，即一个用户的角色数量是有限的。
  • 先决条件角色：想要拥有某个角色，需要事先拥有另一个先决角色（通常是低一级的角色）
• 动态职责分离 DSD
  • 运行时互斥，静态时可以有两种角色，但运行时不能同时激活运行时互斥角色。

RBAC2 模型如下图所示：

RBAC2.png

4. RBAC3

即 RBAC1 与 RBAC2 的合集，在对角色进行分层的同时，也对角色增加各种约束和限制。

RBAC3 模型如下图所示：

RBAC3.png

参考资料

有赞权限系统(SAM)
自主访问控制 Wikipedia
强制访问控制 Wikipedia
Trusted Extensions 提供自主访问控制和强制访问控制
ABAC Wikipedia
基于属性的访问控制研究进展 王小明，付红，张立臣 - 电子学报
基于属性的访问控制模型 李晓峰，冯登国，陈朝武，房子河 - 通信学报, 2008
Ravi S. Sandhu... “Role-basedaccess control models,” IEEE Computer, 29(2):38-47, February 1996.
What is the difference between RBAC and DAC/ACL?

汪

汪