中间控制
组：访问权限的管理依靠单个主体是相当麻烦的， 因此通常将用户置于组中，并也可以从用户组取得访问权限
理想状况，所有的访问许可可以通过组成员关系来居中调停通常，安全策略有一些特殊的场合，在这些场合中直接给某些主体访问一个客体的许可， 或者否认一个主体从它的组成员关系中获得的许可是较为方便的
否定的许可（negative permission）就是访问控制结构中的一个表项，它规定了一个主体不允许执行的访问操作
基于角色的访问控制（Role-based access control，RBAC）
主要关注用户和用户执行的任务上
中间控制
主体和客体之间的中间层有助于减少访问控制管理的复杂性。中间层可以被插到多个位置上，这样就可以使用多个层次来构造访问控制。在主体和客体之间，可插入的中间层次有：
角色：一个角色就是一组过程，角色被分配给用户。一个用户可以有多个角色，多个用户也可以有相同的角色。
过程：过程是语义比读或写更复杂的高层访问控制方法。过程只能被应用于某些数据类型的客体上
数据类型：每个客体均属于一种特定的数据类型，只能通过为该数据类型定义的过程来访问。通过限制可以访问客体的过程来控制对客体访问。
保护环
保护环用于说明主体和客体之间中间层。主体和客体均依照“重要性”被赋予一个数字。
RBAC
将访问权限分配给角色，用户通过被指派为角色从而获得角色所拥有的访问权限
RBAC模型是各类基于角色的访问控制模型的基础，由四个子模型组成：
- RBAC0基本模型
- RBAC1层次模型
- RBAC2约束模型
- RBAC3统一模型
RBAC0 基本模型
五个基本数据元素：用户，角色，客体，操作，许可
用户：一个可以独立访问计算机系统中的数据或者用数据表示的其他资源的主体
角色：一个组织或人物中的工作或者位置，代表了一种权利，资格和责任
许可（特权）：允许对一个或多个客体执行的操作
一个用户可经授权而拥有多个角色，一个角色可由多个用户构成。
每个角色可拥有多个许可，每个许可可授权给不同的橘色
每个操作可是驾驭多个个体
会话：一个会话构成一个用户到多个角色的映射，即会话激活了用户授权角色集的某个子集，这个子集成为活跃角色集。活跃角色集决定了本次会话的许可集。
RBAC1 层次模型
角色层次提供了一种反映组织中角色层次结构的方式。
- 下级角色画在下面。两个角色之间的连线表示上面角色包含下面角色的所有访问权及下面角色不具有的其它访问权
- 一个角色可以从多个下级角色继承访问权
- 多个角色也可以继承同一个下 级角色
继承关系可以分为：
- 一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承
- 受限继承关系则进一步要求角色继承关系是一个树结构，要求角色间单继承
RBAC2 约束模型
约束在如下方面规定了所应遵循的强制性规则：
- 权限被赋予角色时
- 角色被赋予用户时
- 当用户在某一时刻激活一个角色时
约束是在角色之间定义的关系或与角色相关的条件
- 约束主要有如下类型：互斥角色、基数和先决条件
互斥角色支持一个组织中职责和能力的分离。指一个用户只能被分配给角色集合中的一个角色
- 静态角色互斥：只有当一个角色与用户所属的其他角色彼此不互斥时，这个角色才能授权给该用户
- 动态角色互斥：只有当一个角色与用户的任何一个当前活跃角色都不互斥时，该角色才能成为该用户的另一个活跃角色
基数：在一个特定的时间段内，有一些角色只能由一定人数的用户占用。基数就是设置关于角色的最大数值。
先决条件：用户在分配某个角色之前，必须先拥有另一个或一组先决条件角色。
先决条件可以用来构建最小特权概念的实现
RBAC3 统一模型
RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种约束
RBAC模型的优点
- 支持最小权限原则、责任分离原则。这些原则是任何组织的管理工作都需要的。这就使得RBAC模型 有广泛的应用前景
- 支持数据抽象原则和继承概念。由于目前主流程序设计语言都支持面向对象技术，RBAC的这一特性 ，便于在实际系统中应用实现
- 模型中概念与实际系统紧密对应。RBAC模型中的角色、用户和许可权等概念都是实际系统实际存在的实体，便于设计者建立现存的或待建系统的RBAC模型
RBAC模型的缺点
- 本质是对访问矩阵模型的扩充，能够很好的解决系统中主体对客体的访问控制、访问权力的分配与控制问题，但模型没有提供信息流控制机制，不能完全满足信息系统的全部安全需求
- 没有提供操作顺序控制机制。很难应用于要求有严格操作次序的实体系统，例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走
- 其他问题：如是否允许一个正在会话的用户再创建一个新会话，管理模型不支持用户和许可权的增加 与删除等管理工作
基于任务的访问控制（Task-based access control， TBAC）
-
从应用的角度来解决安全问题，是基于主动式安全模型，以面向任务的观点来建立安全模型和实现安全机制，在任务处理的过程中提供动态实时的安全管理
-
将访问权限与任务相结合,每个任务的执行都被看作是主体使用相关访问权限访问客体的过程
模型组成
- 工作流：为了完成某一目标而由多个相关任务（活动）构成的业务流程
- 授权结构体：是任务在计算机中进行控制的一个实例。任务中的子任务，对应于授权结构体中的授权步
- 一般授权结构体内的授权步依次执行
- 原子授权结构体内部的每个授权步紧密联系，其中任何 一个授权步失败都会导致整个结构体失败
- 授权步：表示一个原始授权处理步，是指在一个工作流程中对处理对象的一次处理过程。授权步是访问控制所能控制的最小单元，由受托人集(trustee-set)和多个许可集(permissions set)组成
- 受托人集：是可被授予执行授权步的用户的集合
- 许可集：是受托人集的成员被授予授权步时拥有的访问许可
- 任务：任务(Task)是一个可区分的动作，可能与多个用户相关，也可能包括几个子任务。一个工作流的业务流程由多个任务构成。而一个任务对应于一个授权结构体，每个授权结构体由特定的授权步组成
- 依赖：指授权步之间或授权结构体之间的相互关系，包括顺序依赖、失败依赖、分权依赖和代理依赖。依赖反映了基于任务的访问控制的原则
授权用五元组（S，O，P，L，AS）来表示，S、O、P 分别表示主体、客体和许可，L表示生命期(lifecycle)，AS表示授权步。P是授权步AS所激活的权限，L则是授权步AS的存活期限
授权步不是静态的，而是随着处理的进行动态地改 变内部状态
- 睡眠状态(Dromant)：授权步还未生成
- 激活状态(Invoked)：授权步被请求激活，此时授权步已经生成
- 有效状态(Valid)：授权步开始执行，随着权限的使用，它的保护态发生变化
- 挂起状态(Hold)：授权步被管理员或因执行条件不足而强制处于挂起状态，它可以被恢复成有效状态，也可能因生命周期用完或被管理员强制为无效状态
- 无效状态(Invalid)：授权步已经没有存在的必要，可以在任务流程中删除
授权步的生命期、许可的次数限制和授权步的自我动态管理，三者形成了TBAC的动态授权
TBAC支持两个著名的安全控制原则：
- 最小特权原则。在执行任务时只给用户分配所需的权限，未执行任务或任务终止后用户不再拥有所分配的权限；而且在执行任务过程中，当某一权限不再使用时，授权步自动将该权限回收
- 职责分离原则。有时，一些敏感的任务需要不同的用户执行，如支票处理流程中准备支票和提交支票的职员必须不同。这可通过授权步之间的分权依赖实现
总结
在TBAC中，对象的访问权限控制不是静止不变的，而是随着执行任务的上下文环境发生变化
在工作流环境中，数据的处理与上一次的处理相关联，相应的访问控制也如此，因而TBAC是一种上下文相关的访问控制模型
TBAC不仅能对不同工作流实行不同的访问控制策略，而且还能对同一工作流的不同任务实例实行不同的访问控制策略
TBAC是基于任务的，这也表明，TBAC是一种基于实例（instance-based）的访问控制模型
TBAC非常适合分布式计算和多点访问控制的信息处理控制以及在工作流、分布式处理和事务管理系统中的决策制定
基于任务和角色的访问控制T-RBAC
T-RBAC模型把任务和角色置于同等重要的地位，任务是RBAC 和TBAC能结合的基础
- 先将访问权限分配给任务，再将任务分配给角色，角色通过任务与权限关联，任务是角色和权限交换信息的桥梁
T-RBAC模型中，任务具有权限，角色只有在执行任务时才具有权限, 当角色不执行任务时不具有权限
- 权限的分配和回收是动态进行的，任务根据流程动态到达角色，权限随之赋予角色，当任务完成时，角色的权限也随之收回；角色在工作流中不需要赋予权限
这样, 不仅使角色的操作、维护和任务的管理变得简单方便, 也使得系统变得更为安全
基于对象的访问控制(Object-based Access Control Model，OBAC)
当用户数量多、处理的信息数据量巨大时，用户权 限的管理任务将变得十分繁重，并且用户权限难以 维护，这就降低了系统的安全性和可靠性
对于海量的数据和差异较大的数据类型，需要用专 门的系统和专门的人员加以处理，要是采用RBAC 模型的话，安全管理员除了维护用户和角色的关联关系外，还需要将庞大的信息资源访问权限赋予有限个角色
控制策略和控制规则是OBAC访问控制的核心所在
