总结:SAAS后台权限设计案例分析

数据分析如何避免沦为形式?15天在线学习get一套可落地的数据分析方法,了解一下 >>

saas平台由于其本身“按需购买”的特性,在设计规划权限时,需要考虑统一配置权限如何规避企业没有购买的应用,以及如有部分应用存在数据权限不同的问题。现在,本文简单总结一下当前saas模式下权限的几种设计方式。

作为一个B端平台型产品,系统的权限设计是其中一个非常重要的组成部分,没有权限管理的系统仿佛一个没有门的房子,任何人都可以随意查看甚至调整,对系统的安全性存在非常大的隐患,而saas模式下由于应用基本独立,随时可能被企业拆分使用。

这里权限的统一与拆分问题也十分重要,本文简单总结一下当前saas模式下权限的几种设计方式。

一、权限管理的重要性

权限管理一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源,权限管理基本是任何一个系统的标配模块。它的作用不仅在于保护系统数据安全性、防止留下系统漏洞,更能在庞大的系统下进行模块和数据配置,让不同的角色进入系统看到不同的模块和数据,最大程度地提高系统的易用性。

大部分系统中权限管理是作为一个独立的管理入口,统一设置所有的业务的权限。而saas平台由于其本身“按需购买”的特性,在设计规划权限时,需要考虑统一配置权限如何规避企业没有购买的应用,以及如有部分应用存在数据权限不同的问题。

二、抽象权限组成

权限到底是名词属性还是动词属性,还是名词、动词属性均包含,这对于权限的含义很重要。如果是名词属性的话,那么它应该是有具体的指代物;如果是动词,则应该具有行为表示。

  • 权限的名词属性:api接口、页面、功能点。
  • 权限的动词属性:可操作、不可操作。

那么我们现在来看,其实权限是名词、动词属性,它一定是表达了两层含义。即控制的对象、操作。

向上引申可将权限划分为3个组成部分:

  1. 页面权限:用户可以看到那些页面;
  2. 操作权限:用户可以在页面内进行那些操作,增删改查等;
  3. 数据权限:用户可以看到那些数据或内容;

三、常见的权限控制模型

(1)自主访问控制(DAC:Discretionary Access Control)

系统会识别用户,然后根据被操作对象(object)的权限控制列表(ACL:Access Control List)或者权限控制矩阵(ACL:Access Control Matrix)的信息来决定用户的是否能对其进行哪些操作,例如读取或修改。而拥有对象权限的用户,又可以将该对象的权限分配给其他用户,所以称之为“自主(Discretionary)”控制。

DAC最大缺陷就是所有用户的权限不能统一管理,用户和用户的权限比较分散,后期调整只能单个进行调整,不易维护。

(2)强制访问控制(MAC:Mandatory Access Control)

在MAC的设计中,每一个对象都都有一些权限标识,每个用户同样也会有一些权限标识,而用户能否对该对象进行操作取决于双方的权限标识的关系,这个限制判断通常是由系统硬性限制且无法回避的。强制访问控制多应用于对安全性要求比较高的系统,如多级安全军事系统;

(3)基于角色的访问控制(RBAC:Role-Based Access Control)

RBAC是我们当前使用范围最广的一种权限设计模型,模型基础就是用户和角色,角色和权限做多对多的对应。标准的RBAC模型包括四个部件模型,分别为基本模型RABC0、角色分级模型RABC1、角色限制模型RABC2、统一模型RABC3。

  1. RBAC0(基本模型)定义了完全支持RBAC概念的任何系统的最低需求。RBAC0的模型中包括用户(U)、角色(R)和许可权(P)等3类实体集合,RABC0是权限管理的核心部分,其他的版本都是建立在0的基础上。
  2. RBAC1(角色分级模型)基于RBAC0模型,引入角色间的继承关系,即角色上有了上下级的区别,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。这种模型合适于角色之间的层次明确,包含明确。
  3. RBAC2(角色限制模型)引入了角色间的约束关系,主要约束规则包括:角色间的互斥关系,在处理用户和这些角色之间的关系时,包括静态分离和动态分离,静态分离指互斥的角色不能同时赋予同一个用户;动态分离指用户不能同时操作两个互斥的角色进行登录。
  4. RBAC3(统一模型)同时包含了1和2的特性。

