访问控制模型
在项目中需要加入访问空值,于是对访问控制模型多了一些调研,介绍一些常见的访问控制模型.
访问控制模型三要素
- 主体（Subject) 指主动对其它实体施加动作的实体
- 客体 (Object) 是被动接受其他实体访问的实体
- 控制策略 (Policy) 为主体对客体的操作行为和约束条件
自主访问控制模型（DAC）
概念
自主访问控制模型（DAC，Discretionary Access Control）是根据自主访问控制策略建立的一种模型，允许合法用户以用户或用户组的身份访问策略规定的客体，同时阻止非授权用户访问客体。拥有客体权限的用户，可以将该客体的权限分配给其他用户。例如没有文件 File1 访问权限的用户可以从有访问权限的 B 用户那里得到访问权限。
DAC访问控制的实现
权限控制列表
访问控制列表 (ACL, Access Control List)，每一个客体都配有一个列表，这个列表记录了主体对客体进行何种操作。当系统试图访问客体时，先检查这个列表中是否有关于当前用户的访问权限。ACL 是一种面向资源的访问控制模型，它的机制是围绕资源展开的。
对于一个文件对象的 ACL：
- Alice: read,write
- Bob: read
表示 Alice 可以对该文件进行读写操作，Bob 只能读取。
权限控制矩阵
访问控制矩阵 (ACM,Access Control Matrix) 是通过矩阵形式描述主体和客体之间的权限分配关系。每个主体而言，都拥有对哪些客体的哪些访问权限；而对客体而言，又有哪些主体对他可以实施访问；
应用场景
DAC 常见于文件系统，LINUX，UNIX、WindowsNT 版本的操作系统都提供 DAC 的支持。在实现上，先对用户鉴权，然后根据控制列表决定用户能否访问资源。用户控制权限的修改通常由特权用户或者管理员组实现。
特点和缺点
特点
授权的实施主体（1、可以授权的主体；2、管理授权的客体；3、授权组）自主负责赋予和回收其他主体对客体资源的访问权限。DAC 模型一般采用访问控制矩阵和访问控制列表来存放不同主体的访问控制信息，从而达到对主体访问权限的限制目的。
缺点
- 主体的权限太大，无意间就可能泄露信息
- 不能防备特洛伊木马的攻击访问控制表
- 当用户数量多、管理数据量大时，ACL 就会很庞大。不易维护。
强制访问控制 MAC
强制访问控制模型 (MAC, Mandatory Access Control), 是为了弥补 DAC 权限控制过于分散的问题而诞生的。在计算机安全领域指一种由操作系统约束的访问控制，目标是限制主体或发起者访问或对对象或目标执行某种操作的能力。任何主体对任何对象的任何操作都将根据一组授权规则（也称策略）进行测试，决定操作是否允许。
- Subject 被赋予一定的安全级别
- Object 被赋予一定的安全级别
- Subject 能否访问 Object 由双方的关系安全级别决定，这个判断通常有系统硬性限制.
MAC 非常适合机密机构或者其他等级观念强烈的行业，过重强调保密性，管理不够灵活。在实现上，MAC 和 DAC 通常为每个用户赋予对客体的访问权限规则集，考虑到管理的方便，在这一过程中还经常将具有相同职能的用户聚为组，然后再为每个组分配许可权。
强制访问策略
强制访问控制系统根据主体和客体的敏感标记来决定访问模式，模式包括
- 不上读（NRU），主体不可读安全级别高于他的数据；
- 不下读（NRD），主体不可读安全级别低于他的数据
- 不上写（NWU），主体不可写安全级别高于他的数据。
- 不下写（NWD），主体不可写安全级别低于他的数据。
由于安全性，这种方式一直被军方所使用，下面讲述两种被广泛使用的强制访问控制安全模型
- BLP 模型：在 BLP 模型中，不上读，不下写，也就是不允许低安全等级的用户读取高安全等级的信息，不允许高敏感度的信息写入低敏感度的区域，禁止信息从高级别流向低级别，强制访问控制通过这种梯度的安全标签实现信息的单向流通
- Biba 模型：由于 BLP 模型存在不保护信息的完整性和可用性，不涉及访问控制等缺点，所以使用 Biba 模型作为一个补充，它针对的是信息的完整性保护，主要用于非军事领域，Biba 模型使用不下读，不上写的原则来保证数据的完整性，在实际的应用中主要是避免应用程序修改某些重要的系统程序或系统数据库，这样可以使资源的完整性得到保障。也就是写，只能读上级发给他的命令，不能读他的下级接收到什么命令
基于角色的访问控制(RBAC)
管理员定义一系列角色（roles）并把它们赋予主体。系统进程和普通用户可能有不同的角色。设置对象为某个类型，主体具有相应的角色就可以访问它。这样就把管理员从定义每个用户的许可权限的繁冗工作中解放出来。
基于角色的访问控制 (RBAC, Role Based Access Control) 在用户和权限之间引入了 “角色（Role）” 的概念，角色解耦了用户和权限之间的关系。
角色和组的主要区别：
- 组是用户的集合
- 角色是权限的集合
- 角色 / 权限之间的变化比组 / 用户关系之间的变化相对要慢得多，减小了授权管理的复杂性
基于角色的访问控制模型 RBAC，有时成为基于规则的基于角色的访问控制（Rule-Based Role-Based Access Control，RB-RBAC）。它包含了根据主体的属性和策略定义的规则动态地赋予主体角色的机制。例如，你是一个网络中的主体，你想访问另一个网络中的对象。这个网络在定义好了访问列表的路由器的另一端。路由器根据你的网络地址或协议，赋予你某个角色，这决定了你是否被授权访问。
发展历程
RBAC0
RBAC0 作为基础模型，只包含核心的三要素，用户，角色，权限。用户和角色可以是多对多的关系，权限和角色也是多对多的关系。
RBAC1
RBAC1 包括了 RBAC0 并且添加了角色继承。顾名思义，角色继承就是指角色可以继承于其他角色，在拥有其他角色权限的同时，自己还可以关联额外的权限。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。也就是角色之间存在上下级的关系，对应到实体设计中也就是角色实体的自身关联。
RBAC2
RBAC2 也包括 RBAC0 并且添加了约束。RBAC1 和 RBAC2 相互独立.
RBAC2 的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
互斥约束：包括互斥用户，互斥角色，互斥权限。同一个用户不能拥有相互排斥的角色，两个互斥角色不能分配一样的权限集，互斥的权限不能分配给同一个角色，在 session 中，同一个角色不能拥有互斥权限。
基数约束：一个角色被分配的用户数量受限，它指的是有多少用户能拥有这个角色。例如：一个角色专门为公司 CEO 创建的，那这个角色的数量是有限的。
先决条件角色：指要想获得较高的权限，要首先拥有低一级的权限。例如：先有副总经理权限，才能有总经理权限。
RBAC3
RBAC3 是一个全功能的 RBAC，RBAC3 合并了 RBAC0，RBAC1，RBAC2.
基于属性的访问控制 (ABAC)
基于属性的访问控制 (ABAC, Attribute Based Access Control) 通过动态计算一个或一组属性是否满足某种条件来进行授权判断。可以按需实现不同颗粒度的权限控制，但定义权限时不易看出用户和对象间的关系。如果规则复杂，容易给管理者带来维护和追查带来麻烦。
属性通常来说分为四类：
- 用户属性（如用户年龄)
- 环境属性（如当前时间）
- 操作属性（如读取)
- 对象属性（如一篇文章，又称资源属性）
指定基于属性的控制协议需要将主体,环境,客体的属性构建集合,通过关联控制策略形成响应结果.
跟 RBAC 相比，ABAC 对权限的控制粒度更细，如控制用户的访问速率。实际开发中可以结合 RBAC 角色管理的优点和 ABAC 的灵活性一起使用。
参考
[1] https://blog.csdn.net/fei33423/article/details/106588580