权限系统设计学习总结—— SaaS 平台多租户模式下权限设计

Posted 2022-01-29 科技D人生

一、RBAC模型

1.1、概念

权限设计最常见的就是基于 RBAC 模型。而 RBAC 模型又有 RBAC0、RBAC1、RBAC2、RBAC3 等几种常见的模式。RBAC（Role-Based Access Control) 基于角色的访问控制的设计思想。作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。RBAC 中有4个比较关键的元素：用户 – 角色 – 权限 – 资源。

1.2、 RBAC 支持的安全原则

RBAC 支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则。

最小权限原则：RBAC 可以将角色配置成其完成任务所需的最小权限集合。

责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作。

数据抽象原则：可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读、写、执行权限。

1.3、 RBAC 优缺点

（1）优点：简化了用户和权限的关系。易扩展、易维护。

（2）缺点：RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。

1.4、术语解释

 （1）、资源：被安全管理的对象（Resources页面、菜单、按钮、订单等）。

   (2）、 权限：问和操作资源的许可（Permit删除、编辑、审批等）。

（3）、角色：用户通过业务需求确定一个角色（Role），并按照实际的业务场景，赋予角色对应的权限的过程，角色也可以理解是权限的集合，是众多权限颗粒组成。

（4）、 用户：系统实际的操作员（User）

（5）、操作权限

页面权限：即用户登录系统可以看到的页面，由菜单来控制，菜单包括一级菜单或多级菜单。当系统赋予用户对应菜单的权限，那么用户就可以访问对应的菜单页面。

操作权限：即页面的功能按钮，包括：查看、新增、修改、删除、审核等。当用户点击按钮时，系统将会校验用户的是否包含次操作权限，如果有，就可以进行下一步操作。

数据权限 ：数据权限就是用户在同一页面看到的数据是不同的。比如项目管理员，就能看到当前团队正在进行中的项目，以及项目的进度情况。而团队成员，就只能看到本人具体参与的项目，已经项目信息。相对于复杂一项的权限也可以基于组织结构来拓展。

总的来说，一般我们会这样来用一句话更好的理解它：【用户(user：谁)】被赋予【角色(role：具有1-n个权限)】，通过角色关联的【权限(permit：许可)】去访问/操作【资源(resource)】。如下图：

1.5、 RBAC0 模式

这是权限最基础也是最核心的模型，基本上绝大多数就是基于它来建设，包括用户、角色、权限。其中用户和角色可以是多对多的关系；角色和权限也是多对多的关系。用户是发起操作的主体，可以是业务性的访问者、可以是后台管理系统的用户。角色起到了桥梁的作用，连接了用户和权限的关系。由于角色和权限的关系是多对多，而用户与角色也是多对多的关系，所以一个用户就有一个或多个角色一个或多个系统权限（这里关于针对比较简单的系统，例如用户量很小，项目级别也很小的系统，可以采用用户直接和权限关联。也就是添加一个用户，就直接针对用户去添加对应的权限，可以没有角色的概念。针对这种情况，在此不展开讨论）。一般的系统中，引入角色（Role）就是为了提升了系统操作的效率和拓展性。权限是用户可以访问的资源，包括：页面权限、作权限、数据权限等（具体解释看上面的术语部分）。下面用具体的图例来展示：

1.6、RBAC1 模式

RBAC1 模式是RBAC0的拓展。主要是在角色上引入了角色继承（Hierarchical Role）的概念。即角色具有上下级的关系，角色间的继承关系可分为一般继承（General）和受限继承（Limited）关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承，受限继承则增强了职责关系的分离。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

这里举一个场景例子，比如销售团队，销售主管或经理一般会需要了解并汇总下面销售专员的数据。而销售专员能够管理各自的销售数据。此时，销售主管就需要向下继承销售专员的角色，进而也就拥有了他们的基本权限。

1.7、RBAC2模式

RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制，实现了责任分离。RBAC2中的一个基本限制是互斥角色的限制，互斥角色是指各自权限可以互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。该模型有以下几种约束：

（1）互斥角色：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。

（2）基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的。

（3）先决条件角色：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。

（4）运行时互斥：允许一个用户同时拥有多个角色，但在系统运行中或部分特殊场景不可同时使用这两个角色，只能使用其中一种角色。这些限制可以分成两类，即静态职责分离SSD（Static Separation of Duty）和动态职责分离DSD（Dynamic Separation of Duty）。

         静态职责分离（SSD）：当角色授权给用户时，需要判断当前用户是否被赋予了一个与新角色冲突的角色，冲突的角色位一个二元关系，任何一个用户在此场景下只能拥有其中一个角色。

         动态职责分离（DSD）：在角色分配时可以将冲突的角色赋予给同一个用户，但是在用户使用系统时，一次会话中不能同时激活两个角色。

1.8、 RBAC3 模型

即最全面的权限管理，它是基于RBAC0，将RBAC1和RBAC2进行了整合。这种模式即要维护好角色间的继承关系处理好分层，又要处理角色间的责任分离。模型公式：RBAC3 = RBAC1 + RBAC2 。

二、场景实战

2.1 需求场景

我们目前在做一款toB的产品，采用SaaS的模式对外B端客户提供服务。目标就是如何规划好平台的管理、租户的管理、租户应用的管理以及租户业务流程等内容的管理。我们将SaaS平台基本角色分为平台管理员、平台运维、平台开发、租户管理员、租户子管理员、租户其他角色组成。在这里，我将我们SaaS服务的权限部分设计分享出来。

2.2 设计说明

我们这套设计，涉及两部分，即完整的企业组织结构和角色组。所以这里针对部分概念进行说明。

2.2.1 组织（部门）

针对toB的产品，往往要考虑如何支撑起企业的组织结构，比如企业的部门层级。同时组织结构也可以与角色进行关联，用户加入组织后，就会自动获得该组织的默认角色。同时用户在调岗时，只需调整组织、角色即可批量调整。组织的另外一个作用是控制数据权限，把角色关联到组织，那么该角色只能看到该组织下的数据权限。

2.2.2 用户组（角色组）

在系统中，存在相同属性或操作功能的用户存在。随着使用的用户基数增大、角色类型增多时，分配的工作就会越发的繁琐。这里可以增加用户组的概念来统一规划这一部分用户的权限管理。在上面的设计中，角色组中的岗位、职位就充当了这部分的作用。以后其他用户加入对应的用户组（角色组）后，即可自动获取用户组的所有角色。退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。

2.2.3 职位 / 岗位

每个组织部门下都会有多个职位或岗位，比如IT技术部会有技术总监、技术经理、研发组长、开发等职位。虽然都在同一部门，但是每个职位的权限是不同的，职位高的拥有更多的权限。研发总监拥有所有权限，研发组长和开发拥有部分权限。有些特殊情况下，一个人可能身兼多职。

2.2.4 角色

角色是权限控制的最小单位（不是权限的最小单位），通过角色来进行权限资源的分配。在上面的设计中，就是遵循RBAC模式进行的设计。例如管理角色组，就涉及到了RBAC1，主管理员同时拥有子管理员的权限；同时也涉及到了RBAC2，一个组织只能有一个主管理员（基数约束 ），但是可以有多个子管理员。

2.2.5 含有组织、职位、用户组、角色模型

通过根据以上场景，平台的权限模型设计如下图:

以上基本就是关于我们一个项目的权限设计部分。