基于角色的访问控制（RBAC）

什么是基于角色的访问控制 (RBAC)？

一种根据组织内某些用户的职责来限制网络访问的技术称为基于角色的访问控制，简称 RBAC。RBAC，也称为基于角色的安全，是组织用来根据个别员工的角色和职责来划分访问级别的工具。

对于拥有大量员工、承包商或第三方（如供应商和客户）可以访问网络的公司来说，限制网络访问至关重要。这是因为充分监控网络访问可能会很困难。使用 RBAC 的公司能够更好地保护其敏感信息和关键应用程序。RBAC 可防止用户访问与他们无关的信息，并确保他们只访问执行其职责所需的数据。

一个人被允许的权限取决于其在组织中的职位，从而确保低级别员工无法访问敏感数据或执行高级别任务。

RBAC 的基础是角色和权限的概念。权力、技能和问责制等因素决定了访问权限。员工可以限制对网络和其他资源的访问，包括文件或程序。例如，某些程序或文件可能只能临时访问，而为了完成一项工作，其他文件可能只能读取。组织可以将用户归类为管理员、最终用户或专业用户。此外，这些职位可能重叠，或者提供不同程度授权的独特功能。

实施基于角色的访问控制的有效程序

在采用 RBAC 时，组织应遵循一些最佳实践，例如以下几点

• RBAC 可以在没有身份和访问管理 (IAM) 系统的情况下实现，尽管当 IAM 系统到位时会更容易实现。IAM 简化了数字或电子身份的管理。IT 管理员可以通过使用 IAM 架构来控制用户对其组织内关键信息的访问。
• 列出需要控制访问的资源。联系人管理系统、电子邮件和客户数据库可能属于此类。
• 检查劳动力并确定哪些职位需要相同的访问级别。但要小心——创建过多的角色可能会抵消基于角色的访问限制的好处。一个包含每位员工所需访问权限（包括电子邮件和公司内网）的基本职位是 RBAC 的一个例子。另一个职位可能是对客户数据库具有读写访问权限的客户支持代理。
• 遵循最小权限原则 (POLP)。根据 POLP，用户应仅拥有执行其工作所需的活动、程序或数据的访问权限。必须使用 RBAC 角色来提供超出最小权限级别的附加活动访问权限。
• 创建了角色及其相应访问权限的列表后，将员工分配给这些角色并配置他们的访问权限。
• 检查处理职位变更、关闭离职员工帐户以及注册新员工的流程。
• 制定 RBAC 策略，概述了可能需要避免的问题。
• 确保 RBAC 已集成到公司使用的每个系统中。
• 提供培训，使员工了解 RBAC 的原则。
• 定期审核角色，同时考虑分配给这些角色的员工以及为每个职能允许的访问级别。如果发现某个特定角色对某个特定系统拥有不必要的访问权限，则更改该角色并调整访问级别。

基于角色的访问控制的好处

有许多可用的安全选项，为我们的业务选择最佳选项并非易事。RBAC 的许多成熟优点使其在竞争对手中脱颖而出。

RBAC 框架能够

• 降低复杂性：根据新员工的职位授予访问权限，而不是广泛的服务器和文档要求列表。这使得策略的建立、维护和审计更加容易。
• 允许全局管理：修改角色的权限以同时更改多个员工的访问权限。
• 简化入职流程：当有人加入、内部调动或在我们的组织内获得晋升时，我们无需担心他们的权限——只需确保他们位于正确的位置即可。其余的由角色处理。
• 减少错误：传统安全管理中经常发生错误。当我们为个人添加权限时，有很多出错的空间。如果我们更改角色的访问权限，我们授予某人过多（或过少）权限的可能性就会降低。
• 降低总成本：由于管理任务的减少，公司在安全管理方面的支出会节省。这样做将为我们的公司节省时间和金钱。

RBAC 与 ABAC

尽管它们都使用访问控制技术，但基于角色的访问控制和基于属性的访问控制 (ABAC) 使用不同的方法。ABAC 根据以下类别的组合来管理访问权限，而 RBAC 根据用户的职责授予访问权限

• 用户属性：姓名、国籍、组织、ID、工作和安全级别是其中的一些示例。
• 资源属性：这些可能包括有关对象名称、所有者和创建日期等信息。
• 操作属性：这些属性描述了与正在使用的应用程序或系统相关的活动。
• 环境属性：威胁级别、访问位置和访问时间是其中的一些示例。例如，美国陆军在采用 ABAC 的同时，还采用了零信任安全方法。

RBAC 是一种预定的基于角色的访问控制机制；相比之下，ABAC 更具动态性，并提供更精细化的控制。

例如，组织可以使用 RBAC 来提供粗粒度的访问控制。例如，所有大学教授都应该能够访问 Google 进行研究，所有承包商都应该能够访问公司电子邮件。但是，当涉及细粒度访问控制或需要在特定情况下做出决策时，公司应该使用 ABAC。例如，仅当学者在 X 楼工作并且教授一年级学生时，才授予他们访问 Google 的权限。

RBAC 示例包括

组织可以为用户分配到组或职位。当用户添加到角色组时，他们将获得该角色组中所有权限的访问权限。

组织可以选择将职责划分为访客、特定于工作的最终用户和管理员。以下角色是可能角色的示例

• GitHub、Docker 和 Jenkins 是该公司分配给该职位的软件工程师可用的唯一软件工程技术。
• 一位市场营销人员被分配了一个特定的职位，并拥有对公司营销资源的独占访问权限。例如，这可能包括社交媒体帐户、Google Analytics 或电子邮件营销列表。
• 一位人力资源员工被分配了一个职位，可以访问与 HR 相关的服务，包括 Paycor、ADP 和 Oracle Cloud Human Capital Management。

例如，软件工程师将能够访问他们完成工作所需的工具，但他们无法访问同一组织内营销或 HR 部门的数据或资源。同样，营销专业人员将能够访问他们工作所需的工具，但无法访问软件工程或人力资源工具。每个用户的权限都基于他们在公司中的职位和职能。

RBAC 与 ACL

就管理负担和安全性而言，对于大多数商业应用，RBAC 的表现优于 ACL。RBAC 更适合具有监管管理员的公司级安全系统，而 ACL 更适合在单个用户级别和低级别数据上建立安全性。例如，ACL 可能允许对特定文件的写入访问权限，但它无法控制用户如何编辑该文件。

基于角色的访问控制权限：它们是什么？

权限定义了用户在系统中的访问范围和操作。权限是个人根据我们所定义的职责所遵守的指导方针。

权限应包括

• 访问权限：特定磁盘、程序、文件或记录对哪些人开放？谁能说这些东西甚至不为人知？访问权限将限制个人可以看到的内容。
• 阅读：即使他们无法更改这些文件中的任何内容，谁可以阅读它们？某些角色可能能够参考材料但不能修改它们。
• 撰写：谁有权修改文档？修改是最终的还是需要其他人批准？我们将使用我们的授权来澄清这一点。
• 分发：谁有权将文档作为电子邮件附件进行传输？与其他权限类似，有些人可能能够引用但不能分发它们。
• 财务：谁有权收费？谁能退款？处理费用和退款、创建信用帐户或停止付款的能力是权限的一些示例。

重要的是要记住，角色优先于权限。确定每个职位的职责并相应地应用权限。

即使员工的现有工作限制了他们，也不要让他们请求权限。如果我们开始逐个更改权限，系统可能会很快变得非常复杂。