访问控制：实现数据保密性与完整性机制的主要手段，主要为了限制访问主体对访问客体的访问权限。

自主访问控制DAC： 

1.主体对所属对象和运行的程序拥有全部的控制权；

2.用户A执行的程序拥有与A相同的权限。

3. 权限可传递访问矩阵，能力表的方式存储用户权限。

数据库中：主体理论上拥有对其创建的数据库、数据表的所有（最高）权限。

Grant Revoke==》 授权管理：{ 集中式管理： 主体授权客体，只有主体可以执行授权

  { 分散式管理： 主体授权给客体，客体可以继续执行授权操作（传递授权）

  { 受限分散式管理： 主体可以授权给管辖范围中的下属，授权路径稳定，便于追责

强制访问控制MAC：

(1)MAC中，管理员管理访问控制，制定策略，用户无法改变。策略定义主体对对象的访问规则。

(2)"need to know basis"的工作机制，用户只能访问工作所需的对象（特权最少），主体不能写或创建低于自己级别的标记的对象（不能向下写），防止主体将秘密与低级别主体共享。

        数据库（系统）使用事先确定的安全策略，对用户访问权限进行强制性控制。数据库（系统）独立于用户行为强制执行访问控制，普通用户无法改变他们的安全级别或对象的安全属性。

==》小栗子：

        此时教务处科长发布文件A，假设C_A = (秘密，{教务处})，此时只有校长和教务处主任可以查看此文件，因为校长与教务处主任的秘密级>=文件的秘密级 且 文件A的范畴domain是校长与教务处主任domain的子集。此时教务处level未达到秘密的员工与其他部门的处主任均无法查看文件A。

MAC相比DAC访问控制的粒度更细，安全性更高，强制访问控制和自主访问控制常结合使用。

基于角色的访问控制RBAC：(Role-Based Access Control)

用户<==>角色<==>权限

用户层面抽象出“角色”属性间接被赋予权限，用户通过成为适当角色得到这些权限（用户与权限的解耦），简化了权限的管理。

• 基本模型RBAC0 ： 用户、角色与权限多对多关系，用户权限等于他所有的角色持有的权限之和。
• 角色分层模型RBAC1： 角色引入“继承”概念，可以分为多个等级。角色等级权限不同，等级越高权限越高。例如处长与副处长，副处长只有处长的部分权限。

• 角色限制模型RBAC2。RBAC0上增加限制，限制分为静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

SSD：一个人不能既管销售又管财务（互斥），部分单位升职需要“步步高升”。

• 统一模型RBAC3，RBAC3 = RBAC1+RBAC2，当系统对权限要求十分复杂时才使用。
• 基于RBAC的延展——用户组。根据实际需求可以对RBAC模型进行拓展，如增加用户组概念，直接给用户组分配角色（权限），这样在添加新用户到用户组中时，新用户同时也拥有了所属用户组的所有权限。

基于属性的访问控制ABAC：(Attribute-Based Access Control)有时也被称为PBAC和CBAC。

动态计算一个或一组属性是否满足某条件（或者rule）来进行授权判断。

        属性通常来说分为四类：用户属性（如年龄）,环境属性（如时间）,操作属性（如读取）和对象属性（文件）。

特点：集中化管理；可以按需实现不同颗粒度的权限控制；不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中；定义权限时，不能直观看出用户和对象间的关系；规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦；权限判断需要实时执行，规则过多会导致性能问题。

        在复杂场景下，RBAC产生了许多虚无的role并且更难进行管理与控制，不同的病人有不同的nurse，这些nurse的访问资料权限与其他权限均不相同。除此之外，假如公司在员工回家后不想让员工看到财务数据，但是在公司这些数据的开放的，这样的动态需求假如使用RBAC就会需要虚拟的role与大量的动态控制。

（滥用权限：“role explosion”）

        典型的 ABAC 场景描述如下图，当 subject 需要去读取某一条记录时，我们的访问控制机制在请求发起后遍开始运作，该机制需要计算，来自 policy 中记录的规则，subject 的 attribute，object 的 attribute 以及 environment conditions，而最后会产生一个是否允许读取的结果：

1. 尝试访问
2. ACM(访问控制机制)进行计算：subject attributes + object attributes + environment conditions = allow or deny?
3. 执行/拒绝访问

ABAC为什么能解决复杂场景下的问题：（相比RBAC思维前进了一点）

· Attribute易于管理。

·细粒度的授权支持。Policy十分灵活，甚至可以引入正则表达式等，实现“让徐姓工程师在A项目中访问B资源“。

·访问控制管理成本很低。当Policy经常变化时，RBAC可能需要创建虚拟role，而ABAC只需修改Policy即可。

·动态的整体控制。Environment conditions提供统一的系统级别控制，依靠威胁等级或区域等信息划分安全级别。

 BLP模型

        是对安全策略形式化的第一个数学模型，是一个状态机模型，用状态变量表示系统的安全状态，用状态转换规则来描述系统的变化过程。  多级安全策略模型，给出了军事安全策略的数学描述。

        BLP模型是一个很安全的模型，既有自主访问控制，又有强制访问控制。控制信息只能由低向高流动，能满足军事部门等一类对数据保密性要求特别高的机构的需求。

BLP模型“过于安全”。（下读上写）,体现于：

①上级对下级发文受到限制；

②部门之间信息的横向流动被禁止；

③缺乏灵活、安全的授权机制。

不安全的地方：

①低安全级的信息向高安全级流动，可能破坏高安全客体中数据完整性，被病毒和黑客利用。

②只要信息由低向高流动即合法（高读低），不管工作是否有需求，这不符合最小特权原则。

③高级别的信息大多是由低级别的信息通过组装而成的，要解决推理控制的问题。

BLP完善、增强：

① 限制低安全级向上写（高密）；

② 限定主体read的能力，不允许对所有低密级的读操作；

③ 低密级读低密级数据时，应保障低密级不能更改低密级的数据；

④允许根据data的情况动态调节安全级别

具体可见《访问控制》课件第四章----访问控制与安全模型。

附录（一些术语）

Attribute：属性，用于表示 subject、object 或者 environment conditions的特点，attribute 使用 key-value 的形式来存储这些信息，我在公司的 role 是 developer，role 是key，developer 是 value，而我的小组昵称袋熊，key 是 team，value 是 wombat。

Subject：常常指代使用系统的人或者其他使用者（non-person entity，NPE），比如说客户端程序，访问 API 的client 或者移动设备等等。当然一个 subject 可以有多个的 attributes，就像用户属性这些我们曾经用过的名词一样。

Object：指代我们这个 ACM 需要管理的资源，比如文件，比如某项记录，比如某台机器或者某个网站，任何你需要进行访问控制的资源都可以称为object，同样 object 也可以有多项属性，比如袋熊组的桌子，或者洛克组的线上实例，我们也常常使用 resource来描述这些资源，但是在 ABAC 的环境下，我们称为 object。

Operation：有了 object 有了 subject，自然就有了 subject需要做的事情，比如查看某条记录，登录某台服务器，使用某个 SaaS服务进行报销或者查看候选人的作业。往往包括我们常说的读、写、修改、拷贝等等，一般 operation 是会表达在 request 中的，比如HTTP method。

Policy：通过 subject、object 的 attribute 与 environment conditions 一起来判断subject 的请求是否能够允许的关系表示，比如说：policy可以用人类语言这样表达，只有袋熊组的人才能访问这几台服务器，或者只有在办公室才能访问这些资源，但对于机器来说，无非就是一个判断语句罢了。当然了，policy可以是一堆这样 boolean 逻辑判断的组合，比如只有公司的正式员工、并且在公司的六楼区域的网络中，才能访问某个服务。你可以使用Specification Pattern 来实现 policy，其实没那么复杂。

Environment Conditions：表示目前进行的访问请求发生时的操作或情境的上下文。Environment conditions 常常用来描述环境特征，是独立于 subject 与 object的，常用来描述系统的情况：比如时间，当前的安全等级，生产环境还是测试环境等等。