RBAC:基于角色的访问控制完整指南

RBAC 基于角色的访问控制与 ABAC 示例
图片来自 Freepik

可以通过称为基于角色的访问控制 (RBAC) 的方式来控制对网络的访问。 部署 RBAC 后,员工只能看到与其职责直接相关的数据。 公司中的角色决定了每个人拥有哪些权利,并防止较低级别的员工获取敏感信息或执行属于较高级别员工的任务。 本文包含您需要了解的有关 RBAC 的所有内容,包括示例。 本文还说明了 RBAC 与 ABAC 之间的差异,以防止您在遇到其中任何一个时感到困惑。 让我们深入挖掘吧!

什么是 RBAC?

术语“基于角色的访问控制”(RBAC) 是指一种安全方法,它根据人们在公司中分配的“角色”允许或拒绝人们访问系统。 这减少了未经授权的工作人员访问私人数据或进行非法活动的可能性,同时仍然使用户能够访问完成其工作职责所需的信息和应用程序。 除了限制访问之外,RBAC 还可以改善用户与数据的交互。 它可以授予特定角色只读或读/写访问权限,这限制了用户删除数据或运行命令的能力。

大型企业或那些处理大量承包商、供应商甚至客户的企业需要一个运行良好的特权用户访问控制系统。 RBAC 将保护重要数据、提高运营效率并协助验证这些公司的监管合规性。

基于角色的访问控制如何工作

在部署 RBAC 之前,组织应仔细定义与每个角色相关的角色和权限。 这需要精确指定以下领域的权限:

  • 数据修改权限(读、写、完全访问等)
  • 访问公司内部应用程序
  • 应用程序内的权限

角色和权限建模是优化 RBAC 的第一步。 这涉及将员工的所有职责和责任指定给特定的工作,并建立适当的特权。 然后,根据工人的任务,组织可以指定职位。

组织可以使用基于角色的访问控制向各个用户分配权限或角色。 目标是确定允许用户履行其职责而无需进行额外更改的权限。

为了设置和监控 RBAC,公司使用身份和访问管理 (IAM) 工具。 IAM 主要通过记录、跟踪和更新所有身份和权限来帮助拥有大量员工的公司。 “配置”是指给予许可,“取消配置”是指取消许可。 实施该系统的组织需要为每个相关人员定义一组一致的角色。

RBAC模型

RBAC标准将访问控制分为三类:受限的、分层的和核心的。

以下是它们的完整解释:

#1。 核心 RBAC

核心模型中描述了每个基于角色的访问控制系统的基本组件。 尽管核心 RBAC 是一种独立的访问控制技术,但它也构成了有限和分层模型的基础。

#2. 分层 RBAC

如果您加强针对潜在威胁的安全态势,就好像它们已经突破您的防御一样,您可以减少成功攻击造成的损害。 通过限制网络的攻击面、分段访问和确认端到端加密,您可以减少“爆炸半径”或由漏洞造成的潜在损害。 您还可以实时关注您的网络。

#3。 受约束的 RBAC

在基本范例的基础上,第三个 RBAC 标准增加了角色分离。 职责分离有两类:静态和动态。 不允许一名用户在静态职责分离 (SSD) 关系下担任互斥的工作(由组织定义)。 

用户可以根据动态职责分离(DSD)概念参与竞争角色。 但是,用户可能无法在单个会话中执行这两项任务。 

因此,所有 RBAC 都必须遵守以下三个准则:

  • 分配角色: 只有在选择或被赋予角色后,主体才可以行使许可。
  • 按角色授权: 主体需要获得许可才能积极参与。
  • 授权许可: 主体仅可以行使主体主动角色所允许的权限。

RBAC 的示例

RBAC 使企业能够将员工分类为管理员、专家或普通人员。 以下是 RBAC 的示例:

  • 软件工程领域的开发人员可以访问各种资源来创建软件。
  • 营销用户可以使用客户关系管理 (CRM)、在线分析和内容管理系统 (CMS) 等营销工具。
  • 有权访问会计或计费系统的金融部门用户。
  • 根据功能的性质,可能有管理层和贡献者层。 在给定的应用程序内,不同的作业具有不同级别的特权。
  • 当用户的职责发生变化时,公司必须手动将其角色重新分配给新员工,或者将其分配到角色组并利用角色分配规则来更改组的成员资格。
  • 用户加入角色组后即可访问该角色组中的每个角色。 当个人被从组中删除时,其访问权限就会受到限制。 另一种选择是暂时将人们分成几个组,让他们访问特定的信息或应用程序,并在使用完后将其删除。

