权限系统设计(1)：MAC+DAC+RBAC
Author：zhoulujun Date：
自主访问控制（DAC: Discretionary Access Control）
自主访问控制中，产品中的操作对象被设置了权限等级。
在用户登陆时，系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。
而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。
DAC最常见的应用就是文件系统的权限设计，如微软的NTFS。
Windows中的文档系统的权限设计就是“自主访问控制”模型的典型应用。
DAC最大缺陷就是对权限控制比较分散，不便于管理，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。
比如windows，也没有linux权限中的 用户组概念。
强制访问控制（MAC: Mandatory Access Control）
MAC是为了弥补DAC权限控制过于分散的问题而诞生的。
MAC设计中所有的访问控制策略都由系统管理员来制定，用户无法改变。
在MAC的设计中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。
比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。
MAC一般会给用户和资源进行分级，比如：
用户级别：高级，中级，普通
文件级别：绝密，保密，公开
由系统管理员会制定访问策略，比如高级用户可以访问所有类型的文件，中级用户可以访问保密级别以下的文件，而普通用户只能访问公开的文件。
一般强制访问控制采用以下几种方法：
限制访问控制
一个持洛伊木马可以攻破任何形式的自主访问控制，由于自主控制方式允许用户程序来修改他拥有文件的存取控制表，因而为非法者带来可乘之机。
MAC不提供这一方便，在这类系统中，用户要修改存取控制表的唯一途径是请求一个特权系统调用。该调用的功能是依据用户终端输入的信息，而不是靠另一个程序提供的信息来修改存取控制信息。
过程控制
在通常的计算机系统中，只要系统允许用户自己编程，就没办法杜绝木马。但可以对其过程采取某些措施，这种方法称为过程控制。
例如，警告用户不要运行系统目录以外的任何程序。提醒用户注意，如果偶然调用一个其它目录的文件时，不要做任何动作，等等。需要说明的一点是，这些限制取决于用户本身执行与否。
系统限制
对系统的功能实施一些限制。
比如，限制共享文件，但共享文件是计算机系统的优点，所以是不可能加以完全限制的。再者，就是限制用户编程。不过这种做法只适用于某些专用系统。在大型的，通用系统中，编程能力是不可能去除的。
MAC适用在对保密性要求比较高的系统中，比如军方机构。商业系统中使用MAC的有SE Linux和Trusted Solaris。而对于大部分的商业服务型系统来说，略显死死板不够灵活。
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/
权限系统设计一： DAC、MAC、RBAC、ABAC模型 https://blog.csdn.net/weixin_42058609/article/details/101030808
转载本站文章《权限系统设计(1)：MAC+DAC+RBAC》,
请注明出处：https://www.zhoulujun.cn/html/Operation/PM/2020_0505_8406.html