如图所示,每个用户关联一个或多个角色,每个角色关联一个或多个权限,从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建,这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。

简单来说RBAC就是:用户关联角色,角色关联权限。并且在产品和数据设计层面,有更好的扩展性,可控制到任意的粒度。

(4)基于属性的权限验证(ABAC:Attribute-Based Access Control)

ABAC则是通过动态计算一个或一组属性,来是否满足某种条件来进行授权判断(可以编写简单的逻辑)。属性通常来说分为四类:用户属性(如用户年龄),环境属性(如当前时间),操作属性(如读取)和对象属性(如一篇文章,又称资源属性),所以理论上能够实现非常灵活的权限控制,几乎能满足所有类型的需求。该设计过于复杂,暂未参透。

四、基于RBAC权限模型的SAAS平台权限系统设计

对于SAAS平台这样庞大复杂的平台来说,权限系统设计得越全面、精细、后期的系统扩展性就越高,所以这里采用RBAC权限模型,RBAC权限模型是现有比在这方面比较成熟的权限设计模型,应用这个模型能解决常规的系统权限配置问题,其基本原理也能适用于平台权限设计。

RBAC对权限抽象概括:判断【Who是否可以对What进行How的访问操作(Operator)】

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

  1. 最小权限原则之所以被RBAC所支持,是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。
  2. 责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现,比如要求一个计帐员和财务管理员共参与同一过帐
  3. 数据抽象可以通过权限的抽象来体现,如财务操作用借款、存款等抽象权限,而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

——来自百度百科

以某物业公司内部信息平台为例,该物业公司平台分为客户档案、房产档案、收费系统、客服工单等多应用结构,其中物业公司组织架构为多层级,基本样式如下如。

组织架构

应用入口

功能页面

以上我们可以将:

  • 组织架构=数据权限
  • 应用入口以及应用菜单=页面权限
  • 功能操作点=操作权限

1. 基本模型:RBAC0

抽取角色,建立角色与用户的关系。

这里的角色主要是指在组织内承担特定的业务活动,并和别的业务角色进行交互的业务角色。业务角色的抽取主要有两种方式:一种是直接和岗位对应,另外一种是根据流程的本质和需要定义角色。

确定各角色的用例图,如下图(简单示例):

根据业务复杂度、用户特点进行原型草图设计,在进行权限分配时,可以从增加角色维度以及增加用户维度。如下图:

新建角色维度

新建用户维度

使用此模型时,我们需要注意的问题有:

  1. 用户和角色为多对一的关系,如果需要用到多对多的关系,将涉及到角色关系的处理,此模型并不适用。
  2. 权限一定是动态可配置的,不是静态的,这点一定要在着手开发前进行说明,一般情况,权限的数据结构为树形,合理的数据结构,便于前端根据实际需求进行解析;
  3. 人员在选择角色获取到对应的权限数据后,最好可以提供一个二次编辑界面,权限会更加灵活。

2. 角色分级模型:RBAC1

RBAC1基于RBAC0模型,引入角色间的继承关系,即角色上有了上下级的区别,角色分级模型适用于平台业务功能较多,单个角色设置操作过于繁琐,引用角色分级,可让角色之间存在继承或被继承的关系,比如客服主管可直拥有下级所有员工拥有的权限。

建立角色管理,确定角色跟用户之间的关系。(要求角色间有明显的层级关系,所以在没有其他需求的情况下,这里根据业务部门和岗位进行角色的抽取)

建立角色层级关系和继承关系。

角色层级关系

一般继承关系

受限继承关系

给角色赋予权限(应用入口权限——应用页面权限、应用页面中操作功能权限、数据查看权限。)权限赋予同RBAC0。

