CISSP 域5知识点访问控制模型

无趣胜有趣

920人浏览 · 2026-04-15 15:12:48

无趣胜有趣 · 2026-04-15 15:12:48 发布

🔐 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 动态属性
参考监视器三特性：必须调用 / 不可旁路 / 可被验证