本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 访问控制的类型
<a name="access-control-types"></a>

您可以使用两个广泛定义的模型来实现访问控制：基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC)。每种型号都有优缺点，本节将简要讨论这些优缺点。您应该使用的模型取决于您的具体用例。本指南中讨论的架构支持这两种模型。

## RBAC
<a name="rbac"></a>

基于角色的访问控制 (RBAC) 根据通常符合业务逻辑的角色来确定对资源的访问权限。权限会根据需要与角色相关联。例如，*营销*角色将授权用户在受限系统内执行*营销*活动。这是一个相对简单的访问控制模型，因为它与易于识别的业务逻辑非常吻合。 

在以下情况下，RBAC 模型的效果会降低： 
+ 您有独特的用户，其职责包括多个角色。 
+ 您的业务逻辑很复杂，因此很难定义角色。 
+ 要向上扩展到较大的规模，需要持续管理权限并将权限映射到新角色和现有角色。 
+ 授权基于动态参数。

## ABAC
<a name="abac"></a>

基于属性的访问控制 (ABAC) 根据属性确定对资源的访问权限。属性可以与用户、资源、环境甚至应用程序状态相关联。您的策略或规则引用属性，并且可以使用基本的布尔逻辑来确定是否允许用户执行操作。以下是权限的基本示例： 

*在支付系统中，财务部门的所有用户都可以在工作`/payments`时间通过 API 端点处理付款。*

财务部门的成员资格是一种决定访问权限的用户属性`/payments`。还有一个与 `/payments` API 端点关联的资源属性，仅允许在工作时间内进行访问。在ABAC中，用户能否处理付款由一项策略决定，该策略将财务部门成员资格作为用户属性，将时间作为资源属性。`/payments`

ABAC 模型在允许动态、上下文和精细的授权决策方面非常灵活。但是，ABAC模型最初很难实现。定义规则和策略以及列举所有相关访问向量的属性需要大量的前期投资才能实施。

## RBAC-ABAC 混合方法
<a name="hybrid"></a>

将 RBAC 和 ABAC 结合使用可以提供这两种模型的一些优势。RBAC 与业务逻辑非常接近，实施起来比 ABAC 更简单。为了在做出授权决策时提供额外的精细度，您可以将 ABAC 与 RBAC 结合使用。这种混合方法通过将用户的角色（及其分配的权限）与其他属性相结合来做出访问决定，从而确定访问权限。使用这两种模型可以简化权限的管理和分配，同时还可以提高与授权决策相关的灵活性和精细度。

## 访问控制模型比较
<a name="comparison"></a>

下表对前面讨论的三种访问控制模型进行了比较。这种比较旨在提供信息丰富且内容丰富。在特定情况下使用访问模型不一定与本表中的比较相关。


|  |  |  |  | 
| --- |--- |--- |--- |
| **因子** | **RBAC** | **ABAC** | **混合** | 
| **弹性** | 中  | 高 | 高 | 
| **简单** | 高 | 低 | 中 | 
| **粒度** | 低 | 高 | 中 | 
| **动态决策和规则** | 否 | 是 | 是 | 
| **情境感知** | 否 | 是 | 有点像 | 
| **实施工作** | 低 | 高 | 中 |