SAAS后台权限设计案例分析

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的特性。

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