跳转至

RBAC与ABAC权限控制

一、常见的三种权限管理类型

在任何公司，网络用户必须经过身份验证和授权，才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。ACL、RBAC 和 ABAC 是三种常见的权限管理模型，每种模型在不同的场景下都有适用性。选择哪种权限管理模型取决于具体需求和环境。

acl rbac abac

二、ACL(Access Control List：访问控制列表)

ACL介绍及应用场景

ACL 是最简单的权限管理模型之一。它基于对象与主体之间的关系来控制访问权限。ACL 将权限直接与用户或用户组相关联，管理员直接给用户授予某些权限即可。这种模型适用于小型和简单系统，其中权限控制较为简单，并且角色和权限的变化较少。

ACL 提供了一种通过将访问控制条目 (ACE) 与各个资源相关联来指定访问权限的基本机制。每个ACE 通常包括一个主体（用户或组）和一组确定主体对资源的操作的权限（例如，读、写、执行）。 ACL 通常在文件系统级别或网络设备上实现。

ACL 主要有两种类型：

  1. 文件系统 ACL管理对文件和目录的访问。它们为操作系统提供指令，指定用户对系统的访问权限及其在系统上的权限。
  2. 网络 ACL通过向网络交换机和路由器发出指令来控制网络访问，这些指令确定允许与网络接口的流量类型。这些 ACL 还建立了网络中的用户权限。网络管理员预先定义网络ACL限制。 

ACL 还可以根据其识别流量的方式进行划分：

  • 标准 ACL 阻止或允许整个协议套件使用源 IP 地址。
  • 扩展 ACL 根据一组更具差异性的功能（包括源和目标 IP 地址以及端口号）阻止或允许网络流量。

ACL 的优点

使用访问控制列表 (ACL) 具有多种优势，包括：

1. 简化用户识别：ACL 有助于用户识别，确保只有授权用户和流量才能访问系统。

2. 性能：与具有类似功能的替代技术相比，ACL 具有性能优势。它们直接配置在路由设备的转发硬件上，不会对设备性能产生负面影响。相反，其他检查防火墙作为单独的软件元素可能会导致性能下降。对网络流量的控制提高了整体网络效率。

3. 控制：ACL 使管理员能够对整个网络的用户和流量权限进行细粒度控制。它们对于管理网络端点的访问和调节内部网络之间的流量至关重要。这种控制级别对于实现改进的网络安全和运营管理至关重要。

ACL 的限制

另一方面，ACL 也有一些缺点。这里是其中的一些： 

1. 缺乏效率：ACL 在某些情况下可能会表现出效率低下，因为它们使用显式定义的访问控制。例如，如果用户由于同时具有 IT 部门和管理角色的成员身份而拥有特定的访问权限或权限，则必须指定此升级的访问级别，而不是从组成员身份自动推断。

2.可扩展性问题：这一限制与前一个限制有关。显式声明访问控制的必要性会对可伸缩性产生负面影响。随着用户、用户组和资源数量的增加，ACL 和定义授予特定用户的访问级别所需的时间也会增加。

3. 能见度模糊：ACL 附带多个自治列表，其中包含用户的权限和访问级别。因此，检查、更改或撤销访问权限需要检查业务环境中的每个 ACL 以应用新权限。

三、RBAC(Role-Based Access Control,基于角色的访问控制)

RBAC介绍及应用

RBAC 是应用最广泛的权限管理模型之一。它通过定义角色和角色的权限集合来管理访问控制。用户被分配到角色，角色与权限相关联，从而精确地控制用户对系统资源的访问。
RBAC 适用于大型系统，特别是那些需要灵活、可扩展的权限管理的场景。使用 RBAC 可以简化权限管理的复杂性并提高系统的安全性。

what is rbac

RBAC权限管理的模式，最适合公司内部的管理系统，不适合对外互联网用户的系统。

1
2
3
用户：用户表 
角色(部门)：角色表(部门表) 
权限：权限表

权限：是授予角色的(或者说部门，或者说组)，一个个角色，就是一条条记录(对应到公司就是开发部，hr部门，股东部)。

用户：一个个用户是用户表中一条条记录，用户属于某个部门，就具备了部门下的权限。

三张表之间的关系：

  • 用户和角色关系：多对多，中间表
  • 角色和权限关系：多对多，中间表

那么就一共有了5张表：

  1. 用户表
  2. 角色表
  3. 权限表
  4. 用户和角色关联表
  5. 角色和权限关联表

对于普通授权，都是建立用户和对象之间的关系，比如：