最佳 RBAC 实施实践

如果您遵循一些最佳实践,那么建立基于角色的访问控制会很容易。 以下是一些协助 RBAC 的优秀实践:

记下用户当前拥有的资源权限。 拥有全面的数据并能够查看用户对资源和应用程序(包括硬件和软件)的访问权限至关重要。

通过使用特定于角色的模板,标准化用户凭据并根据工作职责将访问权限限制为仅需要的人员。 此外,请密切关注对用户角色、访问权限和权限所做的任何更改,以便您可以发现并调查权限滥用、奇怪的帐户行为和其他安全漏洞。

Azure AD 中基于角色的访问控制

Azure Active Directory 提供两种基于角色的访问控制:

#1. 综合角色

Azure AD 具有大量内置角色。 然而,每个角色都具有一组不可更改的权限。

#2. 自定义角色

一组可根据角色调整的权限是 Azure AD 为定制角色提供的功能之一。 使用自定义角色授予权限的过程分为两步。 它需要生成唯一的 Azure AD 角色并根据预定列表分配必要的权限。 对象范围或组织级别都可以指定自定义角色。 虽然对象范围权限仅限于特定应用程序,但自定义权限授予成员对所有组织资源的访问权限。

管理基于角色的访问控制

您在本项目开始时构建的 RBAC 不可避免地与您最终需要的 RBAC 不同。 在安装的初始阶段,监视您的安全状态并根据需要调整您的角色。 实现稳定后,建立一个可以遵守的定期审查计划,可能每年或每季度一次,具体取决于组织的需求。

尽管使用角色可以更轻松地添加、删除和修改特定人员的权限,但随着组织变得更加复杂,您仍然需要对角色进行更改。 这就是频繁审查和迭代调整的有用之处。

不断收集意见并始终关注您的安全状况。 此外,对角色、角色分配和 RBAC 授权进行持续评估。 检查用户评论和访问日志,找出哪些功能有效,哪些无效。

当心:

  • 对特定资源具有不必要的访问权限的角色。
  • 试图获取与其职位无关的信息的个人。
  • 重叠的角色分配。
  • 角色扩展/扩散。

RBAC的优点

限制不需要的员工对关键业务信息的访问有助于维护安全性和合规性。 以下是 RBAC 的优点:

#1. 提高运营效率 

由于基于角色的访问控制简化了访问权限的自动化,因此它可以帮助减少手动职责和文书工作。 使用 RBAC 软件解决方案时,企业可以更快、更轻松地分配、更改、添加和删除角色和职责,以提高运营效率。

#2. 提高安全性

RBAC 将用户访问权限限制为完成任务所需的最小数量。 这使得公司更容易遵循安全最佳实践,例如最小特权原则 (PoLP),从而降低数据黑客和泄漏的风险。 RBAC 减少了攻击面,通过将对受保护信息的访问限制为黑客作为入口点的角色,从而减轻了违规的影响。 

#3。 表现出坚持

组织可以通过实施 RBAC 来证明对州、地方和联邦法规的遵守。 管理员和 IT 团队现在可以更有效地控制谁有权访问敏感信息。 RBAC 是金融和医疗组织可以用来控制谁有权访问 PCI 和 PHI 等敏感信息的工具。

基于角色的访问控制的缺点

以下是 RBAC 的缺点:

#1. 需要业务方面的专业知识

在角色定义方面,没有一刀切的方法。 在决定如何对角色进行分类并控制这些职位的访问权限时,组织需要跨部门协作。 这就需要彻底理解支持组织理想形式的技术框架及其组成。

在大型或发展中企业中,当 IT 或安全经理需要在没有人力资源或高级决策者支持的情况下建立职位时,这可能是一项艰巨的任务,变得更加困难。 这种频繁尝试简化实施实际上加剧了问题,并导致与总体业务目标的背离。

#2. 不灵活

RBAC 因过于严格而闻名,这是有道理的。 随着公司和团队的成长,他们的进入需求也会发生变化。 您在 RBAC 项目开始时建立的职位不再符合业务目标。 管理人员还面临着尽快入职新员工的压力,即使他们的角色并不完全明确。

