权限模型
权限模型是计算机安全领域中用于控制用户或系统对资源访问的一种机制。
基于角色的访问控制
基于角色的访问控制（RBAC, Role-Based Access Control）是一种广泛使用的访问控制机制，它通过将权限与角色关联，并将角色分配给用户来简化权限管理。
核心概念
- 用户（User）：
- 系统中的个体，可以是个人、程序或设备。
- 用户被分配一个或多个角色。
- 角色（Role）：
- 角色是一组权限的集合，代表用户在系统中的职责或职能。
- 角色可以根据组织的结构和职能来定义。
- 权限（Permission）：
- 权限是对特定资源的具体操作许可，如读取、写入、执行等。
- 权限通常与角色关联，而不是直接与用户关联。
- 会话（Session）：
- 用户与系统交互的活跃时期。
- 在会话中，用户可以激活一个或多个角色来访问系统资源。
基本模型
RBAC 的标准模型由NIST（美国国家标准与技术研究院）提出，分为四个层次：RBAC0、RBAC1、RBAC2 和 RBAC3。每个层次都建立在前一个层次之上，并增加了额外的功能或约束条件。
RBAC0：核心模型
RBAC0 是RBAC的基础，定义了用户、角色和权限之间的基本关系。
- 用户（User）：请求访问资源的实体。
- 角色（Role）：定义了一组权限的集合，通常与用户的职责或职能相关。
- 权限（Permission）：允许或拒绝执行特定操作的能力。
- 用户-角色分配（User-Role Assignment）：用户可以分配一个或多个角色。
- 角色-权限分配（Role-Permission Assignment）：角色可以分配一个或多个权限。
在RBAC0中，有以下基本关系：
- 用户与角色之间是多对多的关系。
- 角色与权限之间也是多对多的关系。
RBAC1：层次模型
RBAC1 在RBAC0的基础上增加了角色的层次结构。这意味着可以定义一些更高级别的角色，它们可以继承低级别角色的所有权限，同时还可以拥有自己的独特权限。
- 角色层次（Role Hierarchy）：允许角色之间有继承关系，形成一棵角色树。
- 高级角色（Senior Role）：可以继承其下所有子角色的权限。
- 低级角色（Junior Role）：其权限可以被上级角色继承。
角色层次使得权限管理更加灵活和高效，因为权限可以一次性分配给高级角色，从而自动授予所有下级角色。如果有角色A是角色B的父角色，则角色B自动获得角色A的所有权限。
这种机制简化了权限管理，因为不需要为每个子角色重复指定相同的权限。
RBAC2：约束模型
RBAC2 引入了约束的概念，对角色分配和权限管理施加额外的限制。
- 互斥角色（Mutually Exclusive Roles）：用户不能同时拥有互斥的角色。例如，一个人不能既是财务审批员又是财务请求者。
- 基数约束（Cardinality Constraints）：限制角色可以分配给多少用户，或者用户可以拥有多少角色。比如，可能只允许一个用户担任CEO的角色。
- 先决条件约束（Precedence Constraints）: 在某些情况下，只有当用户已经获得了另一个角色后，才能被分配到某个角色。例如，必须首先成为部门经理，然后才能晋升为区域经理。
- 静态职责分离（Static Separation of Duty, SSD）：定义了用户可以同时拥有的角色集合的限制。
- 动态职责分离（Dynamic Separation of Duty, DSD）：定义了用户在会话中可以激活的角色集合的限制。
约束确保了访问控制策略的完整性和安全性。
RBAC3：统一模型
RBAC3 是RBAC的完整模型，结合了前面所有模型的特点，提供了一个完整的、灵活的访问控制框架。它既支持角色层次，也支持各种约束条件，从而能够适应更复杂的安全需求和组织结构。
RBAC3 = RBAC0 + RBAC1 + RBAC2：
- 包含了RBAC0中的用户-角色-权限的基本映射。
- 支持RBAC1中的角色层次结构。
- 实现了RBAC2中的多种约束机制。
基于属性的访问控制
基于属性的访问控制（Attribute-Based Access Control, ABAC）是一种灵活且细粒度的访问控制方法，它允许根据主体（用户）、客体（资源）、环境条件以及操作本身的多种属性来决定是否授予访问权限。ABAC模型能够提供比RBAC更加精细和动态的访问控制策略。
核心概念
- 属性（Attributes）：
- 用户属性：与用户相关的信息，如职位、部门、角色、安全许可等。
- 资源属性：与资源相关的信息，如资源的类型、敏感度级别、创建日期等。
- 环境属性：与访问请求发生时的环境相关的信息，如时间、地点、网络状态等。
- 策略（Policies）：
- 策略是一组规则，用于定义访问控制决策的逻辑。策略通常由策略管理员配置，它们将属性与允许或拒绝访问的决策相结合。
- 策略决策点（Policy Decision Point, PDP）：
- PDP是ABAC体系结构中的核心组件，负责根据策略评估访问请求并做出决策。
- 策略执行点（Policy Enforcement Point, PEP）：
- PEP是系统中的一个组件，它拦截访问请求，向PDP查询决策，并根据PDP的响应允许或拒绝访问。
工作流程
1. 访问请求
- 用户尝试访问资源：当用户尝试访问某个资源时，例如打开一个文件、执行一个操作或调用一个API，这个请求会被PEP（Policy Enforcement Point，策略执行点）拦截。
- 收集相关信息：PEP负责收集与该访问请求相关的所有必要信息。这些信息包括但不限于：
- 用户属性：用户的标识信息（如用户名）、角色、职位、部门、认证状态等。
- 资源属性：请求访问的资源类型、敏感级别、创建者、所属项目等。
- 环境属性：当前的时间、日期、地理位置、网络状况等。
2. 策略评估
- 发送属性到PDP：PEP将收集到的所有属性信息打包成一个请求，并发送给PDP（Policy Decision Point，策略决策点）。
- 策略匹配：PDP接收到请求后，会根据预定义的安全策略进行评估。这些策略可能包含一系列规则，每个规则都定义了在特定条件下哪些属性组合是被允许或禁止的。
- 规则解析：PDP解析并理解每个策略规则，这可能涉及到复杂的逻辑表达式。
- 条件检查：PDP检查所有相关属性是否满足策略规则中的条件。例如，如果策略规定“仅允许公司内部员工在工作时间访问”，则PDP需要验证用户的“员工”属性以及当前的“时间”属性。
- 决策生成：一旦所有条件都被检查完毕，PDP会生成一个最终的决策结果，通常是“允许”或“拒绝”。
3. 决策执行
- 返回决策结果：PDP将最终的决策结果返回给PEP。
- 执行决策：PEP根据PDP的决策来决定如何处理用户的访问请求。
- 允许访问：如果PDP的决策是“允许”，PEP会放行请求，让用户能够访问资源。
- 拒绝访问：如果PDP的决策是“拒绝”，PEP会阻止请求，通常会向用户显示一个错误消息或重定向到一个合适的页面。
- 记录日志：无论决策结果如何，系统通常会记录这次访问尝试的日志，以便后续审计和监控。
示例
假设有一个公司内部的应用程序，其中包含一些敏感的数据报告。公司希望只允许市场部的全职员工在工作时间内访问这些报告。
- 用户属性: 用户名（user001），角色（员工），部门（市场部），雇佣类型（全职）
- 资源属性: 报告ID（report123），敏感级别（高）
- 环境属性: 当前时间（上午10点），日期（工作日）
策略规则:
- 只有市场部的全职员工可以在工作时间（上午9点至下午5点）访问高敏感级别的报告。
工作流程:
- 用户user001尝试访问report123。
- PEP拦截请求并收集上述属性。
- PEP将这些属性发送给PDP。
- PDP根据策略规则评估这些属性：
- 用户属于市场部且为全职员工。
- 当前时间为上午10点，在工作时间内。
- 报告的敏感级别为高。
- 所有条件均满足，PDP返回“允许”的决策。
- PEP根据PDP的决策，允许用户访问报告。
优缺点
优点：
- 灵活性：能够根据多种属性和条件灵活定义访问控制策略。
- 细粒度控制：提供非常详细的访问控制，能够针对具体的情况制定规则。
- 可扩展性：随着组织的发展，可以轻松添加新的属性和策略。
- 简化管理：减少了直接管理权限的数量，并且可以集中管理策略。
缺点：
- 复杂性：策略的设计和管理相对复杂，需要深入理解和持续维护。
- 性能：可能会影响系统的性能，特别是在处理大量属性和高并发的情况下。
- 策略配置：需要专业知识来正确配置策略，否则可能导致安全风险或不必要的限制。
