熟悉这四种权限管理模型,产品迭代才能心里有数
不管是2C产品经理还是2B产品经理,都要将权限管理法则烂熟于心。只有熟悉权限管理法则,才能更好地理解自己产品的架构,做到每次产品迭代都心里有数。
从本质来说,无论何种类型的权限管理模型都可以抽象出三个基本的要素——即:用户(user)、系统/应用(system/application)、策略(policy)。
策略决定了用户和不同功能应用之间如何交互。反过来,也就是说,无论设计何种权限管理的模型,都是基于这三个基本要素来展开。
本文聚焦于目前应用最广的RBAC模型,但在这里提出三个基本要素,主要是为了帮助大家更好的理解权限管理,不至于在众多权限模型中迷失。
不同的公司或软件提供商,设计了无数种控制用户访问功能或资源的方法。但无论哪种设计,都可归到四种经典权限模型里——自主访问控制(DAC,Discretionary Access Control)、强制访问控制 (MAC,Mandatory Access Control)、基于角色访问控制 (RBAC,Role-based Access Control) 和基于属性访问控制 (ABAC,Attribute-based Access Control).
(我觉得翻译不好,但也找不到更贴切的。本文下面内容均以英文首字母来代替:DAC,MAC,RBAC,ABAC)。
一、DAC,MAC
本文主要就RBAC展开分析该模型的使用场景,以及如何基于该模型设计出合适的权限管理体系。但从文章便于理解的完整性的角度来考虑,会对DAC,MAC和ABAC进行简要的介绍。
DAC:被操作对象,根据访问控制规则,来判断操作主体可对操作对象做哪些操作,比如只读或者是可写的权限。而自主的含义,则是拥有某种权限的用户,可以把权限赋予其他用户。
MAC:被操作对象及用户两方均有各自的权限标识,用户能否对对象进行操作,取决于权限标识的对照关系。这种模型多用于等级制度明显,信息访问安全性要求高的场景,比如军事。
ABAC和RBAC有很多相通的地方,而且相比较而言ABAC实际上更灵活,符合未来发展的方向。因此,我们分析完RBAC后,再回过头来看ABAC。
二、那么,什么是RBAC呢?
Role-based Access Control,基于角色的权限控制模型。
顾名思义,给用户定义角色,通过角色来控制权限。目前来说基于角色权限控制模型是应用较广的一个。特别是2B方向SAAS领域,应用尤其常见。
如上图示,用户拥有角色,且可拥有多个角色,而每个角色对应不同权限。
这样的好处是:不必为每一个用户去配置权限,拥有极大的灵活性和便利性。而当用户及权限的量级又大到另一个级别时,又引入了角色组和权限组概念,此处不做延伸,有兴趣的读者可以去搜些资料来看。
三、怎么利用RBAC模型来进行权限体系的设计?
我们已经知道什么是RBAC模型了,在分析怎么来根据此模型来设计权限体系之前,我们再把这个模型要素进行拆分一下。
首先是:用户、角色、权限。
而权限,具体到某个软件来说,实际上包含两个方面。一个是菜单权限,另一个是数据权限。
不同的行业会有不同的使用场景,用户角色权限模型也会有不同程度上的变化。但归到底层来说,还是离不开上面我画的这个图。
上面这个图是从官网看到的,销售自动化领域十分典型的用户权限管理设计。
接下来,我们来抽象一个场景或者说案例,来辅助我们理解整个权限管理设计的过程。假设A公司是个中大型的生产制造公司,公司有OA、HR、CRM、ERP一系列管理软件。公司员工以万计,不同人员职责不同,体现在管理软件上,就是会需要使用不同的功能来完成工作。
帐号管理
帐号是人和软件进行交互时的一个身份的转化。账号的背后,代表了这个操作的人。账号管理应该是所有需要和系统交互的人的统一管理,包含基础信息,比如:这个人的名字,性别、手机号、部门以及其他属性。
角色管理
角色管理,就是要从实际场景出发,比如:使用系统的企业或者团体,有哪几类使用的角色——也就是说,有哪几类人,是需要有不同的业务菜单和业务数据的。
说到底,角色管理,就是把这个角色对应的人平时工作需要的菜单、功能给划到一个组里。给这一个个的操作组定义不同的名称——即角色名称。
当然,这个角色管理除了规定了该角色的人平时可对哪些功能进行查看操作,还需规定这个角色,能看到哪些范围内的数据。也就是前面提到的,权限实际上包含的是菜单权限和数据权限两部分。
系统内功能控制的颗粒度越细,对使用者来说配置角色便越灵活,但对系统的设计者来说,系统的复杂度自然也会上升,成本也会增加。
因此,到底控制到哪一层级,就要视具体业务场景来定,比如:有些行业的系统,可能控制到一级菜单就可以(某些SAAS工具),但有些系统,不仅需要控制所有的子级菜单,每一个按钮操作,甚至还会需要控制到不同的字段(比如Salesforce的权限控制系统)。
不过,我们抽象出了基本的模型,根据实际业务再去发散,就不是最困难的事了。
四、看看ABAC,顺便畅想下未来的权限模式
至此,我们可以了解到:RBAC模型实际上能解决大部分的权限设计问题了。
那么,ABAC到底是什么呢?它存在的意义在哪里?关于未来的权限设计趋势,它能带给我们什么启发呢?
带着这些问题,我们先来看看到底什么是ABAC模型。
ABAC,Attribute-based Access Control. 基于属性的访问控制。而属性,总的来说有三类:用户属性、系统或应用被访问属性(数据和操作)、环境属性。
也就是说,系统根据一组或多组属性是否满足预设规则来动态的控制,谁可以访问哪些功能数据和操作。RBAC模型,其实可以看成是静态的、单组属性的ABAC模型。
用例子来理解这个模型就是:只有当用户角色为Admin,在工作时间内,且处在C栋大楼B实验室,才可以访问D文件。
实际上,ABAC是个可以以最细颗粒度来管理权限的模型。它可以让设计者,利用任何一个用户属性、环境属性,或者多个属性之间的交集、并集等来组合出动态的权限判断逻辑。
它是这么强大,既可以有效的帮助信息辨别能力差的用户过滤垃圾信息。也可以让商家用到营销广告填满你生活的每个角落却不自知。
但我一直坚信,科技绝对是让生活更美好。
五、总结一下
权限管理,可能是每个2B产品经理需要面对的问题。但无论C端还是B端的产品,了解权限管理的设计法则,让自己更好的理解产品的架构,让产品的每次迭代都心里有数。
本文由@2B产品七七 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unspalsh, 基于CC0协议。
您上文提到的数据权限是基于角色控制的,如果一个角色中多个功能的数据权限不同呢?那需要通过多个角色控制吗?这样不会让角色变得冗余吗?
基于abac的有展开吗?
菜鸟想问下:数据权限中的,查看本人及下属,查看部门等,系统是如何区分部门及上下属之间的关系的啊?这是怎么设计的啊
那就是涉及到OA这块的了。组织架构管理,员工管理,职位管理等。就把部门和部门之间,部门和人之间,人和人之间的关系建立起来了。
作者不知道还能不能收到我的回复,我觉得你 RBAC 中的例子里已经涉及到 ABAC 模型了。
看到后面了,你后面也说了,其实 RBAC 本身也是 ABAC 的一种 RBAC 的属性只有一个,那就是功能属性。
个人理解 不知道是否正确 ABAC和RBAC的不同点在于 RBAC是基于角色的纬度 为角色分配功能和功能下的权限范围 而ABAC是为每项功能分配相应可使用他的角色 这个可使用 包含时间 地点 权限范围的控制等纬度 这样可以实现吗
赞,这个角度考虑很特别。
我们公司支持这种模型
可以这样实现的,实际上我们公司就支持这么做的。但是有个问题,即使你我一样是一样的角色,因为角色中包含了你说的时间、地点、权限范围这些数据,导致我两的权限已经千差万别了。此时角色失去了它该有的价值。
有举例就完美了
占位
rbac最细致的权限维度是“功能权限”和“数据权限”,通过将这些权限聚合形成角色、岗位、功能等与账号绑定起来。ABAC中的例子:“只有当用户角色为Admin,在工作时间内,且处在C栋大楼B实验室,才可以访问D文件。”应该在系统中实现的时候,应该是“账户巨有admin角色,admin角色拥有‘访问’这一功能权限,以及‘D文件’这一数据权限,以及‘工作时间、C栋大楼B实验室’这一环境权限”。这样看,基础维度应该是,功能权限(操作),数据权限(操作对象),环境权限(操作发生环境),角色依然可以是权限聚合的产物。
是的,这样理解也可以的。但其实我觉得这几种模型,倒没有说是有绝对的分割线的。都是从用户、系统、规则三个基本要素展开的。使用的场景、用户使用的复杂度决定了具体需要利用哪种模型。因为模型一定是精简的,如果十分复杂,则说明不是最好的模型。你理解的很透彻。多多交流。
我也2b一起交流
哈哈好滴
你也是2B?我不是,我是toB….