什么是基于角色的访问控制 (RBAC)？示例、好处等

柔光的暖阳◎ 2023-09-27 10:48 26阅读 0赞

基于角色的访问控制 (RBAC)，也称为基于角色的安全性，是一种[访问控制方法][Link 1]，可根据最终用户在组织中的角色为其分配权限。RBAC 提供了细粒度的控制，提供了一种简单、可管理的访问管理方法，与单独分配权限相比，这种方法更不容易出错。

这可以降低 [网络安全风险][Link 2]，保护 [敏感数据][Link 3]，并确保员工只能访问信息并执行他们完成工作所需的操作。这被称为 [最小特权原则][Link 4]。

正因为如此，RBAC 在需要根据其角色和职责授予数百甚至数千名员工访问权限的大型组织中很受欢迎。也就是说，它在较小的组织中越来越受欢迎，因为它通常比访问控制列表更容易管理。

在 RBAC 系统中，[用户访问配置][Link 5]是基于一个基于共同职责和需求的组（例如营销部门）的需求。这意味着每个角色都有一组给定的权限，并且可以将个人分配给一个或多个角色。

例如，您可以将用户指定为管理员、专家或最终用户，并限制对特定资源或任务的访问。在组织内部，可以为不同的角色提供写访问权限，而其他角色可能只提供查看权限。

用户-角色和角色-权限关系使执行角色分配变得容易，因为各个用户不再具有唯一的访问权限，而是[具有][Link 6]与分配给其特定角色或工作职能的权限一致的权限。

例如，如果您将 RBAC 应用到使用 [UpGuard][]的组织，您可以 在[UpGuard Vendor Risk上为所有][UpGuard Vendor Risk][供应商风险管理][Link 7] 员工提供用户帐户 。

### 什么是 RBAC 的例子？ ###

通过 RBAC，您可以控制最终用户可以在板级和细粒度级别上执行的操作。您可以指定用户是管理员还是标准用户，并根据用户在组织中的职位调整角色和权限。

核心原则是只为员工分配足够的访问权限来完成他们的工作。

如果员工的工作发生变化，您可能需要为其当前角色组添加和/或删除他们。

通过将用户添加到角色组，用户可以访问该组的所有权限。如果它们被删除，访问将受到限制。还可以为用户分配对某些数据或程序的临时访问权限以完成任务并在之后被删除。

RBAC 的常见示例包括：

*  **软件工程角色：**有权访问 GCP、AWS 和 GitHub
 *  **营销角色：**有权访问 HubSpot、Google Analytics、[Facebook Ads][]和 Google Ads
 *  **财务角色：**有权访问 Xero 和 ADP
 *  **人力资源角色：**可以使用 Lever 和 BambooHR

在这些角色中的每一个中，可能有一个管理层和一个单独的贡献者层，它们在授予每个角色的各个应用程序内具有不同级别的权限。

### RBAC 有什么好处？ ###

实施 RBAC 后，只要您严格遵守角色要求，访问管理就会变得更容易。根据 Research Triangle Institute 为 NIST 提供的 2010 年报告，RBAC 减少了员工停机时间，改进了供应，并提供了高效的访问控制策略管理。

RBAC 的好处包括：

*  创建系统的、可重复的权限分配
 *  [审核用户权限][Link 8]并更正已识别的问题
 *  添加、删除或更改角色，以及跨 API 调用实现它们
 *  减少分配用户权限时的潜在错误
 *  通过为 [第三方供应商和供应商][Link 9] 提供预定义角色来 降低 [第三方风险][Link 10] 和 [第四方风险][Link 11]
 *  更有效地遵守有关 [机密性、完整性、可用性和隐私][Link 12]的法规和法定要求。[随着 GDPR、 LGPD][GDPR_ LGPD]、 [PIPEDA][]、 [FIPA][]和 [SHIELD 法案][SHIELD]等通用数据保护法以及 [CPS 234][]、 [FISMA][]、 [23 NYCRR 500][]和 HIPAA等行业特定法规的引入，这一点变得越来越重要 。
 *  允许您跨操作系统、平台和应用程序在全球范围内快速切换角色和权限，从而减少管理工作和 IT 支持
 *  通过限制对敏感信息的访问来降低 [数据泄露][Link 13] 和 [数据泄露的风险][Link 14]

### 实施 RBAC 的最佳实践是什么？ ###

基于角色的访问控制允许您改善[安全状况][Link 15]、遵守相关法规并减少运营开销。但是，在整个组织中实施基于角色的访问控制可能很复杂，并且可能会导致利益相关者的抵制。

要实施 RBAC，您应该遵循以下最佳实践：

