什么是基于角色的管理(RBAC)

什么是 RBAC

基于角色的访问控制(Role-based access control,简称 RBAC),指的是通过用户的角色(Role)赋予其相关权限,这实现了细粒度的访问控制,并提供了一个相比直接授予单个用户权限,更简单、可控的管理方式。

当使用 RBAC 时,通过分析系统用户的实际情况,基于共同的职责和需求,将他们分配给不同的角色。然后可以授予每个用户一个或多个角色,每个角色具有一个或多个权限,这种 用户-角色角色-权限 间的关系,让我们可以不用再单独管理单个用户,用户从具备的角色里面继承所需的权限,从而使得用户赋权这件事变得更加简单。

举一个公司内所有在职员工具备登录公司邮箱的权限的场景,如果应用 RBAC,就可以赋予所有在职员工 ​employee​ 角色,​employee​ 角色具备 ​email:login​ 权限,如此所有员工就具备了登录公司邮箱的权限。如果有员工离职,只需要将其移出 ​employee​ 角色,而不需单独收回权限。本质上,一个角色(Role)就是一组权限(Permission)的集合。使用角色添加、删除、调整权限,相比单独赋予单个用户权限更加简单。当你的用户基数不断增长时,角色会变得尤为有用。

在规划访问控制策略时,最佳实践是给予用户完成工作必须的最小权限。

使用 RBAC 的优势

  • 系统性、可重复性的权限指派

  • 更方便得用户权限审计,快速定位问题

  • 快速地添加、修改角色,甚至可以调用 API 实现

  • 减少授予用户权限时发生错误的可能性

  • 引入 第三方用户/新用户/未登录用户 时,赋予他们预先配置好的角色,比如 ​guest​

分组

除了直接赋予用户某个角色,作为 RBAC 的最佳实践,我们还可以通过分组管理用户,将一个分组和一组角色绑定,在此分组内的所有用户就会继承这些角色,并自动具备了这些角色包含的权限。这些概念之间的关系为:Permission <-> Roles <-> Groups <-> Users如下图所示:

  • 分组:Employee, Contractor

  • 角色:Vacation Requester, Invoice Submitter, Express Submitter

  • 权限:Read vacation requests, Create vacation requests 等

用分组管理用户、分组包含一组权限,这也是我们推荐使用的方式。

注:如果一个用户具备的多个角色中权限有重叠,他最终的权限列表将会是这些角色权限的并集。

分组 vs 权限

分组(Group)和角色(Role)有什么区别?

  • 角色是一组权限的集合。

  • 分组侧重于管理用户,一个分组通常拥有多个角色,分组内的用户会继承分组内所有角色的所有权限。

常见的 Group 和 Role 示例:

  • Group

    • admin: 系统管理员,通常包含系统维护者。

    • employee: 正式雇员。

    • employer: 面试官。

    • hr

    • intern: 实习生

    • ops_engineer: 运维工程师

  • Role

    • Invoice Submitter: 具备发票报销的相关权限。

    • Vacation Requester: 具备申请假期的相关权限。

    • Corporation Email User: 具备使用公司邮箱的的相关权限。

    • Production Server Operator: 具备线上服务器的操作权限。

    • HR App User: 具备使用 HR 系统的相关权限。

举例来说:可以这样建立 Role 和 Group 之间的关系:

  • intern 具备 Corporation Email User 这个角色,但是不具备 Vacation Requester 和 Invoice Submitter 这两个角色。

  • employee 拥有发票报销和申请假期角色,但是不具备线上服务器的操作权限。

  • ops_engineer 拥有发票报销、申请假期、线上服务器的角色。

推荐使用 Group organize 用户,用 Role organize 权限,不要直接赋予单个用户某个权限。如果是某个用户临时需要具备某个角色,可以临时授予,结束之后再收回。

如果你还是对 group 和 role 之间的区别不是很清晰,推荐几个资源: