SaaS平台权限架构

22 评论 26062 浏览 403 收藏 12 分钟

编辑导语:对于业务较多的公司来说,组织结构相对复杂,这时候平台的权限架构就显得尤为重要,本篇文章作者分享了有关SaaS平台的权限架构的内容,详细介绍了不同运营场景下的数据权限问题,感兴趣的一起来学习一下,希望对你有帮助。

对于SaaS系统的权限,就是登录账号的功能权限和数据权限的合集。

功能权限是账号在平台上能看到哪些页面,能操作页面里面的哪些功能或按钮。

数据权限就是这个账号能在系统中看到哪些数据,能对哪些数据做功能级的操作。

功能权限一般靠角色和功能集进行关联,即RBAC模型。数据权限一般靠靠租户的组织架构来实现数据的隔离。

然后账号和角色关联,获得功能权限,和组织架构关联,获得可管理的数据。下面对相应内容做详细介绍。

一、组织架构解决数据权限

在实际运营场景中,稍微大点的公司,组织架构相对比较复杂,层级比较多,每个层级节点要看到的数据要求是不一样的,所以要对不同层级节点的数据做隔离。

例如,某餐饮公司组织架构如下,则总部的CEO要看到下属分公司的所有数据,分公司的总经理要看到所有下属区域的数据,朝阳区区域经理要看到下属所有门店的数据,门店店长要看到店里的所有数据。

所以要在平台账号权限中引入组织架构,账号直接跟组织架构关联,在哪个层级看到哪个层级的数据,通过组织架构对多层级数据进行隔离。

总体来说,账号关联组织架构时,需要确定下来方位的数据精确到哪一节点,是本节点及下级节点数据,或只有本节点数据,或指定的某个下级节点数据,或是只能管理属于自己创建的数据。

特殊的也会存在跨层级查看数据的情况。有以下五种场景:

1)场景1:账号可看到本层级及下级数据。

在创建账号时,要选择这个账号属于哪个层级,则就能看到当前层级及以下层级的所有数据。

如账号1可看到北京分公司及其下属节点的所有数据。

这种是比较常用的数据权限,同时账号不能看到上级组织结构节点的数据,如账号2属于朝阳区这个节点,则不能看到属于北京分公司的数据。

2)场景2:账号只能看到本层级的数据。

数据权限更深层的需要细化出来这个账号能看到具体哪个级别的数据,如账号3是属于朝阳区,但他有可能只能看到属于朝阳区这一层的数据,下级节点的门店数据是看不到的。

3)场景3:账号只能看到下级某一节点的数据。

如售后人员的账号2,虽然是属于北京分公司,但只能负责朝阳区下面门店1和门店2的数据。

基于这种情况,需要在创建账号时,在关联组织架构,还要指定当前账号能看到这个节点下的哪些数据。

4)场景4,账号只能看到指定层级的指定数据。

每个组织架构的层级上会有一些属于当前级别某些账号特有的数据。

如商务合作的客户数据,属于当前组织架构的节点,同样属于某个商务人员独有,不会共享给其他招商人员。

如招商部的A员工的账号3,管理的客户信息是属于朝阳区的,同样也只属于账号3所属的A员工管理。

其他同级别的账号4所属的员工,则没有权限看到这些客户信息。但招商部的部门经理是要看到本部门的所有数据。

所以在创建账号时,还要指定这个账号是能看到本部门的数据还只能看到自己创建的数据。

5)场景5:存在管理不同级别其他节点数据。

例如账号5原本属于组织架构里的门店1,理论上只能管理门店1的数据,但如果门店4这种不在同一个上级节点的门店,希望帮忙分析售后问题,那账号5如何跨节点管理门店4的售后问题。

答案是门店4的管理者可以指定某些数据或节点的所有数据共享给门店1的账号5管理。

数据共享不限制组织结构的上下级和同级关系。

二、角色解决功能权限(RBAC模型)

1. 基础角色权限模型(RBAC0)

为什么要靠角色来解决功能权限,而不是使用账号跟功能直接关联?是因为平台页面多,页面内的功能也非常多的情况下,如果靠账号直接跟页面和功能关联,所有账号都操作起来比较繁琐。

引入角色,把角色和权限关联,这样有相同权限的人直接跟角色关联,进而获得角色所对应的功能权限。提高的操作的便利性。角色本身就是功能的合集。

同一个账号,可以有多个角色,则可获得多个角色的并集的权限。如账号4关联员工和助理两个角色,则账号4可获得员工角色对应的页面3、页面4和助理角色对应的页面5的功能权限。

2. 角色搭建组织架构(RBAC1)

对于组织架构没有那么复杂的,则会有使用角色来实现组织架构的,角色设计成带有上下级的树形结构。

这种实现方式灵活性会比较差,如果组织架构复杂,则角色量比较多,同样一个店长角色,需要在每个组织架构的节点上都进行单独创建。一般不会采用这种实现方式。

3. 角色互斥场景(RBAC2)

实际业务场景中,存在同一个账号不能同时获得两个角色,两个角色互斥,有这个角色就不能获得另外一个角色。

财务中的会计和出纳两个角色,一个人是不能同时负责,做到财权分离。

这种需要在创建角色定义中专门去定义互斥情况。

4. 角色同时有组织架构和角色互斥(RBAC3)

复合型的RBAC1+RBAC2的一种合成形式,角色上既有组织架构,又有角色互斥的实现形式。

三、账号关联角色或组织内的岗位

1)账号只绑定角色来同时获得功能权限和数据权限。

如上图所示,把角色当成岗位,可将角色直接与组织架构关联,账号只需与角色关联,不用单独关联组织架构,则账号直接获取当前角色下的功能权限和角色对应的组织架构下的数据权限。

这样如果账号需要调整岗位时,直接调整账号对应的角色就可以,方便操作。

但这种需要在每个节点上创建好岗位和对应节点的角色,角色的数据量会比较多,每个角色都要配置对应的功能权限。

2)账号只绑定组织架构内的岗位来同时获得功能权限和数据权限。

在组织架构上创建岗位,岗位和对应的角色关联,账号直接跟组织架构上的角色进行关联,同时获得角色权限,无需再关联角色。

账号在调岗时直接更换组织架构中的岗位就可以。

这种和上面的场景一样,都需要频繁重复创建一样的内容。

四、审批流程业务场景。

上面介绍的账号与角色和组织架构关联来解决功能权限和数据权限的问题,但涉及到审批流程的,如在门店1内部,服务员请假,需要店长审批,但两个人都属于同一组织架构的门店1上,没有上下级关系,只能在流程上指定人去审批。

但这样每个部门内部都需要自己创建审批流程,操作起来比较繁琐。

因为角色的作用本身就是岗位职责,可以在审批流程中引入角色,审批节点都是角色。

  • 例如请假,可在审批流程中设定门店的员工角色请假都要让门店的店长或管理者角色审批,这样所有的门店都遵照这个流程。
  • 例如报销流程需要走门店店长和区级财务经理这两个审批。如果报销一定金额,需要走分公司的财务副总这个人审批,则需要在流程中支持指定人来审批的功能。但一般不建议指定人审批,后续人员调整,审批流程也要做相应调整。

另外如果当前审批角色上有多个账号,则多个账号都可以审批,除非流程上指定某个账号审批。

如财务报销走到了朝阳区的财务角色,下面有账号3和账号4,则账号3和4都可以审批,本着谁审批,谁负责的原则。

如果账号3审批了某个报销单,后续打款也应当走到账号3上来进行审批。

五、角色组和用户组使用场景。

  1. 角色组是多个角色的合集,多个角色下的功能权限的合集,为了在1个账号绑定多个角色时方便操作,倒不如直接建个新的角色绑定账号。
  2. 用户组,就是多个账号的合集,为了在多个账号绑定同一个角色时方便操作,并没有解决解决具体权限问题。

六、总结

目前基于SaaS平台的现有业务和未来管理类的业务特点,一般会采用标题1、标题2和标题4三种结合的形式,来分别解决功能权限,数据权限,和审批流程的权限。

 

