摘要：本文介绍了基于角色的访问控制（RBAC），包括什么是RBAC？什么是RBAC中的角色？什么是RBAC中的权限？NIST标准包含的4级RBAC模型，使用RBAC的好处，使用RBAC的缺陷，RBAC的实践，RBAC vs. ABAC vs. ACL vs. PBAC，RBAC & IAM。

RBAC允许您通过分配一组权限来创建和实施高级访问。权限基于特定用户类别执行其职责所需的访问级别。换句话说，公司中的不同人员可以完全基于其工作职能和职责等因素拥有完全不同的访问权限级别和类型。

例如，人力资源部员工可以查看员工记录，但不能查看客户数据。人力资源经理可以删除或更改人力资源记录，而较低级别的人力资源专家只能查看这些记录。

美国国家标准与技术研究院（NIST）引入了RBAC方法，作为自主访问控制（DAC）的更好替代方案。使用RBAC，可以为每个用户分配一个或多个角色，然后为这些角色分配允许的权限。用户可以是员工、承包商、业务合作伙伴等，这些类别中的每个角色都具有预定义的权限。当个人的职责或职能发生变化时，例如，由于晋升或部门调动，该人员被分配到RBAC系统中的新角色。

在RBAC框架中，角色是用于构建权限的语义结构。角色可以由任意数量的标准定义，包括权限、职责、成本中心和业务部门。

角色本质上是指用户权限的集合。这与传统的用户群不同，后者是用户的集合。在RBAC的上下文中，权限与角色绑定，而不是与身份直接连接。

角色比组更稳定，因为角色是围绕访问管理组织的，在一个典型的组织中，功能和活动的变化不像身份那样频繁。

权限（permission）即授予对受保护对象执行操作的批准的权限集。这里的受保护对象指的可以是应用中所有的内容，包括数据、模块、菜单、页面、字段、操作功能（增删改查）等等。同时，对于不同的权限可以使用不同的RBAC模型，分别管理或同一管理（即在一个系统中不一定仅使用一种RBAC模型）。例如在可以将页面访问权限与页面内的增删改查的操作权限一起基于RBAC0管理，数据权限（数据隔离）基于RBAC1实现，再为用户分配几种权限的组合。详情可查看 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还有很多其他好处，包括：

需要了解组织结构知识

没有一种一刀切的方法来定义角色。在决定如何对角色进行分类以及如何管理这些角色的访问权限时，组织必须跨部门协调。这需要清楚地了解组织的理想结构以及支持它的技术基础设施。

在大型或成长中的组织中，如果IT或安全经理需要在没有人力资源或执行决策者帮助的情况下定义角色，这可能是一项艰巨的任务，会变得更加困难。这种简化实施的常见尝试实际上使问题变得更糟，导致与公司更大的目标不一致。

需要深思熟虑的实施

分配角色可能是一项挑战。可能会出现很多问题，答案并不总是清晰的。例如：安全团队是否需要访问他们试图保护的数据，包含哪些访问权限（创建/读取/更新/删除）？是否应为用户分配部门之外的角色，以确保临时访问特权文件？

缺乏灵活性

RBAC以过于死板著称，这也难怪。组织成长，团队扩张，访问需求发生变化。在RBAC项目开始时定义的角色可能不再符合公司目标。

结果如何？人员的角色和权限级别可能不一致。例如，一个人可能被赋予过多的角色权限、分配过多的角色，或者两者兼而有之。虽然这些努力可能会起到快速修复的作用，但它们也会造成安全漏洞和法规遵从性挑战，从而打消了您最初实施RBAC的全部原因。

导致角色爆炸

一些团队试图通过定义越来越细粒度的角色、在出现新需求时创建临时角色，或将太多的角色分配给单个用户来回避上述问题。虽然这可能会在短期内缓解摩擦，但也会让RBAC变得混乱，难以管理。

