RBAC 和 ABAC：你应该了解的访问控制模型

介绍#

访问控制 是任何系统安全的关键方面。它确保只有授权用户才能访问资源并执行操作。基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC) 是现代系统中使用的两种最受欢迎的访问控制模型。两种模型都被广泛采用，并可用于有效地实施访问控制策略。那么它们是什么以及它们有何不同？

基于角色的访问控制 (RBAC)#

基于角色的访问控制 (RBAC) 首次于 1990 年代初期被引入。该模型的形式化归功于 David Ferraiolo 和 Rick Kuhn，他们在 1992 年发表的一篇论文中记录了该模型。从那时起，RBAC 成为行业中最广泛使用的访问控制模型之一。

在 RBAC 中，访问控制策略基于角色，即权限的集合。用户被分配角色（例如管理员、编辑者、查看者），他们的访问权由特定资源（例如文件、数据库、应用程序）的权限（例如创建、编辑、删除）决定。通过基于角色对用户进行分组并将权限分配给角色，它简化了访问控制策略的管理。将用户添加或移除角色非常简单，更改会自动反映在访问控制策略中。

RBAC 的关键组件#

• 资源：资源是用户可以访问的实体。资源可以是需要保护的文件、数据库、API 或任何其他系统实体。
• 权限：权限是用户可以在资源上执行的特定操作。例如，创建、编辑、删除、查看。权限的定义可能因系统而异。在大多数情况下，权限是在具有最小粒度的资源级别定义的。
• 角色：角色是定义用户可以执行的一组操作的权限集合。例如，管理员角色可能具有创建、编辑和删除资源的权限，而查看者角色则可能有查看资源的权限。
• 用户：用户是可以被分配一个或多个角色的实体。用户根据他们被分配的角色相关联的权限被授予资源访问权。

RBAC 的变体#

有几个 RBAC 的变体扩展了基本模型以适应更复杂的访问控制需求：

• RBAC0：基本模型，其中用户被分配角色，角色被分配权限。
• RBAC1：增加了角色层次的概念。角色可以从其他角色继承权限。也称为分层 RBAC。
• RBAC2：为角色添加了约束。约束可以用来定义用户被分配角色时必须满足的附加条件。也称为基于约束的 RBAC。
• RBAC3：结合了 RBAC1 和 RBAC2 的特性。它支持角色层次和约束。

有关这些变体的更多信息，请参阅 RBAC 模型及其演变。

RBAC 的优点#

• 简单性：RBAC 易于理解和实现。分配权限给角色和用户非常直接。
• 高效性：通过基于角色对用户进行分组，RBAC 简化了访问控制策略的管理。添加或删除角色用户很容易，而不需要更改访问控制策略。特别是在具有明确权限结构的大型组织中，RBAC 可以非常高效。
• 透明性：RBAC 提供了角色、权限和用户之间的明确信映。审核和检查访问控制策略很容易。

RBAC 的缺点#

• 僵化性：在定义复杂的访问控制策略时，RBAC 可能显得僵化。它可能不适合需要更加动态和上下文感知的访问控制策略的系统。
• 粒度：RBAC 可能缺乏所需的细粒度访问控制。访问控制策略与明确定义的角色绑定在一起，可能需要额外的努力来在更细的粒度上定义权限。
• 角色爆炸：在具有复杂权限结构的大型组织中，角色数量可能会呈指数增长，导致角色爆炸。管理大量角色可能具有挑战性。

基于属性的访问控制 (ABAC)#

2000 年代后期，随着系统变得更加复杂和动态，越来越多的组织开始采用 基于属性的访问控制 (ABAC) 作为 RBAC 的替代方案。ABAC 形式化的一个重要里程碑是 2014 年 NIST 特别出版物 800-162 的发布。

ABAC 是一种比 RBAC 更灵活的访问控制模型。它是一种授权模型，它基于用户、资源、动作和环境的属性定义访问控制策略。它允许组织定义可以适应不同上下文和条件的细粒度访问控制策略。

ABAC 的关键组件#

• 主体：主体是请求访问资源的实体。它可以是用户、设备、应用程序或任何需要访问资源的实体。
• 资源：就像在 RBAC 中，资源是主体可以访问的实体。资源可以是文件、数据库、API 或任何其他系统实体。
• 动作：动作是主体可以在资源上执行的特定操作。它可以是创建、读取、更新、删除或任何其他需要控制的操作。
• 环境：环境是做出访问请求的上下文。它可以包含时间、地点、网络、设备等属性。
• 属性：属性是主体、资源、动作或环境的特性。属性可以是用户角色、部门、位置、IP 地址、设备类型等。
• 策略：策略是定义授予或拒绝访问的条件的规则。策略基于属性定义。

ABAC 的优点#

• 灵活性：ABAC 能够适应基于多个属性的复杂访问控制策略。它可以让组织定义可以适应不同上下文和条件的细粒度策略。
• 动态性：ABAC 策略可以是动态和上下文感知的。访问控制决策可以基于实时属性，例如位置、时间、设备类型等。
• 粒度：通过允许组织定义基于多种属性的策略，ABAC 提供细粒度访问控制。与定义角色和权限不同，基于属性的策略可以更细粒度。

ABAC 的缺点#

• 复杂性：与 RBAC 相比，ABAC 的实现和管理起来可能更复杂。定义属性和策略可能需要更多的努力和专业知识。与 RBAC 中角色和权限的结构良好不同，属性和策略可能更动态。在复杂系统中管理大量属性和策略可能具有挑战性。通常需要一个集中化的策略评估引擎来评估策略。
• 性能：属性评估可能会影响性能，特别是在实时环境中。基于多个属性和实时条件的策略可能会给访问控制决策引入延迟。

