详细了解 RBAC（Role-Based Access Control）
摘要：本文介绍了基于角色的访问控制（RBAC），包括什么是 RBAC？什么是 RBAC 中的角色？什么是 RBAC 中的权限？NIST 标准包含的 4 级 RBAC 模型，使用 RBAC 的好处，使用 RBAC 的缺陷，RBAC 的实践，RBAC vs. ABAC vs. ACL vs. PBAC，RBAC & IAM。
什么是 RBAC？
RBAC 允许您通过分配一组权限来创建和实施高级访问。权限基于特定用户类别执行其职责所需的访问级别。换句话说，公司中的不同人员可以完全基于其工作职能和职责等因素拥有完全不同的访问权限级别和类型。
例如，人力资源部员工可以查看员工记录，但不能查看客户数据。人力资源经理可以删除或更改人力资源记录，而较低级别的人力资源专家只能查看这些记录。
美国国家标准与技术研究院（NIST）引入了 RBAC 方法，作为自主访问控制（DAC）的更好替代方案。使用 RBAC，可以为每个用户分配一个或多个角色，然后为这些角色分配允许的权限。用户可以是员工、承包商、业务合作伙伴等，这些类别中的每个角色都具有预定义的权限。当个人的职责或职能发生变化时，例如，由于晋升或部门调动，该人员被分配到 RBAC 系统中的新角色。
什么是 RBAC 中的角色？
在 RBAC 框架中，角色是用于构建权限的语义结构。角色可以由任意数量的标准定义，包括权限、职责、成本中心和业务部门。
角色本质上是指用户权限的集合。这与传统的用户群不同，后者是用户的集合。在 RBAC 的上下文中，权限与角色绑定，而不是与身份直接连接。
角色比组更稳定，因为角色是围绕访问管理组织的，在一个典型的组织中，功能和活动的变化不像身份那样频繁。
什么是 RBAC 中的权限？
权限（permission）即授予对受保护对象执行操作的批准的权限集。这里的受保护对象指的可以是应用中所有的内容，包括数据、模块、菜单、页面、字段、操作功能（增删改查）等等。同时，对于不同的权限可以使用不同的 RBAC 模型，分别管理或同一管理（即在一个系统中不一定仅使用一种 RBAC 模型）。例如在可以将页面访问权限与页面内的增删改查的操作权限一起基于 RBAC0 管理，数据权限（数据隔离）基于 RBAC1 实现，再为用户分配几种权限的组合。详情可查看 RBAC 的实践 一章。
NIST 标准包含的 4 级 RBAC 模型
RBAC0（Core RBAC）：基本模型有三个元素：用户、角色和权限。模型设计基于 “多对多” 原则，即多个用户可以具有相同的角色，一个用户可以具有多个角色。同样，您可以将同一权限分配给多个角色，也可以将同一角色分配给多个权限。
RBAC1（Hierarchical RBAC）：添加了第四个组件 - 层次结构，它定义了不同角色之间的资历关系。通过允许高级角色自动获取下级角色的权限，可以消除冗余，例如在角色重叠时必须指定某些权限。
分层 RBAC 支持几种类型的层次结构：
树：自底向上的层次结构，树底部的元素将权限授予更高的元素。例如，底部是一个具有常规权限的部门角色，所有权限比较小，上面的节点除了继承底部节点的权限，还可以添加自有的权限，这可以满足不同部门拥有不用的权限也有相同的权限的需求。
倒树：自上而下的层次结构，其中高级角色将其部分权限继承给下级角色。这种结构中层节点的权限均继承于底部节点，所以同层节点不存在共享权限。
**网格：**自下而上和自上而下的组合，其中每个角色都可以从其下方和上方的节点继承权限。此种结构相对比较灵活，既可以有共享权限，也可以有自有权限，且顶级节点拥有最大的权限。
RBAC2（Static separation of duty (SSD) relations）：为了在存在利益冲突策略的情况下提供帮助，将根据用户分配添加角色之间的关系。例如，作为一个角色的成员的用户将无法被指派为具有利益冲突的角色的成员。
RBAC3（Dynamic separation of duty (DSD) relations）：与 SSD 一样，DSD 限制了可用的用户权限，但基于不同的上下文。例如，根据会话期间执行的任务，用户可能需要不同级别的访问，DSD 限制会话期间激活的权限。
使用 RBAC 的好处有哪些？
RBAC 最大的优点之一是它提供了一种系统化的方法，用于定义和维护角色，使您能够仅根据用户需要一致地授予访问权限，从而降低数据泄露或数据丢失的风险。
但 RBAC 还有很多其他好处，包括：
- 通过根据人力资源属性自动为新员工分配访问权限来加速入职
- 简化 IT 管理工作，例如，通过在全球范围内跨多个平台和应用程序快速重新分配权限
- 改善对欧盟《一般数据保护规则》（GDPR）或美国《健康保险可移植性和责任法案》（HIPAA）等法规的遵守
- 通过为供应商和业务合作伙伴等外部用户提供预定义的角色来降低第三方风险
- 通过在角色更改时自动更新访问权限来维护 “最低权限” 的最佳实践
- 降低高级访问控制的成本，尤其是在大型复杂环境中
RBAC 有哪些缺陷？
需要了解组织结构知识
没有一种一刀切的方法来定义角色。在决定如何对角色进行分类以及如何管理这些角色的访问权限时，组织必须跨部门协调。这需要清楚地了解组织的理想结构以及支持它的技术基础设施。
在大型或成长中的组织中，如果 IT 或安全经理需要在没有人力资源或执行决策者帮助的情况下定义角色，这可能是一项艰巨的任务，会变得更加困难。这种简化实施的常见尝试实际上使问题变得更糟，导致与公司更大的目标不一致。
需要深思熟虑的实施
分配角色可能是一项挑战。可能会出现很多问题，答案并不总是清晰的。例如：安全团队是否需要访问他们试图保护的数据，包含哪些访问权限（创建 / 读取 / 更新 / 删除）？是否应为用户分配部门之外的角色，以确保临时访问特权文件？
缺乏灵活性
RBAC 以过于死板著称，这也难怪。组织成长，团队扩张，访问需求发生变化。在 RBAC 项目开始时定义的角色可能不再符合公司目标。
结果如何？人员的角色和权限级别可能不一致。例如，一个人可能被赋予过多的角色权限、分配过多的角色，或者两者兼而有之。虽然这些努力可能会起到快速修复的作用，但它们也会造成安全漏洞和法规遵从性挑战，从而打消了您最初实施 RBAC 的全部原因。
导致角色爆炸
一些团队试图通过定义越来越细粒度的角色、在出现新需求时创建临时角色，或将太多的角色分配给单个用户来回避上述问题。虽然这可能会在短期内缓解摩擦，但也会让 RBAC 变得混乱，难以管理。
这个问题通常被称为角色爆炸，是 RBAC 最常见的反对意见之一。当现实世界中的角色和访问需求与您的政策文件中概述的角色和访问需求不同时，甚至在很小的程度上也会出现这种情况。而作为临时解决方案创建的角色有时管理员可能会忘记或甚至故意选择保留这些角色，即使为其创建这些角色的人员离开或更换组织内的工作。结果是：特权蔓延和混乱。
RBAC 的实践
Azure RBAC
Azure RBAC 可帮助管理员管理对 Azure 资源的访问，并准确定义可在其中执行的操作。Azure RBAC 是基于 Azure 资源管理器（ARM）的授权系统。
在 Azure 中分配角色有三个关键要素。
主体 – 请求资源并被授予访问该资源权限的用户、组、服务主体或托管标识。
角色定义 – 对各种 Azure 资源的一组权限，与分配给主体的角色相关联。它定义了具有特定角色的主体可以对资源执行的操作。
作用域 – 定义角色提供访问的资源以及一个或多个角色的权限级别。
在 Azure 中，可以直接在管理组、订阅、资源组或单个资源级别定义作用域。作用域具有父子关系，子资源继承父资源的权限。Azure 包括几个基于行业最佳实践和 Azure 资源结构的内置角色。Azure 还提供了基于组织角色的自定义 RBAC 兼容性。
定义角色并将作用域映射到这些角色后，管理员可以使用角色分配来授予对一个或多个安全原则的角色作用域的访问权限。如果组织需要删除访问权限，他们还可以取消角色分配。因此，作用域使权限管理变得更容易。
AWS RBAC 与亚马逊 Cognito
亚马逊云通过亚马逊 Cognito 服务提供 RBAC。Cognito 支持移动和 web 应用程序的身份验证、授权和用户管理。
Cognito 使用用户池的概念，用户池是受管理的用户目录，身份池允许用户访问其他 AWS 服务。身份池授予用户访问 AWS 资源的临时有限权限。这些权限是通过 Amazon IAM 角色创建的。您可以使用令牌将角色分配给应用程序的用户，并利用基于规则的映射将角色分配给用户。
RBAC vs. ABAC vs. ACL vs. PBAC
有效的访问控制是在不给用户造成摩擦的情况下保护网络安全的任何方法。虽然 RBAC 仍然是限制访问的常用方法，但您可能需要考虑其他选项。基于属性的访问控制（ABAC）、访问控制列表（ACL）和基于策略的访问控制（PBAC）是三种选择。
RBAC vs. ABAC
组织使用 ABAC 来实现更细粒度的访问控制，作为 RBAC 的替代或补充。与 RBAC 不同的是，ABAC 依靠属性组合来匹配用户完成工作所需的资源。关于 ABAC 的详细内容可参考下文：
李敢敢：理解 ABAC（Attribute based access control）及企业级 ABAC 架构
RBAC vs. ACL
访问控制列表（ACL）控制或限制数字环境中的流量。ACL 规则允许或拒绝两种一般类别的访问：
- 文件系统 ACL 适用于文件和 / 或目录。ACL 指定允许哪个主体（人类用户或机器 / 系统进程）访问对象，以及允许对这些对象执行哪些操作。
- 网络 ACL 适用于网络路由器和交换机。ACL 指定可以访问网络的流量类型以及允许的活动。
组织使用 ACL 和 VPN 来管理流量。这样做可以提高网络性能，提高安全性，并允许在入口和出口点进行更细粒度的监控。这使得 ACL 适合保护单个用户和低级数据，但在大多数业务应用程序中，它可能不是访问管理的最佳方法。
RBAC vs. PBAC
基于策略的访问控制（PBAC）是另一种侧重于授权的访问管理策略。RBAC 基于静态角色限制用户访问，而 PBAC 基于规则和策略动态确定访问权限。尽管 PBAC 与 ABAC 非常相似，但随着所需属性数量的增加，ABAC 需要更多的 IT 和开发资源（例如 XML 编码）。
PBAC 的一些关键好处包括：
- 细粒度或粗粒度的灵活性。
- 能够快速添加、删除或修改权限。
- 环境和上下文控制（例如，有时间或位置限制的访问）。
- 了解身份和资源之间的关系。
这些好处可能会使访问控制更加灵活，尤其是在组织不断发展和变化的情况下。但每个门禁系统都需要一定的管理和周到的实施。
RBAC & IAM
IAM 是一个政策、流程和技术框架，使企业能够管理数字身份并控制用户对关键企业信息的访问。通过为用户分配特定角色，并确保他们有权访问公司资源和网络，IAM 提高了安全性和用户体验，实现了更好的业务成果，并提高了移动和远程工作以及云应用的可行性。
IAM 平台的核心目标是为每个个人或设备分配一个数字身份。从这里开始，解决方案在每个用户的访问生命周期中维护、修改和监控访问级别和权限。
IAM 系统的核心职责是：
- 根据个人角色和背景信息（如地理位置、时间或（受信任的）网络）验证和认证个人
- 捕获并记录用户登录事件
- 管理并授予企业用户身份数据库的可见性
- 管理用户访问权限的分配和删除
- 使系统管理员能够在监视用户权限更改的同时管理和限制用户访问
IAM 框架不仅对控制用户对关键信息的访问至关重要，而且对实现基于角色的访问控制也至关重要。这使系统管理员能够根据单个用户的角色来管理对公司网络或系统的访问，这些角色由其职务、权限级别和企业内部的责任来定义。
参考链接：