1
2
3
用户A -> 能读取 -> 文件a
用户B -> 能写入 -> 文件a
用户A -> 能删除 -> 文件b

这样的控制能做到很细的粒度，但是有一个缺点，那就是难于控制。举个例子，对于企业内部系统，假设普通员工们都可以访问100个 子系统接口，对于一个新来的员工，我们就需要给他重新配置这100个子系统接口的权限。但是有了RBAC之后就不一样了，我们通过 引入role这一个中间层，所有的授权关系，我们都是建立在 role 和 对象之间，例如：

1
2
3
角色A -> 能读取 -> 文件a
角色B -> 能写入 -> 文件a
角色A -> 能删除 -> 文件b

然后我们再建立用户和角色之间的关系。这样，对于一个新来的员工，我们只需要把他和对应的角色关联起来，他就自动拥有了该角色 所有的权限。

但是RBAC的缺点在于，赋予权限之后，无法将权限的粒度限制到更小，例如，我们允许用户A "删除集群"，但是RBAC上，我们无法表述出 "删除1号集群" 的操作，也就是说，RBAC无法做到缩小权限。

RBAC的优点

基于角色的访问控制具有明显的优势，包括： 

1. 简化管理：RBAC 通过基于角色组织权限来简化访问控制的管理。这使得添加或删除用户以及分配或取消权限变得更加容易。通过 RBAC，企业可以在整个组织中传播一致的访问策略。 

2. 可扩展性和灵活性：RBAC 具有很强的可扩展性，适合不同规模的组织。随着组织的发展，可以添加新角色，而不会严重增加管理工作量。责任级别、职责分离和其他规则可以合并到角色和权限定义中。

3、维护方便：RBAC 允许组织自动执行权限分配并减少管理负担。管理员可以通过简单的界面快速有效地添加新用户。对角色或权限的任何更改都会自动应用于具有这些角色的所有用户。

4. 策略管理：RBAC 有助于集中策略管理。安全策略与角色相关联，对策略的更改可以统一应用于特定角色内的所有用户。

5. 增强安全性和合规性：RBAC 通过确保用户仅拥有其角色所需的权限来提高安全性。这最大限度地降低了未经授权访问的风险并减少了攻击面。此类系统通常提供全面的审计跟踪，使组织能够跟踪用户活动和访问权限的变化。这有利于合规性目的。

RBAC 的局限性

尽管 RBAC 有许多优点，但也有一些限制需要考虑： 

1. 实现复杂：实施 RBAC 可能很复杂，尤其是在具有不同角色和职责的大型组织中。由于耗时，可能需要对组织结构和流程进行彻底分析。

2、角色数量过多：在某些情况下，角色的数量可能会变得过多，从而导致"角色爆炸"的现象。当需要大量角色来充分满足不同用户所需的不同权限集时，就会发生这种情况。

3. 动态环境：在用户角色和职责频繁变化的动态环境中，RBAC 可能面临挑战。使 RBAC 模型适应快速变化的组织结构可能具有挑战性。

4. 角色冲突：在某些情况下，用户被分配了两个具有冲突信息的角色。在我们的例子中，如果用户被分配了admin 角色和regular-user 角色， 他们有edit:self和edit:all权限编辑 博客帖子。应该采取哪一个优先级？这优先级 逻辑可以在 API 中编码，但这会打开可能性对于错误。

四、ABAC(Attribute-Based Access Control,基于属性的访问控制)

ABAC介绍及应用

ABAC(Attribute-Based Access Control,基于属性的访问控制),又称为PBAC(Policy-Based Access Control,基于策略的访问控制),或CBAC(Claims-Based Access Control,基于声明的访问控制)。ABAC 是一种基于属性的权限管理模型，它根据多个属性（如用户属性、环境条件、时间等）来进行访问控制决策。ABAC 通过定义策略来决定用户是否有权访问特定的资源。
这种模型适合于需要更细粒度、动态和灵活的访问控制的场景。ABAC 在复杂的环境中可以提供高度的可配置性和可扩展性。
what is abac

不同于常见的将用户通过某些方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性来判断是否满足某种条件来进行授权判断(可以编写简单的逻辑)。

属性通常来说分为四类：

  1. 用户属性(比如用户年龄，用户地址)
  2. 环境属性(比如当前时间)
  3. 操作属性(增、删、改、查)
  4. 对象属性(比如一篇文章，又称资源属性)

特点：集中化管理

  • 可以按需求实现不同颗粒度的权限控制
  • 不需要预定义判断逻辑，减轻了权限系统的维护成功，特别是在需求经常表的系统重
  • 定义权限时，不能直接看出用户和对象间的关系
  • 规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦
  • 权限判断需要实时执行，规则过多会导致性能出现问题