*  **从您的需求开始：** 在迁移到 RBAC 之前，您需要了解哪些工作职能使用哪些软件、支持的业务职能和技术。此外，您将需要考虑您可能有的任何监管或审计要求。
 *  **确定实施范围：** 您不一定要立即在整个组织中实施 RBAC，请考虑将范围缩小到首先存储敏感数据的系统或应用程序。
 *  **定义角色：** 一旦您执行了分析并确定了范围，您就可以开始围绕不同角色需要的权限来设计角色。注意常见的角色设计缺陷，例如粒度过大或不足、角色重叠或授予太多例外。
 *  **制定政策：** 需要概述所做的任何更改，以供当前和未来的员工查看。即使使用 RBAC 工具，文档也可以帮助避免潜在问题。
 *  **分阶段推出：** 考虑分阶段推出 RBAC，以减少工作量和业务中断。从一组核心用户和粗粒度控制开始，然后再增加粒度。在实施其他角色之前收集内部用户的反馈并监控您的业务指标。
 *  **不断适应：** 大多数组织需要几次迭代才能成功推出 RBAC。在早期，您应该经常评估您的角色和安全控制。

### 什么是 RBAC 的补充控制机制？ ###

访问控制措施调节用户权限，例如谁可以查看 计算机系统上的[敏感信息][Link 3] 或谁可以在 CRM 中运行特定任务。它们是最小化业务风险的重要组成部分。

访问控制系统可以是物理的（限制对建筑物、房间或服务器的访问）或逻辑控制对数据、文件或网络的数字访问）。

因此，RBAC 模型可以与其他访问控制技术相补充，例如：

*  **自主访问控制 (DAC)：**  DAC 是一种访问控制方法，其中受保护系统或资源的所有者设置策略来定义谁可以访问它。这可以包括物理或数字控制，并且比其他访问控制系统限制更少，因为它使个人可以完全控制自己的资源。缺点是它本质上不太安全，因为相关程序将继承安全设置，并且所有者可能会意外地将访问权限授予错误的最终用户。
 *  **强制访问控制 (MAC)：**  MAC 是一种访问控制方法，在该方法中，中央机构基于多个安全级别来规范访问权限。MAC 为系统资源、安全内核和操作系统分配分类。只有具有所需信息安全许可的用户或设备才能访问受保护的资源。这是政府和军队组织中常用的访问控制方法。

[在此处阅读我们关于访问控制的完整指南][Link 1]。

### RBAC 的替代品是什么？ ###

RBAC 的替代品包括：

*  **访问控制列表 (ACL)：** 访问控制列表 (ACL) 是一个列出附加到计算资源的权限的表。它告诉操作系统哪些用户可以访问一个对象，以及他们可以执行哪些操作。每个单独的用户都有一个条目，该条目链接到每个对象的属性（例如查看、导出、创建）。对于大多数企业而言，RBAC 在安全性和管理开销方面优于 ACL。ACL 更适合实现对低级数据的控制，而 RBAC 更适合用作公司范围的访问控制系统。
 *  **基于属性的访问控制 (ABAC)：**  ABAC 评估一组规则和策略，以根据特定属性（例如环境、系统、对象或用户信息）管理访问权限。它基于对原子属性或集值属性的评估以及它们之间的关系，应用布尔逻辑来授予或拒绝用户访问权限。ABAC 与 RBAC 不同，因为它不依赖于预定义的角色，并且 ABAC 提供了更多的粒度。例如，RBAC 系统可能会授予所有经理访问 GitHub 的权限，而 ABAC 策略会限制只有软件工程师可以访问。

[Link 1]: https://www.upguard.com/blog/access-control
[Link 2]: https://www.upguard.com/blog/cybersecurity-risk
[Link 3]: https://www.upguard.com/blog/sensitive-data
[Link 4]: https://www.upguard.com/blog/principle-of-least-privilege
[Link 5]: https://www.sailpoint.com/identity-library/identity-and-access-management
[Link 6]: https://www.upguard.com/blog/prevent-supply-chain-attacks-by-securing-pam
[UpGuard]: https://www.upguard.com/
[UpGuard Vendor Risk]: https://www.upguard.com/product/vendorrisk
[Link 7]: https://www.upguard.com/blog/vendor-risk-management
[Facebook Ads]: https://visme.co/blog/email-images/
[Link 8]: https://www.upguard.com/blog/prevent-supply-chain-attacks-with-zero-trust-architecture
[Link 9]: https://www.upguard.com/blog/third-party-vendor
[Link 10]: https://www.upguard.com/blog/manage-third-party-risk
[Link 11]: https://www.upguard.com/blog/what-is-fourth-party-risk
[Link 12]: https://www.upguard.com/blog/cia-triad
[GDPR_ LGPD]: https://www.upguard.com/blog/lgpd
[PIPEDA]: https://www.upguard.com/blog/pipeda
[FIPA]: https://www.upguard.com/blog/fipa
[SHIELD]: https://www.upguard.com/blog/shield-act
[CPS 234]: https://www.upguard.com/blog/cps-234-compliance
[FISMA]: https://www.upguard.com/blog/fisma
[23 NYCRR 500]: https://www.upguard.com/blog/new-york-cybersecurity-regulations-explained
[Link 13]: https://www.upguard.com/blog/data-breach
[Link 14]: https://www.upguard.com/blog/data-leak
[Link 15]: https://www.upguard.com/blog/security-posture