🔐 CISSP 域5｜访问控制模型：底层理论全拆解
归属 ：Domain 5 身份与访问管理 × Domain 3 安全架构与工程
权重 ：占 Domain 5 的 35% 以上，概念题 + 规则匹配题 + 场景题高频必考
核心价值：所有访问控制体系的底层理论框架，是认证与授权的核心执行依据
🔴 六条考试红线（违反必错）
🔴 红线①：参考监视器三大特性不可突破------必须被全程调用 / 不可被旁路 / 可被独立验证
🔴 红线②：模型选择必须与安全目标精准匹配------保密性 → BLP/MAC，完整性 → Biba/Clark-Wilson，防利益冲突 → Chinese Wall，不可错位
🔴 红线③：最小特权 + 默认拒绝 + 职责分离，是所有模型的通用底层原则，无例外
🔴 红线④：高安全涉密场景必须使用 MAC 强制访问控制，禁止仅用 DAC 实现核心管控
🔴 红线⑤：所有访问行为全程可审计、日志不可篡改，满足合规要求
🔴 红线⑥：BLP 与 Biba 规则完全相反，绝对不能记反------这是最高频错题
📖 核心术语速查（11条）
🔹 访问控制模型：定义主体访问客体的规则、权限逻辑、安全边界的标准化框架
🔹 主体（Subject）：发起访问请求的主动实体------用户、设备、服务、进程、API 等
🔹 客体（Object）：被访问的被动资源------文件、数据库、应用、系统、API、数据字段等
🔹 安全标签（Security Label）：MAC 模型的核心，分配给主体/客体的固定密级属性（绝密/机密/秘密/公开），系统强制管控，用户无法修改
🔹 参考监视器（Reference Monitor）：拦截所有主体对客体的访问请求、执行权限校验的核心抽象机制，是所有访问控制模型的执行中枢
🔹 可信计算基（TCB）：系统中所有负责执行安全策略的硬件、软件、固件的总和，参考监视器是 TCB 的核心组件
🔹 安全内核（Security Kernel）：TCB 中实现参考监视器逻辑的核心组件，必须不可旁路、不可篡改
🔹 最小特权原则：仅授予主体完成工作必需的最小权限与最短生效时间
🔹 职责分离（SoD）：将高风险操作拆分给不同主体，禁止单个主体完成全流程
🔹 Need-to-Know（知其所需）：MAC 模型核心补充规则------哪怕安全等级足够，无业务需求也不能访问
🔹 ACL（访问控制列表）：DAC 模型的核心执行载体，由资源所有者自主配置
🏗️ 底层核心基础：参考监视器 / TCB / 安全内核
所有访问控制模型都依赖这三大底层组件，先理解它们，才能理解所有模型
🔐 参考监视器------访问控制的执行中枢
官方定义：拦截所有主体对客体的访问请求、执行权限校验的逻辑闸门
三大不可突破的核心特性（必考）：
- ✅ 必须被全程调用：每一次访问请求都必须经过参考监视器校验，没有例外
- ✅ 不可被旁路：校验逻辑不可被绕过、篡改、禁用，任何访问不能跳过权限校验
- ✅ 可被独立验证：设计足够精简，可被独立审计验证，确保逻辑无缺陷
💡 通俗理解：参考监视器就像大楼的安检闸机------每个人进出都必须刷证过闸，闸机不可被绕开，设计简单可靠可被验证
🔐 可信计算基（TCB）
- 包含参考监视器、安全内核、OS安全模块、硬件安全芯片、固件、ACL 等所有安全组件
- TCB 之外的组件视为不可信，不可绕过 TCB 执行访问控制
- TCB 存在安全缺陷 → 整个访问控制体系直接失效
🔐 安全内核
- TCB 中实现参考监视器逻辑的核心组件
- 必须实现参考监视器三大特性，且设计足够精简，可被全面审计
🗂️ 四大模型分类总览
OSG 第十版将所有访问控制模型分为四大类，选型前先判断类别
🔹 自主访问控制（DAC）：资源所有者自主管控权限，灵活性高，安全性最低
🔹 强制访问控制（MAC）：系统基于安全标签强制管控，安全性最高，灵活性最差
🔹 非自主访问控制（RBAC / ABAC / Rule-BAC）：企业主流应用，兼顾安全与效率
🔹 专项安全目标模型（BLP / Biba / Clark-Wilson / Chinese Wall）：针对特定安全需求设计
📋 模型一：自主访问控制（DAC）
官方定义：资源所有者有权自主决定将资源的访问权限分配给哪些主体，系统不强制干预权限分配
核心执行逻辑：
- 每个客体有明确所有者（通常是创建者）
- 所有者自主创建/修改/删除客体的 ACL（访问控制列表）
- 系统基于 ACL 校验主体的访问权限并执行规则
典型应用场景：Windows/Linux 文件权限、普通办公系统文档共享、个人文件管理
核心优劣：
- ✅ 灵活性高，配置简单，适配个性化权限需求，用户体验好
- ❌ 安全性最低，权限管控完全依赖所有者的安全意识，易过度授权
- ❌ 无法集中化管控，易权限蔓延，禁止单独用于涉密高安全场景
⚠️ 考试核心考点：
- DAC 核心特点：资源所有者自主分配权限，系统不强制干预
- ACL 是 DAC 的核心执行载体
- DAC 安全性最低，禁止单独用于涉密、高安全场景
- 易错点：DAC 中系统仅执行 ACL 规则，不会主动限制所有者的权限分配
📋 模型二：强制访问控制（MAC）
官方定义：系统基于预定义的安全标签，强制管控主体对客体的访问，用户/所有者无法修改安全标签与访问规则，是安全性最高的访问控制模型
核心执行逻辑：
- 系统为每个主体分配固定的安全许可标签（Clearance）------绝密/机密/秘密/公开
- 系统为每个客体分配固定的安全分类标签（Classification）
- 系统基于预定义的强制规则，自动校验标签匹配关系，决定是否允许访问
- 任何用户/所有者都无法修改安全标签或绕过规则，只有安全管理员可基于合规流程修改
典型应用场景：军方/政府涉密系统、关键信息基础设施、高安全等级金融核心系统
核心优劣：
- ✅ 安全性极高，系统强制管控，无法绕过
- ✅ 集中化管控，可实现严格的多级保密管控，满足保密法规
- ❌ 灵活性极差，配置复杂，运维成本极高
- ❌ 不适用于普通企业办公场景，用户体验差
⚠️ 考试核心考点：
- MAC 核心特点：系统强制管控，用户无法修改标签与规则，与 DAC 完全相反
- 安全标签是 MAC 的核心，分主体安全许可标签 + 客体安全分类标签
- MAC 是涉密场景的唯一合规模型
- 核心补充规则：Need-to-Know------哪怕安全等级足够，无业务需求也不能访问
- BLP 模型是 MAC 的典型代表
📋 模型三：非自主访问控制（企业主流，场景题核心）
企业最主流的访问控制体系，既解决了 DAC 安全性不足，也解决了 MAC 灵活性不足
🎯 RBAC------基于角色的访问控制
官方定义：将权限与角色绑定，主体通过归属角色获得权限，不直接给主体分配权限，实现"用户-角色-权限"解耦
核心执行逻辑：
- 基于岗位/部门/职责，预定义标准化角色（财务会计、系统管理员、普通员工等）
- 将完成该岗位必需的最小权限绑定到对应角色
- 给主体分配角色，主体通过角色继承权限
- 岗位变动时仅需调整角色归属，无需批量修改权限
OSG 官方定义的三大层级（必考）：
- 核心 RBAC：基础模型，包含用户/角色/权限/会话四大元素
- 层级 RBAC：增加角色的层级继承关系，上级角色可继承下级角色权限
- 受限 RBAC：增加职责分离规则，包括静态职责分离（不能同时归属互斥角色）和动态职责分离（同一会话中不能同时激活互斥角色）
典型应用场景：大中型企业内部系统、标准化岗位权限自动化分配、ERP/CRM等企业级系统
核心优劣：
- ✅ 标准化程度高，运维效率高，易实现职责分离与最小特权
- ✅ 当前最成熟的企业级访问控制模型
- ❌ 对动态、跨部门、非标准化场景灵活性不足
- ❌ 角色数量过多会导致"角色爆炸"，运维复杂度大幅提升
⚠️ 考试核心考点：
- 核心是权限与角色绑定，而非用户-权限直接绑定
- 三大层级是高频概念题考点
- RBAC 可轻松实现静态/动态职责分离
- 易错点：RBAC 基于岗位角色，而非用户属性，与 ABAC 有本质区别
🎯 Rule-BAC------基于规则的访问控制
官方定义：基于预定义的全局强制规则，决定是否允许主体的访问请求，规则对所有主体生效，通常与其他模型结合使用
典型规则示例：
- 仅允许 8:00-18:00 工作时间访问业务系统
- 禁止来自境外 IP 的管理员登录请求
- 仅允许公司内网网段访问核心数据库
- 未启用 MFA 的用户禁止访问敏感财务系统
典型应用场景：防火墙 ACL、网络访问控制、与 RBAC/ABAC 结合补充全局规则
⚠️ 考试核心考点：
- Rule-BAC 的核心是预定义全局强制规则，对所有主体生效
- Rule-BAC 通常作为其他模型的补充，而非单独使用
- ⚡ 易混淆 ：Rule-BAC（基于规则）与 RBAC（基于角色）是完全不同的模型，不可混淆
- 防火墙的 ACL 规则是 Rule-BAC 的典型应用
🎯 ABAC------基于属性的访问控制
官方定义 ：基于主体属性、资源属性、环境属性、操作属性四大维度，通过动态策略引擎决定是否允许访问，是零信任架构的核心访问控制模型，也是 OSG 第十版重点强化内容
四大属性维度：
- 主体属性：部门、岗位、角色、安全等级、认证等级、设备健康状态等
- 资源属性：资源的密级、分类、归属部门、业务类型、数据标签等
- 环境属性：访问时间、IP 地址、网络位置、当前风险评分、威胁情报等
- 操作属性：操作类型（读/写/删除/执行）、访问的 API 接口、数据操作范围等
核心执行逻辑：策略引擎实时拉取四大维度属性 → 匹配动态策略 → 实时决策是否允许访问 → 属性变化时可实时调整权限
典型应用场景：零信任架构、云原生、微服务、跨企业合作、大数据细粒度访问管控
核心优劣：
- ✅ 灵活性极高，可实现超精细化动态授权，完美适配零信任架构
- ✅ 无需预定义大量角色，解决 RBAC 的"角色爆炸"问题
- ❌ 配置复杂度高，前期策略设计难度大，运维成本高
- ❌ 对属性数据的完整性、实时性要求极高
⚠️ 考试核心考点：
- ABAC 核心是基于四大属性维度，动态策略引擎实时授权
- 是零信任架构的核心访问控制模型，第十版重点强化
- ABAC 是动态授权，RBAC 是静态角色绑定，二者有本质区别
- ABAC 可实现基于上下文的细粒度访问控制，适配复杂动态场景
📋 模型四：专项安全目标模型（规则匹配题必背）
⚠️ 这四个模型规则必须精准记住，绝对不能混淆
🏰 Bell-LaPadula 模型（BLP）
核心目标 ：🔒 保障数据保密性（Confidentiality）
MAC 模型的典型代表，军方涉密系统标准模型
三大核心规则（必考）：
-
📌 简单安全规则（不上读） ：主体只能读取安全等级等于或低于自身安全许可的客体
秘密级用户 → 可读秘密级/公开级，不能读机密级/绝密级
-
📌 星号属性规则（不下写） ：主体只能写入安全等级等于或高于自身安全许可的客体
机密级用户 → 可写机密级/绝密级，不能写秘密级/公开级（防止高密级数据泄露到低密级）
-
📌 强星规则：在满足前两条规则的基础上，通过 ACL 实现自主访问控制，两条规则同时满足才允许访问
核心特点：
- 仅关注保密性，完全不关注完整性
- 基于安全标签实现强制访问控制
- 核心补充：Need-to-Know------安全等级够用也不代表有权访问
⚠️ 考试考点：
- BLP 核心目标：保密性（区别 Biba 的完整性）
- 不上读、不下写，必须精准记住，不能和 Biba 记反
- BLP 不保障完整性
🏰 Biba 模型
核心目标 ：🔒 保障数据完整性（Integrity）
BLP 的镜像模型，规则与 BLP 完全相反
三大核心规则（必考，与 BLP 完全相反）：
-
📌 简单完整性规则（不下读） ：主体只能读取完整性等级等于或高于自身的客体
高完整性财务系统进程 → 不能读低完整性用户上传文件，防恶意代码注入
-
📌 星号完整性规则（不上写） ：主体只能写入完整性等级等于或低于自身的客体
普通用户（低完整性）→ 不能修改系统核心配置文件（高完整性）
-
📌 调用规则：主体只能调用完整性等级等于或低于自身的进程，禁止低完整性主体调用高完整性进程
核心特点：
- 仅关注完整性，完全不关注保密性
- 规则与 BLP 完全相反，是 BLP 的镜像模型
- 适配商业场景中防止数据被篡改的需求
⚠️ 考试考点：
- Biba 核心目标：完整性（区别 BLP 的保密性）
- 不下读、不上写，必须精准记住，不能和 BLP 记反
- Biba 不保障保密性
📊 BLP vs Biba 对照速记（最高频必考）
BLP（保密性）：
- 核心目标 → 保密性
- 读取规则 → 不上读（只读低于或等于自身等级）
- 写入规则 → 不下写（只写高于或等于自身等级）
Biba（完整性）：
- 核心目标 → 完整性
- 读取规则 → 不下读（只读高于或等于自身等级）
- 写入规则 → 不上写（只写低于或等于自身等级）
💡 记忆口诀：BLP 保密 → 往上读会泄密（不上读）；Biba 完整 → 往下读会污染（不下读）
🏰 Clark-Wilson 模型
核心目标 ：🔒 商业场景数据完整性 + 防范内部舞弊
Biba 模型的商业落地增强版，专为企业财务/交易等商业场景设计
四大核心术语（必考）：
- 🔹 CDI（受约束数据项）：需要保障完整性的核心商业数据（财务数据、交易记录、账户余额）
- 🔹 UDI（非约束数据项）：不受完整性管控的非核心数据（用户输入的原始数据、公开信息）
- 🔹 IVP（完整性验证程序）：验证 CDI 完整性是否符合商业规则的程序（如财务对账程序）
- 🔹 TP（转换程序） ：唯一可修改 CDI 的程序，通过标准化良构事务修改 CDI，禁止用户直接修改 CDI
五大核心规则（必考）：
- CDI 的修改必须通过 TP 执行，禁止用户直接修改
- 必须通过 IVP 定期验证 CDI 的完整性
- 必须实现职责分离------TP 开发者、使用者、IVP 验证者必须是不同的主体
- 所有 TP 操作必须写入审计日志，全程可追溯
- UDI 转入 CDI 必须经过 TP 校验，防止非结构化数据污染核心商业数据
⚠️ 考试考点：
- Clark-Wilson 核心：商业完整性 + 防舞弊 ，核心手段是良构事务 + 职责分离
- 核心术语 CDI / TP / IVP 是概念题必考
- 区别于 Biba：Biba 基于标签的系统级完整性，Clark-Wilson 基于事务与职责分离的商业完整性
- Clark-Wilson 是唯一强制要求职责分离的访问控制模型
🏰 Chinese Wall 模型（Brewer-Nash 模型）
核心目标 ：🔒 防范利益冲突（Conflict of Interest）
专为金融、咨询、法律等专业服务机构设计，防止同一主体访问存在利益冲突的竞争客户数据
核心执行逻辑：
- 将客户数据按行业/竞争关系划分为利益冲突类（COI）
- 同一 COI 中的互为竞争对手的客户数据，划分为不同数据集
- 主体一旦访问了某个 COI 中的一个客户数据集，就永久不能访问该 COI 中其他竞争对手的数据集
- 主体可自由访问不同 COI 的数据集，以及同一 COI 中已访问客户的数据集
典型示例：
咨询师访问了 A 银行项目数据 → 永久不能访问 B 银行、C 银行的项目数据
但可以访问制造业、零售业等其他 COI 的客户数据
核心特点：
- 是动态访问控制模型，权限随访问行为动态变化
- 专为专业服务机构设计，适配金融/咨询/法律场景合规要求
⚠️ 考试考点：
- Chinese Wall 核心：防范利益冲突，是唯一针对利益冲突设计的访问控制模型
- 核心是**利益冲突类（COI）**的划分
- 是动态模型，权限随访问行为变化，而非固定不变
- 易错点：Chinese Wall 的权限是动态变化的，不是固定分配
🔖 其他专项模型速记
Graham-Denning 模型：定义 8 个基础权限操作，解决权限安全分配与转移问题，是访问控制的基础理论模型
Harrison-Ruzzo-Ullman（HRU）模型：权限状态转换模型，定义权限创建/修改/删除的 6 个基础操作，是理论模型，考点较少
Take-Grant 模型：基于权限传递规则，管控权限的授予（Grant）与获取（Take）边界，防止权限无限制扩散
🎯 模型选型标准（场景题核心依据）
OSG 第十版明确：没有绝对最优的模型，只有最适配的模型
📌 按核心安全目标选：
- 保密性优先 → MAC / BLP
- 完整性优先 → Biba / Clark-Wilson
- 防利益冲突 → Chinese Wall
📌 按业务场景选：
- 标准化岗位 → RBAC
- 动态/云原生/零信任 → ABAC
- 普通办公 → DAC
- 涉密/军方 → MAC
📌 按合规要求选：
- 涉密/军方 → MAC 强制要求
- 金融/上市公司商业 → Clark-Wilson 优先
- 专业服务机构 → Chinese Wall 优先
📌 按运维成本选：
- 小型/简单场景 → DAC
- 大中型企业标准化 → RBAC
- 复杂动态场景 → ABAC
📌 按技术架构选：
- 云原生/零信任 → ABAC
- 传统本地架构 → RBAC
- 网络边界管控 → Rule-BAC
⚠️ 七大官方误区纠正（考试高频错题）
❌ 误区1：BLP 和 Biba 规则一样，可以通用
✅ 官方纠正 ：二者是完全镜像相反 的模型。BLP 核心是保密性，规则是「不上读、不下写」；Biba 核心是完整性，规则是「不下读、不上写」。绝对不能记反，这是最高频错题。
❌ 误区2：RBAC 和 Rule-BAC 是同一个模型，只是叫法不同
✅ 官方纠正 ：二者是完全不同的模型。RBAC 基于岗位角色 绑定权限；Rule-BAC 基于全局强制规则管控访问，核心逻辑、适用场景完全不同，不可混淆。
❌ 误区3：DAC 模型配置严格的 ACL，可以用于涉密高安全场景
✅ 官方纠正 ：DAC 安全性最低，权限完全依赖资源所有者的安全意识，无法集中化强制管控，官方明确禁止单独用于涉密/高安全场景，涉密场景必须使用 MAC 模型。
❌ 误区4：ABAC 可以完全替代 RBAC，所有企业都应该切换到 ABAC
✅ 官方纠正：二者各有适用场景，没有绝对优劣。RBAC 适配标准化岗位场景，运维成熟稳定；ABAC 适配动态复杂的零信任场景。二者可结合使用，绝大多数企业核心场景仍以 RBAC 为基础。
❌ 误区5：Clark-Wilson 和 Biba 都保障完整性，没有区别
✅ 官方纠正 ：二者核心目标都是完整性，但实现逻辑完全不同。Biba 基于完整性标签的强制管控 ，适配系统级完整性保障；Clark-Wilson 基于良构事务 + 职责分离，专为企业商业场景、防范内部舞弊设计，是 Biba 的商业落地增强版。
❌ 误区6：访问控制模型规则设计合理，可以绕过参考监视器执行
✅ 官方纠正 ：参考监视器的三大特性是不可突破的红线，所有模型的执行都必须经过参考监视器全程校验，不可被旁路，任何可被绕过的访问控制体系都是无效的。
❌ 误区7：Chinese Wall 模型的权限是固定的，分配后不会变化
✅ 官方纠正 ：Chinese Wall 是动态访问控制模型，主体的访问权限随访问行为动态变化------一旦访问某个 COI 的数据集，就自动失去该 COI 中其他竞争数据集的访问权限，而非固定不变。
🔗 跨域关联（8个域全覆盖）
- Domain 1 安全与风险管理：访问控制模型是风险缓解的核心落地措施，模型选择必须基于风险评估结果
- Domain 2 资产安全：资产分级分类直接决定模型选择与管控强度，数据密级/完整性要求是模型设计的核心依据
- Domain 3 安全架构与工程：参考监视器、TCB、安全内核是所有模型的底层基础，安全架构设计必须原生内置访问控制模型
- Domain 4 通信与网络安全：Rule-BAC 是防火墙 ACL 的核心理论基础，ABAC 是零信任网络架构的核心访问控制模型
- Domain 5 身份与访问管理：本知识点是 Domain 5 的核心理论框架，认证与授权的执行都必须基于适配的访问控制模型
- Domain 6 安全评估与测试：访问控制模型有效性验证、越权漏洞检测、策略合规审计是渗透测试的核心内容
- Domain 7 安全运营：权限审计、异常访问行为监控、权限生命周期管理是安全运营的核心日常工作
- Domain 8 软件开发安全：应用层访问控制模型设计、越权漏洞防护是 DevSecOps 的核心组成部分
📌 考前速记口诀
BLP 保密不上读不下写；Biba 完整不下读不上写
Clark-Wilson = 良构事务 + 职责分离 → 商业防舞弊
Chinese Wall = COI + 动态 → 防利益冲突
DAC 所有者自主；MAC 系统强制；RBAC 角色绑定；ABAC 动态属性
参考监视器三特性：必须调用 / 不可旁路 / 可被验证