ABAC的优势

ABAC 模型具有独特的功能，可以为企业带来显着的好处，包括： 

1. 政策灵活多样：ABAC 的灵活性在于其提供高上下文和细粒度访问的属性系统。几乎任何类型的策略都可以在 ABAC 中创建，唯一的限制包括计算语言的属性和条件。

2.动态授权，轻松上手：由于ABAC是基于属性的，因此它允许实时动态分配或撤销对数据或应用程序的授权。此外，新员工的入职也很简单，因为管理员和对象所有者可以轻松创建策略并分配授予新用户访问资源的属性。

3、封装：ABAC 使用封装来隐藏技术权限。只需修改属性值即可更改访问决策，而无需更改底层主体/客体关系。

4. 智能访问限制：ABAC 帮助政策制定者通过智能环境实施智能限制，以保护隐私和安全。此外，它还可以确保用户或用户组只能访问某些类型的资源或操作，具体取决于应用程序、位置或一天中的时间。

5. 监管合规性：ABAC 的精细权限和控制可以更轻松地满足各种合规性法规（HIPAA、GDPR、PCI DSS），以保护个人身份信息 (PII) 和其他敏感数据。

6. 可扩展性: ABAC展示了高可扩展性能力。设置 ABAC 后，管理员可以复制和重用其他组件和用户职位的属性，这使得策略维护和新用户加入速度更快。

ABAC 的局限性

虽然 ABAC 凭借巨大的能力和优势增强了组织，但它也有一些缺点，因此您必须意识到它的局限性。

1. 实施的复杂性：虽然 ABAC 易于使用和维护，但管理员在设计和实施 ABAC 期间必须应对日益增加的复杂性。这些过程非常耗时，并且需要资源来彻底定义和分配属性，以及设计随附的策略。然而，ABAC 实施第一阶段的投资通常会得到回报。 

2、风险暴露：定义特定员工或组织角色的风险敞口可能很困难，甚至不可能。因此，我们需要考虑到这一点。 

3. 数据挑战：如果企业的数据分散在多个数据存储、仓库和数据湖中，那么采用 ABAC 的复杂性就会增加。例如，每个位置可能需要不同的实施方法，从而增加了模糊性和复杂性。

五、对比

由于RBAC和ABAC是最常见的两种权限控制方案，网上关于这两者之间的比较也比较多，这里就截取两张对比图，可以看下两者之间的差别：

rabc vs abac

除此之外，也会存在RBAC + ABAC 混合使用的方案，比如常见的3A或4A认证系统就会使用这种，关于三者之间的对比如下：

Factor RBAC ABAC Hybrid
Flexibility Medium High High
Simplicity High Low Medium
Granularity Low High Medium
Dynamic decisions and rules No Yes Yes
Context-aware No Yes Somewhat
Implementation effort Low High Medium

五、总结

access-control-scenarios

其实每种权限控制创造出来肯定都会有相应的应用场景的，选择适当的权限管理模型需要考虑以下因素：

  • 系统规模：对于小型系统，ACL 可能是足够简单的解决方案。而对于大型系统，RBAC 或 ABAC 可能更适合。
  • 复杂性：RBAC 和 ABAC 提供了更高级别的权限管理功能，但也带来了更多的复杂性。根据系统需求和管理员的技能来评估是否需要更复杂的模型。
  • 灵活性：如果需要灵活性和动态的权限管理，ABAC 是更好的选择。RBAC 提供了一种适度的灵活性，而 ACL 则较为静态。

除了这三种提到的权限控制方法之外，还有其他的权限控制形式，如：

  • MAC(Mandatory Access Control)
  • Claims-based access control
  • Policy-Based Access Control

同时也可以参考本篇最后的wiki百科部分的参考链接，里面有更多可供选择的权限控制形式。

开源方案实现

比如这里提到的Casbin项目支持如ACL, RBAC, ABAC等访问模型，可用于Golang, Java, C/C++, Node.js, Javascript, PHP, Laravel, Python, .NET (C#), Delphi, Rust, Ruby, Lua (OpenResty), Dart (Flutter)和Elixir的授权库。

参考文档：

  1. wikipedia Access control
  2. AWS ABAC 示意图画的不错
  3. Huaweicloud ABAC

捐赠本站(Donate)

weixin_pay
如您感觉文章有用，可扫码捐赠本站！(If the article useful, you can scan the QR code to donate))