开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第2天，点击查看活动详情
了解 RBAC 以及与 ABAC 相比的优缺点。
基于角色的访问控制 (RBAC) 是一种安全方法，它使用角色来定义用户允许做什么和不允许做什么。在 RBAC 系统中，用户被分配了对不同资源（包括文件、数据库和应用程序）具有不同权限的角色。
因此，当用户尝试访问资源时，系统将首先查找与该用户关联的角色，然后检查是否有任何角色具有适当的权限。如果是，则允许用户访问该资源。如果不是，则拒绝用户访问。
通过构建一个示例博客应用程序进行说明。
首先，我们有一个regular-user角色。我们希望允许普通用户阅读所有博客帖子，但只能编辑或删除他们创建的帖子。
另一方面，我们创建了一个admin角色，允许管理员创建、编辑和删除所有博客文章。
因此，如果只有该regular-user角色的用户试图编辑其他用户的博文，我们的系统会发现该regular-user角色无权编辑该博文并拒绝该请求。
RBAC VS ABAC
与 RBAC 不同，基于属性的访问控制 (ABAC) 是另一种安全方法，它根据用户属性、资源属性和环境属性分配权限。例如，可以将设计文件限制为标题中包含设计师并且只能在工作日访问的用户。
虽然 ABAC 在访问不同资源方面提供了更精细的粒度，但 RBAC 在易于实施方面胜出。RBAC 的初始设置成本比 ABAC 低很多。
借助 RBAC，公司可以通过一种简单的方法将具有类似访问需求的用户分组，然后为这些组分配权限。
使用 ABAC，公司必须首先定义变量并配置不同的基于属性的规则，这可能是一个繁琐的过程。
RBAC的优势
- 易于理解：由于其直观的结构，RBAC 的底层业务逻辑易于沟通和理解——即使有几十个不同的角色。
- 可扩展性：当发布新功能或更改应用程序结构时，添加或修改角色可以轻松地为需要它们的用户扩展对新资源的访问权限。
- 提高合规性：使用 RBAC 迫使开发人员思考和组织应用程序权限和访问控制。然后，合规人员可以在审计期间使用此信息。
- 降低数据泄露的风险：开发人员可以轻松地围绕其 API 的访问控制实施应用程序安全最佳实践，从而大大降低泄露的可能性。
RBAC 的缺点
- 很难做出例外：对角色的工作方式做出例外可能很复杂。在我们上面的例子中， 如果我们想添加一个规则，即拥有
regular-user角色的用户如果已经编辑了10次，就不能编辑他们自己的帖子，那么它必须作为一个单独的if语句添加到API逻辑中。角色/权限系统无法轻松地表达它。这导致了问题，因为我们必须在检查edit:self权限的所有地方都编码此规则。 - 角色滥用：因为向 RBAC 系统添加粒度的唯一方法是创建新角色，所以我们最终可以拥有数百个不同的角色。这将变得很难管理。
- 可能导致权限冲突：在某些情况下，可能会为用户分配两个具有冲突信息的角色。在我们的示例中，如果为用户分配了
admin角色和regular-user角色，他们就拥有编辑博客文章edit:self的edit:all权限。应该优先考虑哪一个？可以在 API 中对优先逻辑进行编码，但这会带来出错的可能性。
if (permissions.contains("edit:self")) {
// only allow editing if the blog post belongs to the current user
} else if (permissions.contains("edit:all")) {
// allow editing
}
即使我们的用户同时具有 theadmin和regular-userroles，他们将无法编辑所有博客，因为edit:self语句首先执行，而edit:all规则在 else-if 语句中被跳过。