结果是什么? 角色和授权级别可能并不总是匹配。 例如,某人可能被分配了太多的角色,为这些工作授予了太多的权限,或者可能两者兼而有之。 虽然这些尝试可以提供临时解决方案,但它们也会导致安全缺陷和合规性困难,违背了实施 RBAC 的初衷!

#3。 需要仔细应用

有时很难弄清楚谁做了什么。 是否存在层级结构比初级员工相对于经理的访问权限更重要的情况? 为用户提供其部门之外的工作以便他们可以临时访问具有特殊访问权限的文件是否合适? 可能会有很多问题,有时解决方案并不明显。

另请参阅: IT 软件中的配置:这意味着什么?

RBAC 的替代方案

任何不给用户带来不便的保护网络的方法都是有效的访问控制方法。 使用 RBAC 的访问控制仍然广泛使用; 但是,可能有更好的方法来限制用户权限。 访问控制列表和基于属性的访问控制是可用于管理访问控制的两种方法。

#1. ACL 与 RBAC

ACL 是存储有关谁有权访问计算机系统哪些部分的信息的数据库。 如果您想限制谁可以访问某个项目以及他们可以用它做什么,您可以使用 ACL,它代表“访问控制列表”。 操作系统根据每个用户的条目授予访问权限,该条目指定允许的操作(查看、创建、导出等)。

对于大多数企业来说,RBAC 是 ACL 的更好替代方案,因为它提供了更高的安全性,同时减少了管理工作。 您可以使用 ACL 来限制对低级数据的访问。 另一方面,RBAC 在限制访问方面更成功。

#2. RBAC 与 ABAC

基于属性(即对象、用户、系统和环境信息)管理访问权限的策略的实施称为基于属性的访问控制或 ABAC。 为了决定是否授予或拒绝对对象的访问,它使用布尔逻辑来评估集值或原子属性及其关系。 

ABAC 的粒度使其比使用固定数量职责的 RBAC 更难以管理。 RBAC 与 ABAC 的一个不同之处在于,虽然第二个系统可能限制软件工程师的访问,但第一个系统可能允许所有具有管理角色的用户访问 GitHub。

何时使用 RBAC 与 ABAC

在了解这两种模型的差异后,您可能想知道哪一种最适合您的组织。 ABAC 与 RBAC 的五个典型用例如下:

#1. 分散的工人

 如果您的团队分散在多个站点,ABAC 是更好的选择。 您可以根据员工的位置分配权限,并通过实施 ABAC 模型来限制对该时区工作时间的访问。

#2. 临时团队 

在工作时间内,临时处理项目的团队可以使用 ABAC 系统来访问关键信息和系统。 ABAC 模型中基于时间的限制可阻止敏感数据在不需要时被访问,从而防止数据泄露和泄露。

#3. 具有基本架构的公司 

如果您公司的工作组结构简单且角色很少,那么 RBAC 是更好的选择。 例如,医疗机构的接待员可以阅读和创建时间表,但不能访问患者的病史。

#4。 创意组织和媒体

创意团队通常需要在某些情况下限制访问,而在其他情况下就文件和论文进行协作。 因此,在这种情况下,有必要根据文档的性质而不是请求访问者的职能来修改访问权限。 最好的选择是ABAC。

#5。 小团队

如果您的组织规模较小且员工和资源较少,那么根据角色定义权限可能会更简单。 因此,RBAC 系统在这种情况下可能更有效。

RBAC 是什么类型的访问控制?

对资源的访问由基于角色的访问控制 (RBAC) 决定,该控制通常遵循业务逻辑。 根据需要,权限与角色相关联。

通过确保授权用户或访问者仅被授予执行其职责所需的访问权限,RBAC 保证经理和网络管理员对公司有更多的可见性和控制力。 降低开支。

标准 RBAC 角色是什么?

您可以借助 Azure 基于角色的访问控制或 Azure RBAC 来管理谁有权访问 Azure 资源、他们可以使用这些资源执行哪些操作以及他们可以访问哪些区域。 所有者、贡献者、读者和用户访问管理员是四个核心 Azure 角色。

最后的思考

基于角色的访问控制 (RBAC) 的目的是防止未经授权的用户查看、编辑或删除敏感信息。 它使工作人员可以访问信息,以便他们能够履行职责。 员工根据其工作角色和职务获得访问权限和权限。 这减少了滥用关键业务数据的可能性。

参考资料

0股
发表评论

您的电邮地址不会被公开。 必填带 *

你也许也喜欢