增加一个角色管理。如下图:

通过角色管理即可以将下级角色的权限直接赋值给上级权限,但由于低级角色的权限全部被高级角色继承,就会导致没有自己角色的私有权限;也可以为人员提供一个二次编辑权限界面,但是一旦编辑后,若后续所属角色权限发生变化,会直接覆盖原有编辑后的权限。

3. 角色限制模型:RBAC2

RBAC2,它是RBAC的约束模型,RBAC2也是建立的RBAC0的基础之上的,在RBAC0基础上假如了约束的概念,主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

SSD是用户和角色的指派阶段加入的,主要是对用户和角色有如下约束:

  1. 互斥角色:同一个用户在两个互斥角色中只能选择一个;
  2. 基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的;
  3. 先决条件约束:用户想要获得高级角色,首先必须拥有低级角色。

DSD是会话和角色之间的约束,可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。

角色权限配置界面可参照RBAC0。

用户在配置角色或角色下新建添加用户时,需要根据用户已有的角色身份进行判断。示例:用户A配置角色为客服组长,则可继续添加角色为客服主管,若客服主管已被分配给他人,则也不能分配给用户A(遵从最大拥有数原则)。若同时将保安主管分派至用户A,则操作时,需要选择操作角色。

当一个用户配置了多个角色身份时,权限取并集。

4. 统一模型:RBAC3

统一模型是包括了继承和分离两种情况的更为复杂的模型,即既要定义角色间的的继承关系,也要维护好角色间的责任分离关系。

在这里就不做过多的赘述(两张图供大家参考),因为只要维护好了角色间的约束关系,其他规则类的处理方式同RABC1和RABC2。

角色管理

权限配置

五、总结

1. 角色数据权限

  1. 不同的角色身份查看的角色数据时不相同的,比如物业分公司中深圳区域分公司的管理人员可能就无法管理长沙区域分公司,在给角色分配数据权限时就可以将长沙区域分公司去除。
  2. 除数据权限外,我们还会遇到字段权限,比如:分公司C和分公司D都能看到上海区域分公司的客户情况,但是C看不到客户联系方式,D则能看到联系方式。如果有需要对字段权限进行控制,则可以在设置角色的数据权限或者功能权限时,进行控制。
  3. 题前有提到针对saas模式,可能存在一个角色在管理A跟B应用时可操作的数据权限时不一样的,可以在数据权限中增加一个高级设置权限,为不同的角色针对不用的应用进行分配数据操作。

2. 用户操作体验

平台类或者TO B内部产品,虽然不像C端为了留住用户追求极致用户体验,但是也需要确保在交互以及文字理解上面不会让用户产生疑惑情绪,培训成本也是开发成本的一环,尤其针对权限一块可能涉及业务功能复杂,如果在文字描述以及操作上在加大操作难度,可能无法估量的后果。

3. 默认账号以及默认权限的设置

对于ToB类或者平台类的产品,正常来讲都会有一个默认的超级管理员的角色以及角色对应的账号,否则系统内第一个角色谁来添加?

默认权限的设置则根据需要进行设置,如果是不必要进行控制的权限,当然是可以设置为默认权限的。

综上所述,根据以上的设计模式以及解决方案,已经能实现大部分企业90%的问题了,实际上很多企业并不需要做到这么小粒度的权限控制。

 

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 如果深圳分部的人需要去管理长沙分部的人,就是说这种权限需要可配置的,那应该如何设计呢?

    回复
  2. 好文章

    回复
  3. 笔者能否留一下邮箱地址,我有很困惑的权限设计问题想请教你一下,感恩🙃

    回复
    1. 可以关注我的公众号“百里狗”,留言沟通哦

      回复
  4. 检查任务和检查项设置,我目前也在做这一块的方面,没琢磨透,可否交流下 :|

    回复
  5. 既然是B端,用模块的代替应用是否更好?
    权限分级:系统权限,模块权限,功能权限,数据权限
    除系统权限外,按照架构分级:总部、分部、部门
    后面的……太多了,写不完了

    回复
    1. saas类产品是存在一个平台服务多个企业,后期还可扩展接入企业已有其他应用,且saas下的每个应用都是可单独出来在有基础数据的支撑下独立运行的,模块之间会存在耦合性,应用就是为了减少耦合使之可以独立运行。组织架构分级也是属于数据权限的一部分。

      回复
    2. 分级分权管理啊
      应用这个说法用在移动端,WEb端用模块,比如你的saas系统里面提供了一个简单的日程管理,你叫日程管理应用不太合适吧?
      模块化没任何毛病啊….这样可以解决不用企业的个性化需求,权限分级分权,满足saas提供者和企业用户的权限使用需求

      回复
    3. 模块跟应用的界限在我看来是很模糊的,千人有千面,我定义模块是无法达到完成闭环的,但是应用可以,但是你说的类似日程管理这种基础服务类又确实用模块来命名比价合适,现在很多saas模式的平台比如钉钉在后台管理里面也是添加应用而不是添加模块这种说法。

      回复
    4. 这样说吧,既然是一个平台,那么基于平台基本功能点进行的功能设计就是归属平台的功能模块
      模块和应用概念之间的差距,模块归属于平台,应用植入平台

      回复
    5. 也不能说他们有很明确的界限,主要看一个系统的主次之分吧,重PC还是重移动,重PC,模块化(功能集合),功能在移动端的展现形式则为应用。
      重移动端,则全部称为应用也没有任何问题

      回复
    6. 钉钉的初衷就是做移动办公,移动端用应用这个定义没有任何毛病,钉钉的后端是为了和前台匹配对应,所有用了应用
      如果你的saas是移动端为主,PC端为辅助, 没任何问题,如果以PC端为主,移动端为辅,叫应用就有点怪怪的了!

      回复
    7. 其实换个角度也没有必要模块和应用限定的那么死板。我也不认为你说移动端叫应用就一定没毛病,假设移动端提供的功能就是pc版同样的,我叫它模块也没啥问题。不管是pc为主还是移动为主这个概念在我的理解中都不存在问题。如果是在saas的平台中应用的存在从场景上更多是应用市场,第三方可扩展的内容。模块可以认为是saas平台本身提供什么功能模块。这些可能是基础的功能也可以叫应用。

      回复
    8. 没毛病

      回复
    9. 名字随便叫,只要大家都接受,随便叫模块、应用、功能,都OK!
      移动端不可能提供和PC端同样的内容,原因是他们的功能架构不可能一样
      移动端可以采用页面+功能入口、菜单的方式来呈现,PC端基本都是菜单,不可能说同一个系统里面做应用放到同一个页面中吧?当然可以尝试这么干….. :lol:

      回复
  6. 个人认为,无论是功能权限,页面权限,还是数据权限,归根结底都是 api 得访问权限,即节点权限

    回复
  7. 感谢分享这篇文章。就我目前所知的权限体系中,以及在做的产品权限是RBAC0这一类型的。其他的几种我还真不知道,感谢。

    回复
    1. ;-)

      回复
  8. 按开发成本来算,感觉角色权限变成操作权限,就没有必要弄成角色层级关系了,按用户分配业务权限,不同角色搭配不同的业务权限;
    如:财务总监:注册基本权限+稽查权限(对订单管理可进行增+删+改+查)
    会计:注册基本权限+审核权限(对订单管理可进行查)

    回复
    1. 角色层级可用于继承或者约束关系,RBAC0就是不存在角色层级关系,可以根据业务自身需要进行调整

      回复
    2. 不做层级,你会很纠结的,你的权限会特别多!
      比如人事的:部门HR,分部HR,总部HR,对于人事的操作权限局限于部门、分部、总部
      财务也分总部财务和分部财务
      不做权限分级,做起来会特别麻烦!

      回复