权限系统设计(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