关于SaaS平台中应对多租户模式的设计—权限设计
关于SaaS平台中应对多租户模式的设计—权限设计
本篇是继上次的《关于SaaS平台中应对多租户模式的设计》发⽂的⼀个补充，是关于权限模块的设计。同时，在本篇也会引⽤⼀些专业术语、产品规划和⽅向以及经验的分享。
1、背景
上次写的关于《SaaS平台中应对多租户模式的设计》之后，在上继续收到了朋友的⼀些提问。在沟通的过程中，我们针对权限设计这块有了较多篇幅的讨论。
最开始时，我把我当前的⼀个saas项⽬的权限设计⽅案给他讲了⼀遍，但是对⽅的结果是，“可能太复杂了，不太适合”。其中也提出了各⾃不同的观点和建议。在后来下班回家的路上，我把⽩天所探讨的内容作了⼀下梳理和回顾。也到了所谓分歧的根源原因。其实根本原因，是我们都只站在了各⾃的业务上或平台上来进⾏讨论，忽略了问题的根本性的本质问题。所以就有了各⾃的不同建设⽅案和质疑。
2、概要
在不同的系统中，其实关于权限设计是没有标准⽅案的。⼀般地，依据项⽬需求进⾏系统的功能规划设计、组织结构设计以及对应的权限设计等即可。权限管理是所有后台系统的都会涉及的⼀个重要组成部分，主要⽬的是对不同的⼈访问资源进⾏权限的控制，避免因权限控制缺失或操作不当引发的系统风险
问题。从⽽有效的保证⼈、⾓⾊、资源的有效控制，避免数据不当的操作、隐私数据的泄露等问题。
3、RBAC模型
3.1、  概念
其实，关于权限设计最常见的就是基于RBAC模型。⽽RBAC模型⼜有RBAC0、RBAC1、RBAC2、RBAC3等⼏种常见的模式。
RBAC（Role-Based Access Control) 基于⾓⾊的访问控制的设计思想。作为传统访问控制（⾃主访问，强制访问）的有前景的代替受到⼴泛的关注。在RBAC中，权限与⾓⾊相关联，⽤户通过成为适当⾓⾊的成员⽽得到这些⾓⾊的权限。RBAC中有4个⽐较关键的元素：⽤户 – ⾓⾊– 权限 – 资源。
3.2、  RBAC⽀持的安全原则依着时令的意思
RBAC⽀持三个著名的安全原则：最⼩权限原则、责任分离原则和数据抽象原则。
最⼩权限原则：RBAC可以将⾓⾊配置成其完成任务所需的最⼩权限集合。
责任分离原则：可以通过调⽤相互独⽴互斥的⾓⾊来共同完成敏感的任务，例如要求⼀个计账员和财务管理员共同参与统⼀过账操作。
数据抽象原则：可以通过权限的抽象来体现，例如财务操作⽤借款、存款等抽象权限，⽽不是使⽤典型的读、写、执⾏权限。
3.3、 RBAC优缺点
（1）优点：
简化了⽤户和权限的关系。
易扩展、易维护。
（2）缺点：
RBAC模型没有提供操作顺序的控制机制，这⼀缺陷使得RBAC模型很难适应哪些对操作次序有严格要求的系统。
3.4、  这⾥补充⼀下术语解释：
（1）、资源
（1）、资源
被安全管理的对象（Resources页⾯、菜单、按钮、订单等）。
（2）、 权限
（2）、 权限
访问和操作资源的许可（Permit删除、编辑、审批等）。
（3）、⾓⾊
（3）、⾓⾊
⽤户通过业务需求确定⼀个⾓⾊（Role），并按照实际的业务场景，赋予⾓⾊对应的权限的过程，⾓⾊也可以理解是权限的集合，是众多权
限颗粒组成。
（4）、 ⽤户
（4）、 ⽤户
系统实际的操作员（User）
斑马斑马
（5）、操作权限
（5）、操作权限
页⾯权限：即⽤户登录系统可以看到的页⾯，由菜单来控制，菜单包括⼀级菜单或多级菜单。当系统赋予⽤户对应菜单的权限，那么⽤户就可以访问对应的菜单页⾯。
太平洋汽车保险查询操作权限：即页⾯的功能按钮，包括：查看、新增、修改、删除、审核等。当⽤户点击按钮时，系统将会校验⽤户的是否包含次操作权限，如果有，就可以进⾏下⼀步操作。
数据权限 ：数据权限就是⽤户在同⼀页⾯看到的数据是不同的。⽐如项⽬管理员，就能看到当前团队正在进⾏中的项⽬，以及项⽬的进度情况。⽽团队成员，就只能看到本⼈具体参与的项⽬，已经项⽬信息。相对于复杂⼀项的权限也可以基于组织结构来拓展。
总的来说，⼀般我们会这样来⽤⼀句话更好的理解它：【⽤户(user：谁)】被赋予【⾓⾊(role：具有1-n个权限)】，通过⾓⾊关联的【权限    总的来说
(permit：许可)】去访问/操作【资源(resource)】。如下图：欧美动画电影
⽤户-⾓⾊-权限-资源的关系
3.5、  RBAC0模式
⽤户-⾓⾊-权限的关系
这是权限最基础也是最核⼼的模型，基本上绝⼤多数就是基于它来建设，包括⽤户、⾓⾊、权限。其中⽤户和⾓⾊可以是多对多的关系；⾓⾊和权限也是多对多的关系。
⽤户是发起操作的主体，可以是业务性的访问者、可以是后台管理系统的⽤户。⾓⾊起到了桥梁的作⽤，连接了⽤户和权限的关系。由于⾓⾊和权限的关系是多对多，⽽⽤户与⾓⾊也是多对多的关系，所以⼀个⽤户就有⼀个或多个⾓⾊⼀个或多个系统权限（这⾥关于针对⽐较简单的系统，例如⽤户量很⼩，项⽬级别也很⼩的系统，可以采⽤⽤户直接和权限关联。也就是添加⼀个⽤户，就直接针对⽤户去添加对应的权限，可以没有⾓⾊的概念。针对这种情况，在此不展开讨论）。
权限是⽤户可以访问的资源，包括：页⾯权限、作权限、数        ⼀般的系统中，引⼊⾓⾊（Role）
⾓⾊（Role）就是为了提升了系统操作的效率和拓展性。权限
据权限等（具体解释看上⾯的术语部分）。下⾯⽤具体的图例来展⽰：
RBAC0模式案例
3.6、  RBAC1模式
⾓⾊继承（Hierarchical Role）的概念。即⾓⾊具有上下级的关系，⾓⾊间的          RBAC1模式是RBAC0的拓展。主要是在⾓⾊上引⼊了⾓⾊继承（Hierarchical Role）
继承关系可分为⼀般继承（General）和受限继承（Limited）关系。⼀般继承关系仅要求⾓⾊继承关系是⼀个绝对偏序关系，允许⾓⾊
⼀般继承关系仅要求⾓⾊继承关系是⼀个绝对偏序关系，允许⾓⾊间的多继承。⽽受限继承关系则进⼀步要求⾓⾊继承关系是⼀个树结构，实现⾓⾊间的单继承，受限继承则增强了职责关系的分离。这间的多继承。⽽受限继承关系则进⼀步要求⾓⾊继承关系是⼀个树结构，实现⾓⾊间的单继承，受限继承则增强了职责关系的分离。
种设计可以给⾓⾊分组和分层，⼀定程度简化了权限管理⼯作。
⾓⾊继承关系
这⾥举⼀个场景例⼦，⽐如销售团队，销售主管或经理⼀般会需要了解并汇总下⾯销售专员的数据。
⽽销售专员能够管理各⾃的销售数据。此时，销售主管就需要向下继承销售专员的⾓⾊，进⽽也就拥有了他们的基本权限。
RBAC1模型
3.7、  RBAC2模式
RBAC2同样建⽴在RBAC0基础之上，仅是对⽤户、⾓⾊和权限三者之间增加了⼀些限制，实现了责任分离。RBAC2中的⼀个基本限制是互斥⾓⾊的限制，互斥⾓⾊是指各⾃权限可以互相制约的两个⾓⾊。对于这类⾓⾊⼀个⽤户在某⼀次活动中只能被分配其中的⼀个⾓⾊，不能同时获得两个⾓⾊的使⽤权。该模型有以下⼏种约束：
（1）互斥⾓⾊
同⼀⽤户只能分配到⼀组互斥⾓⾊集合中⾄多⼀个⾓⾊，⽀持责任分离的原则。互斥⾓⾊是指各⾃权限互相制约的两个⾓⾊。对于这类⾓⾊⼀个⽤户在某⼀次活动中只能被分配其中的⼀个⾓⾊，不能同时获得两个⾓⾊的使⽤权。常举的例⼦：在审计活动中，⼀个⾓⾊不能同时被指派给会计⾓⾊和审计员⾓⾊。
（2）基数约束
⼀个⾓⾊被分配的⽤户数量受限；
中考总分是多少?⼀个⽤户可拥有的⾓⾊数⽬受限；
同样⼀个⾓⾊对应的访问权限数⽬也应受限，以控制⾼级权限在系统中的分配。例如公司的领导⼈有限的。
（3）先决条件⾓⾊
可以分配⾓⾊给⽤户仅当该⽤户已经是另⼀⾓⾊的成员；对应的可以分配访问权限给⾓⾊，仅当该⾓⾊已经拥有另⼀种访问权限。指要想获得较⾼的权限，要⾸先拥有低⼀级的权限。
（4）运⾏时互斥
允许⼀个⽤户同时拥有多个⾓⾊，但在系统运⾏中或部分特殊场景不可同时使⽤这两个⾓⾊，只能使⽤其中⼀种⾓⾊。
这些限制可以分成两类，即静态职责分离SSD（Static Separation of Duty）
动态职责分离DSD（Dynamic Separation
静态职责分离SSD（Static Separation of Duty）和动态职责分离DSD（Dynamic Separation of Duty）。
of Duty）
（1）静态职责分离（SSD）
当⾓⾊授权给⽤户时，需要判断当前⽤户是否被赋予了⼀个与新⾓⾊冲突的⾓⾊，冲突的⾓⾊位⼀个⼆元关系，任何⼀个⽤户在此场景下只能拥有其中⼀个⾓⾊。
（2）动态职责分离（DSD）
在⾓⾊分配时可以将冲突的⾓⾊赋予给同⼀个⽤户，但是在⽤户使⽤系统时，⼀次会话中不能同时激活两个⾓⾊。
RBAC2模型
3.8、  RBAC3模型
即最全⾯的权限管理，它是基于RBAC0，将RBAC1和RBAC2进⾏了整合。这种模式即要维护好⾓⾊间的继承关系处理好分层，⼜
RBAC3 = RBAC1 + RBAC2 。
要处理⾓⾊间的责任分离。模型公式：RBAC3 = RBAC1 + RBAC2 。
4、场景实战
4.1 需求场景
我们⽬前在做⼀款toB的产品，采⽤SaaS的模式对外B端客户提供服务。⽬标就是如何规划好平台的管理、租户的管理、租户应⽤的管理以及租户业务流程等内容的管理。我们将SaaS平台基本⾓⾊分为平台管理员、平台运维、平台开发、租户管理员、租户⼦管理员、租户其他⾓⾊组成。在这⾥，我将我们SaaS服务的权限部分设计分享出来。
基于组织结构、⾓⾊组的权限设计
4.2 设计说明
一年级数学教学计划我们这套设计，涉及两部分，即完整的企业组织结构和⾓⾊组。所以这⾥针对部分概念进⾏说明。
4.2.1 组织（部门）
针对toB的产品，往往要考虑如何⽀撑起企业的组织结构，⽐如企业的部门层级。同时组织结构也可以与⾓⾊进⾏关联，⽤户加⼊组织后，就会⾃动获得该组织的默认⾓⾊。同时⽤户在调岗时，只需调整组织、⾓⾊即可批量调整。组织的另外⼀个作⽤是控制数据权限，把⾓⾊关联到组织，那么该⾓⾊只能看到该组织下的数据权限。
4.2.2 ⽤户组（⾓⾊组）
在系统中，存在相同属性或操作功能的⽤户存在。随着使⽤的⽤户基数增⼤、⾓⾊类型增多时，分配的⼯作就会越发的繁琐。这⾥可以增加⽤户组的概念来统⼀规划这⼀部分⽤户的权限管理。在上⾯的设计中，⾓⾊组中的岗位、职位就充当了这部分的作⽤。以后其他⽤户加⼊对应的⽤户组（⾓⾊组）后，即可⾃动获取⽤户组的所有⾓⾊。退出⽤户组，同时也撤销了⽤户组下的⾓⾊，⽆须管理员⼿动管理⾓⾊。
4.2.3  职位 / 岗位
每个组织部门下都会有多个职位或岗位，⽐如IT技术部会有技术总监、技术经理、研发组长、开发等职位。虽然都在同⼀部门，但是每个职位的权限是不同的，职位⾼的拥有更多的权限。研发总监拥有所有权限，研发组长和开发拥有部分权限。有些特殊情况下，⼀个⼈可能⾝兼多职。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。