权限系统设计(0):权限系统设计基本概念改需-MAC/RBAC引子
此篇主要对权限系统设计所涉的一些专业术语重点梳理。从我们windows的文件系统 自主访问控制 到基于角色访问控制。
权限设计基本术语
对后面会用到的词汇做一个简要说明
什么是权限(许可)
权限(Privilege/Permission)是指为了保证职责的有效履行,任职者必须具备的,对某事项进行决策的范围和程度。它常常用“具有批准……事项的权限”来进行表达。例如,具有批准预算外5000元以内的礼品费支出的权限。
在计算机系统中,权限是指某个特定的用户具有特定的系统资源使用权力。而在我们做的后台管理系统,资源指的是系统中所有的内容,包括模块、菜单、页面、字段、操作功能(增删改查)等等。大致可以将权限分为:
-
功能级权限管理,在操作系统中的任何动作、交互都是功能权限,如增删改查等。
-
数据级权限管理。一般业务管理系统,都有数据私密性的要求:哪些人可以看到哪些数据,不可以看到哪些数据。
从控制方向来看,也可以将权限管理分为两大类:
-
从系统获取数据,比如查询订单、查询客户资料
-
向系统提交数据,比如删除订单、修改客户资料
权限管理
权限管理,一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源。
权限管理几乎出现在任何系统里面,只要有用户和密码的系统。 很多人常将“用户身份认证”、“密码加密”、“系统管理”等概念与权限管理概念混淆。
功能权限管理技术,一般就使用基于角色访问控制技术RBAC(Role Based Access Control)。该技术被广泛运用于各个系统。
权限控制表 (ACL: Access Control List)
用来描述权限规则或用户和权限之间关系的数据表。
权限标识
权限的代号,例如用“ARTICLE_ADD”来指代“添加文章的操作”权限。如linux文件浅析 rwx代表读写执行权限。
角色
角色是一定数量的许可的集合,许可的载体,一个角色可以包含多个用户,一个用户同样的也可以属于多个角色,所以角色与用户的关系为多对多的关系。同样的一个角色可以包含多个用户组,一个用户组也可以属于多个角色,所以角色和用户组也是多对多的关系;
一个用户一个角色:用户/角色/权限关系总结
-
个用户有一个角色
-
一个角色有多个操作(菜单)权限
-
一个操作权限可以属于多个角色
在实际的团体业务中,都可以将用户分类。比如对于薪水管理系统,通常按照级别分类:经理、高级工程师、中级工程师、初级工程师。也就是按照一定的角色分类,通常具有同一角色的用户具有相同的权限。这样改变之后,就可以将针对用户赋权转换为针对角色赋权。
我们可以用下图中的数据库设计模型,描述这样的关系。
一个用户一个或多个角色:用户/角色/权限关系总结
但是在实际的应用系统中,一个用户一个角色远远满足不了需求。如果我们希望一个用户既担任销售角色、又暂时担任副总角色。该怎么做呢?为了增加系统设计的适用性,我们通常设计:
-
一个用户有一个或多个角色
-
一个角色包含多个用户
-
一个角色有多种权限
-
一个权限属于多个角色
我们可以用下图中的数据库设计模型,描述这样的关系。
用户组
当平台用户基数增大,角色类型增多时,如果直接给用户配角色,管理员的工作量就会很大。如果有一类的用户都要属于某个角色,我们一个个给用户授予角色,重复工作特别多,所以我们把这么一些用户进行分类,这时候我们可以引入一个概念“用户组”,就是将相同属性的用户归类到一起。也就是用户组,这样的话,我们直接对用户组赋予角色,减少重复的工作量。
例如:加入用户组的概念后,可以将部门看做一个用户组,再给这个部门直接赋予角色(1万员工部门可能就几十个),使部门拥有部门权限,这样这个部门的所有用户都有了部门权限,而不需要为每一个用户再单独指定角色,极大的减少了分配权限的工作量。
同时,也可以为特定的用户指定角色,这样用户除了拥有所属用户组的所有权限外,还拥有自身特定的权限。
用户组的优点,除了减少工作量,还有更便于理解、增加多级管理关系等。如:我们在进行组织机构配置的时候,除了加入部门,还可以加入科室、岗位等层级,来为用户组内部成员的权限进行等级111111上的区分。
关于用户组的详细疑难解答,请查看https://wen.woshipm.com/question/detail/88fues.html。在这里也十分感谢为我解答疑惑的朋友们!
常见设计模式
自主访问控制(DAC: Discretionary Access Control)
系统会识别用户,然后根据被操作对象(Subject)的权限控制列表(ACL: Access Control List)或者权限控制矩阵(ACL: Access Control Matrix)的信息来决定用户的是否能对其进行哪些操作,例如读取或修改。
而拥有对象权限的用户,又可以将该对象的权限分配给其他用户,所以称之为“自主(Discretionary)”控制。
这种设计最常见的应用就是文件系统的权限设计,如微软的NTFS。
DAC最大缺陷就是对权限控制比较分散,不便于管理,比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。
强制访问控制(MAC: Mandatory Access Control)
MAC是为了弥补DAC权限控制过于分散的问题而诞生的。
在MAC的设计中,每一个对象都都有一些权限标识,每个用户同样也会有一些权限标识,而用户能否对该对象进行操作取决于双方的权限标识的关系,这个限制判断通常是由系统硬性限制的。比如在影视作品中我们经常能看到特工在查询机密文件时,屏幕提示需要“无法访问,需要一级安全许可”,这个例子中,文件上就有“一级安全许可”的权限标识,而用户并不具有。
MAC非常适合机密机构或者其他等级观念强烈的行业,但对于类似商业服务系统,则因为不够灵活而不能适用。
因为DAC和MAC的诸多限制,于是诞生了RBAC,并且成为了迄今为止最为普及的权限设计模型。
RBAC是什么?
RBAC,Role-based access control,基于角色的访问控制,通过角色关联用户,角色关联权限的方式间接赋予用户权限。
是资讯安全领域中,一种较新且广为使用的访问控制机制,其不同于强制访问控制以及自由选定访问控制直接赋予使用者权限,而是将权限赋予角色。
1996年,莱威·桑度(Ravi Sandhu)等人在前人的理论基础上,提出以角色为基础的访问控制模型,故该模型又被称为RBAC96。之后,美国国家标准局重新定义了以角色为基础的访问控制模型,并将之纳为一种标准,称之为NIST RBAC。
RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作,也就是“主体”对“客体”的操作,其中who——是权限的拥有者或主体(如:User、Role),what——是资源或对象(Resource、Class)
为什么选择RBAC进行权限控制
通常一个系统会存在不同权限的用户,而根据业务要求的不同,每个用户能使用的功能、查看的内容是不同的。举个最简单的例子:钉钉后台,普通员工和行政能看到的菜单、使用的功能是不同的,行政可以查看所有员工的出勤记录而普通员工则不行。
其实是可以直接给用户分配权限,只是直接给用户分配权限,少了一层关系,扩展性弱了许多,适合那些用户数量、角色类型少的平台。
对于通常的系统,比如:存在多个用户拥有相同的权限,在分配的时候就要分别为这几个用户指定相同的权限,修改时也要为这几个用户的权限进行一一修改。有了角色后,我们只需要为该角色制定好权限后,将相同权限的用户都指定为同一个角色即可,便于权限管理。
对于批量的用户权限调整,只需调整用户关联的角色权限,无需对每一个用户都进行权限调整,既大幅提升权限调整的效率,又降低了漏调权限的概率。
RBAC定义
在一个组织中,会因为不同的作业功能产生不同的角色,执行某项操作的权限会被赋予特定的角色。组织成员或者工作人员(抑或其它系统用户)则被赋予不同的角色,这些用户通过被赋予角色来取得执行某项计算机系统功能的权限。
-
S = 主体 = 一名使用者或自动代理人
-
R = 角色 = 被定义为一个授权等级的工作职位或职称
-
P = 权限 = 一种存取资源的方式
-
SE = 会期 = S,R或P之间的映射关系
-
SA = 主体指派
-
PA = 权限指派
-
RH = 角色阶层。能被表示为:≥(x ≥ y 代表 x 继承 y 的权限)
-
一个主体可对应多个角色。
-
一个角色可对应多个主体。
-
一个角色可拥有多个权限。
-
一种权限可被分配给许多个角色。
-
一个角色可以有专属于自己的权限。
所以,用集合论的符号:
-
PA⊆P×R 是一个多对多的权限分配方式。
-
SA⊆S×R 是一个多对多的主体指派方式。
-
RH⊆R×R
参考文章:
RBAC模型:基于用户-角色-权限控制的一些思考 www.woshipm.com/pd/1150093.html/comment-page-1
RBAC权限模型——项目实战 https://blog.csdn.net/zwk626542417/article/details/46726491
权限系统设计模型分析(DAC,MAC,RBAC,ABAC) https://www.jianshu.com/p/ce0944b4a903
图文详解基于角色的权限控制模型RBAC https://www.bbsmax.com/A/kvJ3Yl8Ddg/
转载本站文章《权限系统设计(0):权限系统设计基本概念改需-MAC/RBAC引子》,
请注明出处:https://www.zhoulujun.cn/html/Operation/PM/2020_0505_8401.html