携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第30天，点击查看活动详情
基于角色的访问控制 （RBAC）
什么是 RBAC
基于角色的访问控制 （RBAC）也称为基于角色的安全性，是一种限制系统访问的机制。它涉及设置权限和特权以启用对授权用户的访问。大多数大型组织使用基于角色的访问控制，根据其角色和职责为其员工提供不同级别的访问权限。这可以保护敏感数据，并确保员工只能访问信息并执行完成工作所需的操作。
组织为每个员工分配基于角色的访问控制角色;该角色确定系统授予用户的权限。例如，您可以指定用户是管理员、专家还是最终用户，并限制对特定资源或任务的访问。组织可能允许某些个人创建或修改文件，而仅向其他人提供查看权限。
一个基于角色的访问控制示例是一组允许用户在写入应用程序中读取、编辑或删除文章的权限。有两个角色：“编写者”和“读取者”，它们各自的权限级别在此真值表中显示。使用此表，您可以为每个用户分配权限。
| 权限/角色 | 作家 | 读者 |
|---|---|---|
| 编辑 | 是的 | 不 |
| 删除 | 是的 | 不 |
| 读 | 是的 | 是的 |
在某些情况下，组织会向不同的角色授予不同级别的权限，或者其权限级别可能会重叠。在上面的示例中，一个角色（读取者）是另一个具有更多权限的角色（编写者）的子集。
访问控制的类型：补充控制机制
访问控制措施控制谁可以查看或使用计算系统中的资源，通常依赖于基于登录凭据的身份验证或授权。它们对于最大限度地降低业务风险至关重要。门禁系统可以是物理的，限制对建筑物，房间或服务器的访问，也可以是逻辑的，控制对数据，文件或网络的数字访问。
| 角色 | 企业网络 | 电子邮件 | 客户关系管理 | 客户数据库 | Unix | 员工信息 |
|---|---|---|---|---|---|---|
| 用户 | 是的 | 是的 | 不 | 不 | 不 | 不 |
| IT 系统管理员 | 是的 | 是的 | 是的 | 是的 | 是的 | 是的 |
| 开发 人员 | 是的 | 是的 | 不 | 不 | 是的 | 不 |
| 销售顾问 | 不 | 是的 | 是的 | 是的 | 不 | 不 |
| 人力资源 | 是的 | 是的 | 不 | 不 | 不 | 是的 |
基于角色的访问控制可以通过其他访问控制技术进行补充。此类访问控制的示例包括：
随机访问控制 （DAC）
受保护系统或资源的所有者设置策略，定义谁可以访问它。DAC可以涉及物理或数字措施，并且比其他访问控制系统的限制更少，因为它使个人可以完全控制他们拥有的资源。但是，它也不太安全，因为关联的程序继承安全设置并允许恶意软件在最终用户不知情的情况下利用它们。可以使用 RBAC 实现 DAC。
强制访问控制 （MAC）
中央机构根据多个安全级别来调节访问权限。MAC 涉及将分类分配给系统资源和安全内核或操作系统。只有具有所需信息安全许可的用户或设备才能访问受保护的资源。具有不同数据分类级别的组织（如政府和军事机构）通常使用 MAC 对所有最终用户进行分类。您可以使用基于角色的访问控制来实现 MAC。
访问控制类型：RBAC 替代方案
其他访问控制机制可以作为基于角色的访问控制的替代方案。
访问控制列表 （ACL）
访问控制列表 （ACL） 是一个表，其中列出了附加到计算资源的权限。它告诉操作系统哪些用户可以访问对象，以及他们可以执行哪些操作。每个用户都有一个条目，该条目链接到每个对象的安全属性。ACL通常用于传统的DAC系统。
RBAC vs ACL
对于大多数业务应用程序，RBAC 在安全性和管理开销方面优于 ACL。ACL 更适合于在单个用户级别实现安全性以及低级别数据，而 RBAC 则更好地为具有监督管理员的公司范围的安全系统提供服务。例如，ACL 可以授予对特定文件的写入访问权限，但它无法确定用户如何更改该文件。
基于属性的访问控制 （ABAC）
ABAC 评估一组规则和策略，以根据特定属性（如环境、系统、对象或用户信息）管理访问权限。它应用布尔逻辑，根据对原子或集值属性及其之间关系的复杂评估，向用户授予或拒绝访问权限。
实际上，这允许您使用可扩展访问控制标记语言 （XACML） 编写规则，使用键值对（如角色=管理器和类别=财务）。
RBAC vs ABAC
虽然 RBAC 依赖于预定义的角色，但 ABAC 更具动态性，并使用基于关系的访问控制。可以使用 RBAC 通过宽笔画确定访问控制，而 ABAC 则提供更精细的粒度。例如，RBAC 系统向所有经理授予访问权限，但 ABAC 策略仅向财务部门的经理授予访问权限。ABAC 执行更复杂的搜索，这需要更多的处理能力和时间，因此您应仅在 RBAC 不足时才求助于 ABAC。
实现基于角色的访问控制
基于角色的访问控制使组织能够改善其安全状况并遵守安全法规。但是，在整个组织中实施基于角色的访问控制可能很复杂，并可能导致利益相关者的阻力。若要成功迁移到 RBAC，应将实现过程视为一系列步骤：
- 了解业务需求 - 在迁移到 RBAC 之前，应运行全面的需求分析来检查工作职能、支持业务流程和技术。您还应考虑任何法规或审核要求，并评估组织的当前安全状况。您还可以从其他类型的访问控制中受益。
- 规划实施范围 - 确定 RBAC 要求的范围，并规划实施以符合组织的需求。缩小范围，将重点放在存储敏感数据的系统或应用程序上。这也将帮助您的组织管理过渡。
- 定义角色 - 一旦您执行了需求分析并了解了个人如何执行其任务，定义角色将变得更加容易。请注意常见的角色设计陷阱，例如粒度过多或不足、角色重叠以及为 RBAC 权限授予过多的异常。
- 实现 - 最后阶段涉及推出 RBAC。分阶段执行此操作，以避免繁重的工作负载并减少对业务的中断。首先，解决核心用户组的问题。从粗粒度访问控制开始，然后再增加粒度。收集用户的反馈并监视您的环境，以规划下一阶段的实施。