这个问题通常被称为角色爆炸，是RBAC最常见的反对意见之一。当现实世界中的角色和访问需求与您的政策文件中概述的角色和访问需求不同时，甚至在很小的程度上也会出现这种情况。而作为临时解决方案创建的角色有时管理员可能会忘记或甚至故意选择保留这些角色，即使为其创建这些角色的人员离开或更换组织内的工作。结果是：特权蔓延和混乱。

Azure RBAC可帮助管理员管理对Azure资源的访问，并准确定义可在其中执行的操作。Azure RBAC是基于Azure资源管理器（ARM）的授权系统。

在Azure中分配角色有三个关键要素。

主体--请求资源并被授予访问该资源权限的用户、组、服务主体或托管标识。

角色定义--对各种Azure资源的一组权限，与分配给主体的角色相关联。它定义了具有特定角色的主体可以对资源执行的操作。

作用域--定义角色提供访问的资源以及一个或多个角色的权限级别。

在Azure中，可以直接在管理组、订阅、资源组或单个资源级别定义作用域。作用域具有父子关系，子资源继承父资源的权限。Azure包括几个基于行业最佳实践和Azure资源结构的内置角色。Azure还提供了基于组织角色的自定义RBAC兼容性。

定义角色并将作用域映射到这些角色后，管理员可以使用角色分配来授予对一个或多个安全原则的角色作用域的访问权限。如果组织需要删除访问权限，他们还可以取消角色分配。因此，作用域使权限管理变得更容易。

亚马逊云通过亚马逊Cognito服务提供RBAC。Cognito支持移动和web应用程序的身份验证、授权和用户管理。

Cognito使用用户池的概念，用户池是受管理的用户目录，身份池允许用户访问其他AWS服务。身份池授予用户访问AWS资源的临时有限权限。这些权限是通过Amazon IAM角色创建的。您可以使用令牌将角色分配给应用程序的用户，并利用基于规则的映射将角色分配给用户。

有效的访问控制是在不给用户造成摩擦的情况下保护网络安全的任何方法。虽然RBAC仍然是限制访问的常用方法，但您可能需要考虑其他选项。基于属性的访问控制（ABAC）、访问控制列表（ACL）和基于策略的访问控制（PBAC）是三种选择。

组织使用ABAC来实现更细粒度的访问控制，作为RBAC的替代或补充。与RBAC不同的是，ABAC依靠属性组合来匹配用户完成工作所需的资源。关于ABAC的详细内容可参考下文：

访问控制列表（ACL）控制或限制数字环境中的流量。ACL规则允许或拒绝两种一般类别的访问：

组织使用ACL和VPN来管理流量。这样做可以提高网络性能，提高安全性，并允许在入口和出口点进行更细粒度的监控。这使得ACL适合保护单个用户和低级数据，但在大多数业务应用程序中，它可能不是访问管理的最佳方法。

基于策略的访问控制（PBAC）是另一种侧重于授权的访问管理策略。RBAC基于静态角色限制用户访问，而PBAC基于规则和策略动态确定访问权限。尽管PBAC与ABAC非常相似，但随着所需属性数量的增加，ABAC需要更多的IT和开发资源（例如XML编码）。

PBAC的一些关键好处包括：

这些好处可能会使访问控制更加灵活，尤其是在组织不断发展和变化的情况下。但每个门禁系统都需要一定的管理和周到的实施。

IAM是一个政策、流程和技术框架，使企业能够管理数字身份并控制用户对关键企业信息的访问。通过为用户分配特定角色，并确保他们有权访问公司资源和网络，IAM提高了安全性和用户体验，实现了更好的业务成果，并提高了移动和远程工作以及云应用的可行性。

IAM平台的核心目标是为每个个人或设备分配一个数字身份。从这里开始，解决方案在每个用户的访问生命周期中维护、修改和监控访问级别和权限。

IAM系统的核心职责是：

IAM框架不仅对控制用户对关键信息的访问至关重要，而且对实现基于角色的访问控制也至关重要。这使系统管理员能够根据单个用户的角色来管理对公司网络或系统的访问，这些角色由其职务、权限级别和企业内部的责任来定义。