比较表#

从比较表中可以看出，RBAC 最适合权限结构明确且访问控制策略相对静态的系统。另一方面，ABAC 更适合需要动态、上下文感知和细粒度访问控制的系统。

示例#

场景：一个需要管理不同员工成员访问患者记录的医院系统。

• 员工：医生、护士、管理员
• 资源：患者记录
• 权限：读取、写入、删除

案例 1#

访问控制策略相对简单：

1. 医生可以读写患者记录。
2. 护士可以读取患者记录。
3. 管理员可以读取、写入和删除患者记录。

RBAC 模型#

在这种情况下，RBAC 简单而有效。我们可以为医生、护士和管理员定义角色，并为每个角色分配适当的权限。

访问控制评估很简单：

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC 模型#

在这种情况下，ABAC 可能显得大材小用，但它仍然可以用于根据诸如部门、角色等属性定义细粒度策略。

属性：

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

策略：

• 策略 1：根据 user.role 和 resource.name 允许读取访问
  • 主体：用户角色为 doctor, nurse, admin
  • 资源：资源名称为 patient-record
  • 操作：read
  • 效果：允许
  • 原因："允许所有角色访问患者记录"
• 策略 2：允许医生和管理员编辑访问
  • 主体：用户角色为 doctor, admin
  • 资源：资源名称为 patient-record
  • 操作：write
  • 效果：允许
  • 原因："允许医生和管理员修改患者记录"
• 策略 3：允许管理员删除访问
  • 主体：用户角色为 admin
  • 资源：资源名称为 patient-record
  • 操作：delete
  • 效果：允许
  • 原因："允许管理员删除患者记录"

对于每个读取/写入/删除请求，策略引擎根据属性评估所有相关策略并做出访问控制决策。

比较#

在这种情况下，访问控制策略简单且结构良好。只需要进行单级权限检查即可确定用户是否有权访问资源。假设医院系统有一个更复杂的结构，其中包含多个部门、角色和权限：

• 在 RBAC 模型中，患者记录资源的访问控制评估过程仍然简单而直接，无论用户是否具有 read, write, 或 delete 权限；
• 而在 ABAC 模型中，需要涉及其他属性，比如 department-id 和 doctor-id。如果一个物联网设备需要访问患者记录怎么办？它将需要在策略评估中引入一个新属性 device-id。如何临时授予实习医生 read 权限？

总之，RBAC 是更好的选择。RBAC 对于具有明确权限结构且访问控制策略静态的系统来说简单而高效。

案例 2#

同一家医院系统，现在让我们引入一个新角色 patient 和一个新属性 patient-id。

访问控制策略是：

1. 医生可以读写患者记录。
2. 护士可以读取患者记录。
3. 管理员可以读取、写入和删除患者记录。
4. 患者可以读取自己的记录。

RBAC 模型#

在这种情况下，除了旧的 读取 权限外，我们还需要引入一个新权限 读取自己的。我们可以为医生、护士、管理员和患者定义角色，并为每个角色分配适当的权限。

现在访问控制评估有点复杂了，特别是对于 读取 患者记录操作：

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC 模型#

现在让我们更新 ABAC 模型中的属性和策略以满足新需求。

属性：

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

策略：

• 策略 1：允许访问所有患者记录
  • 主体：用户角色为 doctor, nurse, admin
  • 资源：资源名称为 patient-record
  • 操作：read
  • 效果：允许
  • 原因："允许所有员工和患者本人访问患者记录"
• 策略 2：允许医生和管理员写入访问所有患者记录
  • 主体：用户角色为 doctor, admin
  • 资源：资源名称为 patient-record
  • 操作：write
  • 效果：允许
  • 原因："允许医生和管理员写入患者记录"
• 策略 3：允许管理员删除访问所有患者记录
  • 主体：用户角色为 admin
  • 资源：资源名称为 patient-record
  • 操作：delete
  • 效果：允许
  • 原因："允许管理员删除患者记录"
• 策略 4：允许读取自己患者记录
  • 主体：用户角色为 patient
  • 资源：资源名称为 patient-record
  • 操作：read
  • 条件：user.id === resource.patient-id
  • 效果：允许
  • 原因："允许读取自己患者记录"

比较#

在这种情况下，访问控制策略更复杂和上下文感知。患者记录资源的访问控制评估过程将需要多个级别的权限检查才能确定用户是否有权访问资源。

• 在 RBAC 模型中，患者记录资源的访问控制评估过程将需要多个级别的权限检查才能确定用户是否有权访问资源。例如，要确定患者是否有权访问自己的记录，系统需要检查用户是否具有 '读取自己的' 权限以及用户 ID 是否与患者 ID 匹配。
• 在 ABAC 模型中，访问控制评估过程可能更简单。策略可以根据用户、资源和操作的属性来定义。例如，要确定患者是否有权访问自己的记录，策略引擎可以根据用户 ID 和患者 ID 来评估策略。

在这种情况下，ABAC 可能更符合需要。ABAC 更适合需要动态、上下文感知和细粒度访问控制的系统。

结论#

选择 RBAC 和 ABAC 取决于系统的具体需求。RBAC 最适合权限结构明确且访问控制策略静态的系统。ABAC 更适合需要动态、上下文感知和细粒度访问控制的系统。在实践中，组织可能会选择结合使用两种模型以实现所需的访问控制水平。