本文由 @阿白 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 可不可以这样,角色用来管理数据、功能权限;而岗位用来管理审批流,这样角色和岗位分开是不是更清晰

    来自广东 回复
    1. 角色管理数据权限灵活性太差,建议角色管理功能权限,节点和用户管理数据权限,岗位可以管理审批流。

      来自北京 回复
    2. 请问这个节点和用户管理数据权限,具体是怎么样呢,数据权限是不是就是默认我管理的组织范围下的数据

      来自广东 回复
  2. 实用干货,学到了

    来自广东 回复
  3. 不错的文章,点个赞,加你微信,还请通过一下

    来自河北 回复
  4. 大佬请教下,我们有这样的业务场景
    用户A在部门1 是角色a,可以看到1部门1所有数据,在部门2 是角色b,可以看到部门2自己的数据,部门1和部门2是平级部门
    用户B在部门1是角色c,但是他需要负责部门2345产生的数据的下一步处理
    请问这种情况怎么处理~~

    来自浙江 回复
    1. 关于A的问题,系统支持用户属于多个组织架构就可以,数据权限跟着组织价格,用户A挂在1和2两个部门(组织架构)下面,1部门分配部门所有数据权限,2部门分仅限自己的数据权限。
      关于用户B,可以通过数据权限中的场景5分享数据权限功能,把2345的数据权限分配给用户B。

      来自北京 回复
  5. 大佬能加个微吗,请教下问题

    来自四川 回复
  6. 请问总结中提到的标题6是指哪一点?

    来自上海 回复
    1. 勘误,应当是标题4,抱歉。

      来自北京 回复
  7. 请教个问题:租户的用户是否需要设计状态?租户到期之后再续费,续费账号数和之前不一致,这种场景怎么处理?

    回复
    1. 1、租户下的用户肯定是要有状态,租户自己也可以调整用户能不能登录系统。
      2、关于续费的账号数问题,可以设定租户超级管理员账号可用,指定角色(系统管理员角色)账号可用,指定数量老账号可用,或仅限超级管理员可用,超级管理员再启用可用的账号。各有优缺点,根据自己业务需要定一个规则就行。

      来自北京 回复
  8. 有个问题想请教下,一个关于RBAC模型的问题 RBAC模型是根据“角色”去判断权限的 但实际业务场景有不同用户是同一“角色” 但是不同权限点的情况 如果用创建多个“角色”来解决的话 觉得不太灵活 想到了改变这个模型 把权限直接和“用户”挂钩 而不是“角色” 但这个模型就变了 会不会用户更难理解

    来自北京 回复
    1. 确实会存在要建多个角色的情况,你说的这种是最简单的用户和权限挂钩的实现方式,如果用户不多的情况下可以这么做。但如果同权限的用户多的话,就要重复配置权限,倒不如用角色来的简单。

      来自北京 回复
    2. 是不是可以在加一个角色的数据权限就可以了

      来自安徽 回复
    3. 那基本上就是角色同时管理功能权限和数据权限了。

      来自北京 回复
  9. 请教一个问题,给到租户的是一个总账号,然后通过总账号去管理一个租户系统,通过子账号角色去隔离功能。那开发者公司的管理总后台发放租户总账号,是租户总账号的更上一层的账号吗(或者说开发者公司的管理后台和租户的系统平台其实也是账号角色去隔离功能的?)还是租户系统和开发者公司管理后台是两套独立的,通过接口关联的呢

    来自浙江 回复
    1. 你说的这是两种实现方式,一种是租户的上层账号,这种维护的平台少,相对简单。另外一种是单独做一套内部使用的系统,通过接口关联,可拓展性强。

      来自北京 回复
  10. 感谢分享,受益了

    来自浙江 回复
    1. 相互学习哈。

      来自北京 回复
  11. 学到了,看似负责难懂的东西,跟着流程走,用对方法,会提高很多效率

    来自湖北 回复
    1. 大家相互学习哈。

      来自北京 回复