CISP学习指南：访问控制

Created 2025-10-11 Updated 2025-10-27

CISP

一、访问控制概述
二、安全模型分类
三、Bell-LaPadula模型（BLP）
四、Biba模型
五、访问控制实现机制
六、Kerberos协议
七、访问控制实施步骤
八、访问控制策略
八、安全模型总结
九、总结

访问控制是信息安全的核心机制，通过限制对资源的访问来保护信息资产的机密性、完整性和可用性。

一、访问控制概述

1.1 访问控制的定义与作用

💡 CIA三要素

访问控制保护信息资产的机密性、完整性和可用性。详细内容请参考：CISP学习指南：信息安全CIA三要素

访问控制是信息安全的核心机制，通过限制对资源的访问来保护信息资产。

🔐 访问控制的作用

访问控制系统在信息系统中发挥着至关重要的作用，主要包括：

✅ 拒绝非法用户的非授权访问请求

防止未经授权的用户访问系统
阻止非法入侵
保护系统资源

✅ 在用户对系统资源提供最大限度共享的基础上，对用户的访问权进行管理

平衡共享与安全
根据需要授予权限
实现资源的有效利用

✅ 防止对信息的非授权篡改和滥用

保护数据完整性
防止权限滥用
确保操作合规性

❌ 错误理解：对经过身份鉴别后的合法用户提供所有服务

这是对访问控制作用的错误理解
即使是合法用户，也应根据权限提供服务
不能因为身份合法就提供所有访问权限

访问控制实例：教务系统

以学校教务系统为例：

graph TB A["教务系统"] B["教师"] C["学生"] D["教务管理员"] A --> B A --> C A --> D B --> B1["可以：录入成绩"] B --> B2["不可以：修改课程信息"] C --> C1["可以：查看自己的分数"] C --> C2["不可以：查看他人分数"] C --> C3["不可以：修改成绩"] D --> D1["可以：修改课程信息"] D --> D2["可以：管理选课信息"] D --> D3["不可以：直接修改成绩"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00

访问控制在教务系统中的作用：

用户类型	身份鉴别	授权访问	访问控制作用
教师	✅ 合法	录入成绩	✅ 允许授权操作
教师	✅ 合法	修改课程	❌ 拒绝非授权操作
学生	✅ 合法	查看自己分数	✅ 允许授权访问
学生	✅ 合法	查看他人分数	❌ 拒绝非授权访问
学生	✅ 合法	修改成绩	❌ 防止非授权篡改
教务管理员	✅ 合法	管理课程信息	✅ 允许授权管理
非法用户	❌ 非法	任何访问	❌ 拒绝所有访问

关键理解：

身份鉴别 ≠ 全部权限
- 身份鉴别只是确认“你是谁”
- 访问控制决定“你能做什么”
- 合法用户也需要权限管理
最小权限原则
- 用户只能访问完成工作所需的资源
- 不因为是合法用户就给予所有权限
- 每个用户的权限根据角色确定
共享与安全的平衡
- 允许合理的资源共享
- 但必须在安全的框架内
- 通过访问控制实现平衡

1.2 主体和客体

访问控制模型将实体划分为主体和客体两类，通过对主体身份的识别来限制其对客体的访问权限。

💡 主体、客体和访问权限的核心概念

关键理解：

✅ 主体的特征

对文件进行操作的用户是一种主体
主体是主动发起访问的实体
用户对文件进行操作是主动行为

✅ 主体与客体的交互

主体可以接受客体的信息和数据（读取）
主体也可能改变客体相关的信息（修改）
具体操作取决于访问权限

✅ 访问权限的定义

访问权限是指主体对客体所允许的操作
如：读、写、执行、删除等
是访问控制的核心概念

主体和客体的定义：

graph LR A["主体
Subject"] B["访问权限
Permission"] C["客体
Object"] A -->|"1. 请求访问"| B B -->|"2. 检查权限"| B B -->|"3. 允许/拒绝"| C A --> A1["用户"] A --> A2["进程"] A --> A3["程序"] C --> C1["文件"] C --> C2["目录"] C --> C3["数据库"] B --> B1["读"] B --> B2["写"] B --> B3["执行"] style A fill:#e3f2fd,stroke:#1976d2 style B fill:#fff3e0,stroke:#f57c00 style C fill:#e8f5e9,stroke:#388e3c

主体、客体和访问权限的关系：

概念	定义	示例	特点
主体	主动发起访问的实体	用户、进程、程序	主动性
客体	被访问的资源	文件、目录、数据库	被动性
访问权限	主体对客体允许的操作	读、写、执行	操作类型

常见的主体类型：

主体类型：
├── 用户（User）
│   ├── 人类用户
│   ├── 系统用户
│   └── 服务账户
├── 进程（Process）
│   ├── 用户进程
│   └── 系统进程
├── 程序（Program）
│   ├── 应用程序
│   └── 系统程序
└── 设备（Device）
    ├── 网络设备
    └── 外设

常见的客体类型：

客体类型：
├── 文件（File）
│   ├── 普通文件
│   ├── 配置文件
│   └── 日志文件
├── 目录（Directory）
│   ├── 文件夹
│   └── 目录树
├── 数据库（Database）
│   ├── 表
│   ├── 视图
│   └── 存储过程
├── 网络资源（Network Resource）
│   ├── 网络共享
│   └── 网络服务
└── 设备（Device）
    ├── 打印机
    └── 存储设备

访问权限的类型：

资源类型	常见权限	说明
文件	读（Read）	读取文件内容
文件	写（Write）	修改文件内容
文件	执行（Execute）	执行文件
文件	删除（Delete）	删除文件
目录	读（Read）	查看目录内容
目录	写（Write）	在目录中创建/删除文件
目录	执行（Execute）	进入目录
目录	列表（List）	列出目录内容
数据库	SELECT	查询数据
数据库	INSERT	插入数据
数据库	UPDATE	更新数据
数据库	DELETE	删除数据

⚠️ 权限与控制结果的区别

访问权限是主体对客体允许执行的操作类型，如读、写、执行、列表等。

访问控制结果是系统根据权限做出的决策，包括允许访问或拒绝访问。

⚠️ 常见混淆： "拒绝访问"不是一种访问权限，而是访问控制的结果。当主体缺少相应权限时，系统会拒绝访问。

📋 目录的访问权限包括：

访问权限 vs 访问控制结果：

graph TB A["主体请求访问"] B["检查访问权限"] C["有权限？"] D["允许访问"] E["拒绝访问"] A --> B B --> C C -->|"Yes"| D C -->|"No"| E B --> B1["读权限"] B --> B2["写权限"] B --> B3["执行权限"] D --> D1["访问控制结果"] E --> E1["访问控制结果"] style B fill:#e3f2fd,stroke:#1976d2 style D fill:#c8e6c9,stroke:#2e7d32 style E fill:#ffcdd2,stroke:#c62828

Unix/Linux目录权限示例：

# 目录权限
# drwxr-xr-x
# d: 目录
# rwx: 所有者权限（读、写、执行）
# r-x: 组权限（读、执行）
# r-x: 其他用户权限（读、执行）

# 目录权限含义：
# r (read): 可以列出目录内容
# w (write): 可以在目录中创建、删除文件
# x (execute): 可以进入目录

# 没有权限的结果：拒绝访问
# 但“拒绝访问”不是一种权限

1.3 访问控制的目标

访问控制的三大目标是保护信息的机密性、完整性和可用性（CIA三要素）。

二、安全模型分类

2.1 机密性模型

保护分级信息机密性的模型：

保护分级信息机密性的模型包括：Bell-LaPadula模型和信息流模型。

graph TB A["机密性模型"] B["Bell-LaPadula
模型"] C["信息流模型"] A --> B A --> C B --> B1["军事和政府"] B --> B2["多级安全"] B --> B3["上读下写规则"] C --> C1["信息流向控制"] C --> C2["防止信息泄露"] C --> C3["格模型基础"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d

💡 机密性模型的选择

为什么选择这两个模型：

✅ Bell-LaPadula模型

专门设计用于保护机密性
基于多级安全策略
防止信息向下流动

✅ 信息流模型

控制信息流向
防止信息泄露
支持机密性保护

❌ 不是机密性模型：

Biba模型 - 保护完整性
Clark-Wilson模型 - 保护完整性
Chinese Wall模型 - 多边安全

2.2 完整性模型

保护数据完整性的模型：

完整性模型包括：Biba模型和Clark-Wilson模型。

graph TB A["完整性模型"] B["Biba模型"] C["Clark-Wilson
模型"] A --> B A --> C B --> B1["下读上写"] B --> B2["防止污染"] B --> B3["完整性级别"] C --> C1["商业环境"] C --> C2["良构事务"] C --> C3["职责分离"] style B fill:#fff3e0,stroke:#f57c00 style C fill:#f3e5f5,stroke:#7b1fa2

💡 完整性模型对比

两种完整性模型的区别：

Biba模型：

🔒 基于完整性级别
📊 下读上写规则
🛡️ 防止低完整性数据污染高完整性数据

Clark-Wilson模型：

💼 面向商业环境
✅ 良构事务（Well-Formed Transactions）
👥 职责分离（Separation of Duties）
🔐 访问三元组（用户-程序-数据）

完整性模型对比：

模型	适用场景	核心机制	特点
Biba	军事、政府	完整性级别、下读上写	简单、形式化
Clark-Wilson	商业、金融	良构事务、职责分离	实用、灵活

2.3 多边安全模型

多边安全模型：

多边安全模型包括：Chinese Wall模型和BMA模型。

graph TB A["多边安全模型"] B["Chinese Wall
模型"] C["BMA模型"] A --> B A --> C B --> B1["金融机构"] B --> B2["利益冲突防范"] B --> B3["动态访问控制"] C --> C1["医疗资料"] C --> C2["隐私保护"] C --> C3["患者数据安全"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#c8e6c9,stroke:#2e7d32

💡 多边安全模型的应用

Chinese Wall模型（金融机构）：

🏦 防止利益冲突
🔒 动态访问控制
📊 信息隔离墙
💼 适用于投资银行、咨询公司

BMA模型（医疗资料）：

🏥 保护患者隐私
📋 医疗数据安全
🔐 访问权限管理
⚕️ 符合医疗法规

多边安全模型应用对比：

模型	主要应用	保护对象	核心机制
Chinese Wall	金融机构	商业机密、利益冲突	动态访问控制、信息隔离
BMA	医疗机构	患者隐私、医疗数据	角色权限、数据分类

三、Bell-LaPadula模型（BLP）

3.1 BLP模型规则

BLP模型基于两种规则保障数据的机密性和敏感度：

graph TB A["BLP模型规则"] B["简单安全特性
Simple Security"] C["*特性
Star Property"] A --> B A --> C B --> B1["No Read Up"] B --> B2["上读规则"] B --> B3["主体不可读安全级别
高于它的数据"] C --> C1["No Write Down"] C --> C2["下写规则"] C --> C3["主体不可写安全级别
低于它的数据"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#fff3e0,stroke:#f57c00

💡 BLP模型的核心规则

两条规则：

📖 上读（No Read Up）

主体不可读安全级别高于它的数据
防止低级别用户读取高级别信息
保护机密信息不被泄露

✍️ 下写（No Write Down）

主体不可写安全级别低于它的数据
防止高级别信息流向低级别
防止机密信息降级

BLP模型示例：

安全级别（从低到高）：
公开 < 内部 < 机密 < 绝密

用户级别：机密

✅ 可以读取：公开、内部、机密（向下读）
❌ 不能读取：绝密（不能上读）

✅ 可以写入：机密、绝密（向上写）
❌ 不能写入：公开、内部（不能下写）

3.2 BLP模型的应用

BLP模型适用场景：

场景	说明	示例
军事系统	多级安全分类	绝密、机密、秘密、公开
政府机构	文件分级管理	内部文件、公开文件
企业	商业秘密保护	核心机密、一般机密

四、Biba模型

4.1 Biba模型规则

Biba模型基于两种规则保障数据的完整性：

graph TB A["Biba模型规则"] B["简单完整性特性"] C["*完整性特性"] A --> B A --> C B --> B1["No Read Down"] B --> B2["下读规则"] B --> B3["主体不可读安全级别
低于它的数据"] C --> C1["No Write Up"] C --> C2["上写规则"] C --> C3["主体不可写安全级别
高于它的数据"] style B fill:#e8f5e9,stroke:#388e3d style C fill:#fff3e0,stroke:#f57c00

💡 Biba模型的核心规则

两条规则：

📖 下读（No Read Down）

主体不可读安全级别低于它的数据
防止低完整性数据污染高完整性数据
保护数据完整性

✍️ 上写（No Write Up）

主体不可写安全级别高于它的数据
防止低完整性主体修改高完整性数据
维护数据可信度

Biba模型示例：

完整性级别（从低到高）：
未验证 < 已验证 < 可信 < 高度可信

用户级别：已验证

✅ 可以读取：已验证、可信、高度可信（向上读）
❌ 不能读取：未验证（不能下读）

✅ 可以写入：未验证、已验证（向下写）
❌ 不能写入：可信、高度可信（不能上写）

4.2 BLP vs Biba对比

两种模型的对比：

特性	BLP模型	Biba模型
保护目标	机密性	完整性
读取规则	上读（No Read Up）	下读（No Read Down）
写入规则	下写（No Write Down）	上写（No Write Up）
防止	信息泄露	数据污染
适用场景	军事、政府	商业、工业

⚠️ 记忆技巧

BLP vs Biba规则记忆：

BLP（机密性）：

📖 上读 - 不能读高级别（防泄密）
✍️ 下写 - 不能写低级别（防降级）
口诀：上读下写

Biba（完整性）：

📖 下读 - 不能读低级别（防污染）
✍️ 上写 - 不能写高级别（防篡改）
口诀：下读上写

关系：Biba是BLP的对偶模型

五、访问控制实现机制

5.1 访问控制实现方法

在实现访问控制时，有多种不同的机制和模型可以选择。对于大量用户的信息系统，需要考虑时间和资源消耗。

📊 访问控制实现机制对比

两种主要实现机制：

访问控制列表（ACL，Access Control List）
- 以客体（资源）为中心
- 每个资源维护一个列表，记录哪些用户可以访问
- 适合大量用户的系统
能力表（CL，Capability List）
- 以主体（用户）为中心
- 每个用户维护一个列表，记录可以访问哪些资源
- 适合大量资源的系统

5.2 ACL vs CL对比

两种机制的核心区别：

graph TB subgraph ACL["访问控制列表 ACL"] A1["文件A"] A2["用户列表"] A1 --> A2 A2 --> A3["用户1: 读"] A2 --> A4["用户2: 读写"] A2 --> A5["用户3: 执行"] end subgraph CL["能力表 CL"] C1["用户1"] C2["资源列表"] C1 --> C2 C2 --> C3["文件A: 读"] C2 --> C4["文件B: 读写"] C2 --> C5["文件C: 执行"] end style ACL fill:#e3f2fd,stroke:#1976d2 style CL fill:#e8f5e9,stroke:#388e3d

详细对比：

特征	访问控制列表（ACL）	能力表（CL）
组织方式	以客体（资源）为中心	以主体（用户）为中心
存储位置	与资源关联	与用户关联
列表内容	哪些用户可以访问此资源	此用户可以访问哪些资源
适用场景	用户数量大，资源数量少	资源数量大，用户数量少
权限检查	检查资源的ACL	检查用户的CL
权限回收	从资源的ACL中删除用户	从用户的CL中删除资源
时间复杂度	O(1) - 直接查找资源	O(n) - 需遍历用户列表
空间复杂度	资源数 × 平均用户数	用户数 × 平均资源数

5.3 大量用户系统的最佳选择

✅ 大量用户系统的访问控制实现

对于存在大量用户的信息系统，从时间和资源消耗的角度，应该采用访问控制列表（ACL）。

为什么ACL更适合大量用户系统：

权限检查效率高
- ⚡ 直接定位到资源
- 📊 检查资源的ACL即可
- ⏱️ 时间复杂度O(1)
空间开销合理
- 💾 通常资源数量 < 用户数量
- 📉 存储开销相对较小
- 📊 每个资源的ACL通常不会太长
管理简便
- 🛠️ 权限集中在资源上
- 🔍 易于审计资源访问情况
- 🔄 易于维护和更新

实际场景对比：

场景：企业信息系统
- 用户数量：10,000人
- 资源数量：1,000个文件/系统

使用ACL：
├── 存储：1,000个资源 × 平均100个用户 = 100,000条记录
├── 检查：直接定位资源，查找用户
└── 时间：O(1)

使用CL：
├── 存储：10,000个用户 × 平均10个资源 = 100,000条记录
├── 检查：需要遍历用户列表找到用户
└── 时间：O(n)，最坏情况需要检查10,000个用户

结论：ACL更高效

5.4 访问控制实现方案对比

各种方案对比：

方案	类型	适用场景	大量用户系统	时间效率
ACL	实现机制	自主访问控制	✅ 适合	⚡ 高
CL	实现机制	自主访问控制	❌ 不适合	🐌 低
BLP模型	安全模型	强制访问控制（机密性）	❌ 不适用	-
Biba模型	安全模型	强制访问控制（完整性）	❌ 不适用	-

访问控制列表（ACL）

是实现自主访问控制的机制
适合大量用户的系统
时间和资源消耗合理
广泛应用于实际系统

能力表（CL）

也是实现自主访问控制的机制
不适合大量用户的系统
权限检查需要遍历用户列表
时间消耗高

BLP模型

是安全模型，不是实现机制
用于强制访问控制，不是自主访问控制
主要保护机密性
不适用于大量用户系统的实现

Biba模型

是安全模型，不是实现机制
用于强制访问控制，不是自主访问控制
主要保护完整性
不适用于大量用户系统的实现

5.5 实现机制 vs 安全模型

关键区别：

graph TB A["访问控制"] B["实现机制"] C["安全模型"] A --> B A --> C B --> B1["ACL：以资源为中心"] B --> B2["CL：以用户为中心"] C --> C1["BLP：机密性模型"] C --> C2["Biba：完整性模型"] B --> B3["如何实现"] C --> C3["保护什么"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d

类别	实现机制	安全模型
定义	如何存储和检查权限	定义安全策略和规则
层次	实现层面	理论层面
目的	高效实现访问控制	保证安全属性
例子	ACL、CL	BLP、Biba、Chinese Wall
关系	可以用于实现模型	需要通过机制实现

理解要点：

实现机制：回答“如何实现”的问题
安全模型：回答“保护什么”的问题
ACL和CL可以用来实现BLP或Biba模型
但BLP和Biba本身不是实现机制

5.6 ACL实际应用示例

Unix/Linux文件系统的ACL：

# 查看ACL
getfacl /path/to/file

# 输出示例
# file: /path/to/file
# owner: user1
# group: group1
user::rw-
user:user2:r--
group::r--
mask::r--
other::---

# 设置ACL
setfacl -m u:user2:r /path/to/file

Windows文件系统的ACL：

文件：project.docx
ACL：
  - 用户1 (所有者): 完全控制
  - 用户2: 读取、写入
  - 用户3: 只读
  - 组A: 读取、写入
  - Everyone: 拒绝访问

数据库系统的ACL：

-- 表的ACL
GRANT SELECT, INSERT ON employees TO user1;
GRANT SELECT ON employees TO user2;
GRANT ALL PRIVILEGES ON employees TO admin;

-- 查看权限
SHOW GRANTS FOR user1;

六、Kerberos协议

6.1 Kerberos协议概述

Kerberos是一种常用的集中访问控制协议，通过可信第三方的认证服务，减轻应用服务器的负担。

Kerberos运行环境组成：

graph TB A["Kerberos运行环境"] B["密钥分发中心
KDC"] C["应用服务器
Application Server"] D["客户端
Client"] A --> B A --> C A --> D B --> B1["认证服务器
AS"] B --> B2["票据授权服务器
TGS"] B1 --> B1A["验证用户身份"] B1 --> B1B["颁发TGT"] B2 --> B2A["验证TGT"] B2 --> B2B["颁发服务票据"] C --> C1["提供服务"] C --> C2["验证服务票据"] D --> D1["请求认证"] D --> D2["请求服务"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00

💡 Kerberos三大组件

Kerberos运行环境由三个部分组成：

🔑 密钥分发中心（KDC）

认证服务器（AS）：验证用户身份
票据授权服务器（TGS）：颁发服务票据
可信第三方

🖥️ 应用服务器

提供实际服务
验证服务票据
授权访问资源

👤 客户端

用户终端
请求认证和服务
使用票据访问服务

6.2 Kerberos认证流程

Kerberos协议的三个阶段：

💡 Kerberos认证流程

Kerberos认证流程分为三个阶段：

阶段 1：获得票据许可票据（TGT）

客户端向认证服务器（AS）请求认证
AS验证用户身份后返回TGT
TGT用于后续请求服务票据

阶段 2：获得服务许可票据（Service Ticket）

客户端向票据授权服务器（TGS）出示TGT
TGS验证TGT后颁发服务票据
服务票据用于访问特定服务

阶段 3：获得服务（Access Service）

客户端向应用服务器出示服务票据
服务器验证票据后提供服务
建立安全会话

详细认证流程：

sequenceDiagram participant C as 客户端 participant AS as 认证服务器(AS) participant TGS as 票据授权服务器(TGS) participant S as 应用服务器 Note over C,S: 阶段1：获得票据许可票据(TGT) C->>AS: 1. 请求认证（用户名） AS->>C: 2. 返回TGT（用密钥加密） Note over C,S: 阶段2：获得服务许可票据 C->>TGS: 3. 请求服务票据（TGT+服务名） TGS->>C: 4. 返回服务票据（Service Ticket） Note over C,S: 阶段3：获得服务 C->>S: 5. 请求服务（服务票据） S->>C: 6. 提供服务 style AS fill:#e3f2fd,stroke:#1976d2 style TGS fill:#fff3e0,stroke:#f57c00 style S fill:#e8f5e9,stroke:#388e3d

三个阶段详解：

阶段1：获得票据许可票据（TGT）

步骤	操作	说明
1	客户端→AS	发送用户名，请求认证
2	AS验证	检查用户是否存在
3	AS→客户端	返回TGT（用用户密钥加密）
4	客户端解密	使用密码派生的密钥解密TGT

💡 TGT（Ticket Granting Ticket）

票据许可票据的特点：

🎫 用于向TGS请求服务票据
🔐 用用户密钥加密
⏰ 有时效性（通常8-10小时）
🔄 可重复使用，无需每次输入密码

阶段2：获得服务许可票据

步骤	操作	说明
1	客户端→TGS	发送TGT和请求的服务名
2	TGS验证	验证TGT的有效性
3	TGS→客户端	返回服务票据（用服务密钥加密）
4	客户端保存	保存服务票据用于访问服务

💡 Service Ticket（服务票据）

服务票据的特点：

🎫 用于访问特定服务
🔐 用服务密钥加密
⏰ 有时效性（通常5分钟-8小时）
🎯 针对特定服务

阶段3：获得服务

步骤	操作	说明
1	客户端→服务器	发送服务票据
2	服务器验证	解密并验证服务票据
3	服务器→客户端	提供请求的服务
4	建立会话	客户端和服务器建立安全会话

6.3 Kerberos的优势

Kerberos的核心优势：

优势详解：

优势	说明	价值
集中认证	统一的认证服务	简化管理，提高安全性
单点登录	一次认证，多次使用	提升用户体验
减轻负担	应用服务器无需存储密码	降低安全风险
相互认证	客户端和服务器双向认证	防止中间人攻击
时效性	票据有时间限制	限制攻击窗口
可扩展	支持大规模部署	适合企业环境

6.4 Kerberos的关键概念

重要术语：

Kerberos关键概念：
├── KDC（Key Distribution Center）
│   ├── AS（Authentication Server）
│   │   ├── 验证用户身份
│   │   └── 颁发TGT
│   └── TGS（Ticket Granting Server）
│       ├── 验证TGT
│       └── 颁发服务票据
├── 票据类型
│   ├── TGT（Ticket Granting Ticket）
│   │   ├── 票据许可票据
│   │   ├── 用于请求服务票据
│   │   └── 有效期：8-10小时
│   └── Service Ticket
│       ├── 服务票据
│       ├── 用于访问特定服务
│       └── 有效期：5分钟-8小时
├── 主体（Principal）
│   ├── 用户主体：user@REALM
│   └── 服务主体：service/host@REALM
└── 领域（Realm）
    ├── Kerberos管理域
    ├── 通常对应DNS域
    └── 可以建立信任关系

6.5 Kerberos安全特性

安全机制：

💡 Kerberos安全特性

核心安全机制：

🔐 加密保护

所有票据都经过加密
密码不在网络传输
使用对称加密算法

⏰ 时间戳

防止重放攻击
票据有时效性
要求时钟同步

🔄 相互认证

客户端认证服务器
服务器认证客户端
防止中间人攻击

🎫 票据机制

无需重复输入密码
限制票据使用范围
支持票据撤销

安全考虑：

安全问题	防护措施	说明
重放攻击	时间戳+时钟同步	要求5分钟内时钟误差
密码猜测	预认证机制	AS-REQ需要加密时间戳
KDC单点故障	KDC冗余	部署多个KDC
票据窃取	加密+时效性	限制票据使用时间
中间人攻击	相互认证	双向验证身份

6.6 Kerberos应用场景

典型应用：

应用场景	说明	示例
Windows域	Active Directory	企业Windows网络
Linux/Unix	MIT Kerberos	企业Unix环境
Web应用	SPNEGO	浏览器SSO
数据库	Kerberos认证	Oracle、PostgreSQL
文件共享	NFS、CIFS	网络文件系统
邮件系统	IMAP、SMTP	企业邮件服务

实际部署示例：

企业Kerberos部署：
├── KDC服务器
│   ├── 主KDC（kdc1.neo01.com）
│   └── 从KDC（kdc2.neo01.com）
├── 领域配置
│   ├── 领域名：neo01.com
│   ├── KDC地址：kdc1.neo01.com:88
│   └── 管理服务器：kdc1.neo01.com:749
├── 客户端配置
│   ├── /etc/krb5.conf
│   ├── 默认领域：neo01.com
│   └── DNS查找：启用
└── 服务配置
    ├── HTTP/web.neo01.com@neo01.com
    ├── host/server.neo01.com@neo01.com
    └── nfs/fileserver.neo01.com@neo01.com

6.7 Kerberos vs 其他认证协议

认证协议对比：

协议	类型	优势	劣势	适用场景
Kerberos	票据	单点登录、安全性高	配置复杂、需时钟同步	企业内网
LDAP	目录	简单、灵活	密码传输、无SSO	用户管理
RADIUS	远程	广泛支持	安全性较低	VPN、WiFi
OAuth 2.0	授权	适合Web、移动	不是认证协议	第三方授权
SAML	联邦	跨域SSO	复杂	企业联邦

七、访问控制实施步骤

7.1 访问控制实施流程

访问控制实施流程四要素：

7.2 四要素详解

1. 主体（Subject）

主体：
├── 定义：主动发起访问请求的实体
├── 类型：
│   ├── 用户
│   ├── 进程
│   └── 程序
├── 职责：
│   ├── 发起访问请求
│   ├── 提供身份信息
│   └── 等待访问结果
└── 示例：用户请求访问文件

2. 访问控制实施部件（Access Control Enforcement）

访问控制实施部件：
├── 定义：执行访问控制决策的部件
├── 职责：
│   ├── 接收主体的访问请求
│   ├── 向决策部件查询权限
│   ├── 执行决策结果
│   └── 允许或拒绝访问
├── 位置：主体和客体之间
└── 示例：操作系统内核、安全网关

3. 客体（Object）

客体：
├── 定义：被访问的资源
├── 类型：
│   ├── 文件
│   ├── 目录
│   ├── 数据库
│   └── 网络资源
├── 特点：
│   ├── 被动接受访问
│   ├── 需要保护
│   └── 有安全属性
└── 示例：被访问的文件

4. 访问控制决策部件（Access Control Decision）

访问控制决策部件：
├── 定义：判断是否允许访问的部件
├── 职责：
│   ├── 存储访问控制策略
│   ├── 存储权限信息
│   ├── 根据策略判断权限
│   └── 返回决策结果
├── 存储内容：
│   ├── ACL（访问控制列表）
│   ├── 权限矩阵
│   └── 安全策略
└── 示例：权限数据库、策略服务器

7.3 访问控制实施详细流程

完整的访问控制过程：

sequenceDiagram participant S as 1.主体 participant E as 2.实施部件 participant D as 4.决策部件 participant O as 3.客体 S->>E: 步骤1: 请求访问客体 E->>D: 步骤2: 查询访问权限 D->>D: 步骤3: 检查策略和权限 D->>E: 步骤4: 返回决策（允许/拒绝） alt 允许访问 E->>O: 步骤5a: 转发访问请求 O->>E: 步骤6a: 返回资源 E->>S: 步骤7a: 返回结果 else 拒绝访问 E->>S: 步骤5b: 返回拒绝信息 end style S fill:#e3f2fd,stroke:#1976d2 style E fill:#fff3e0,stroke:#f57c00 style O fill:#e8f5e9,stroke:#388e3d style D fill:#f3e5f5,stroke:#7b1fa2

7.4 实际应用示例

文件系统访问控制示例：

场景：用户请求读取文件

1. 主体：用户Alice
   - 发起请求：open("/data/report.txt", READ)

2. 访问控制实施部件：操作系统内核
   - 接收请求
   - 提取信息：用户=Alice, 文件=/data/report.txt, 操作=READ
   - 向决策部件查询

3. 客体：文件/data/report.txt
   - 等待访问

4. 访问控制决策部件：文件系统ACL
   - 查找文件ACL：
     /data/report.txt:
       - Alice: READ, WRITE
       - Bob: READ
       - Group_Finance: READ, WRITE
   - 判断：Alice有READ权限
   - 返回：允许访问

结果：实施部件允许Alice读取文件

7.5 关键理解要点

💡 重要区分

实施部件 vs 决策部件：

访问控制实施部件：

职责：执行决策
位置：主体和客体之间
功能：控制访问流程
示例：防火墙、操作系统内核

访问控制决策部件：

职责：判断权限
位置：后端策略存储
功能：存储和查询策略
示例：ACL数据库、策略服务器

正确顺序记忆：

访问控制实施步骤：
1. 主体 → 发起请求
2. 访问控制实施部件 → 接收并查询
3. 客体 → 被访问的资源
4. 访问控制决策部件 → 判断权限

口诀：主实客决（主体、实施、客体、决策）

八、访问控制策略

7.1 访问控制策略类型

主要访问控制策略：

graph TB A["访问控制策略"] B["自主访问控制
DAC"] C["强制访问控制
MAC"] D["基于角色
RBAC"] E["基于属性
ABAC"] A --> B A --> C A --> D A --> E B --> B1["资源所有者控制"] B --> B2["灵活但不安全"] C --> C1["系统强制执行"] C --> C2["需要安全标签"] D --> D1["基于角色授权"] D --> D2["便于管理"] E --> E1["基于属性决策"] E --> E2["细粒度控制"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#ffebee,stroke:#c62828 style D fill:#e8f5e9,stroke:#388e3d style E fill:#fff3e0,stroke:#f57c00

7.2 强制访问控制（MAC）的特点

💡 强制访问控制（MAC）的核心特征

关键理解：

✅ 安全属性机制

主体和客体都有固定的安全属性
主体有安全许可级别，客体有安全分类级别
系统根据安全属性强制执行访问控制

✅ 强制性特征

安全属性由安全管理员或操作系统确定
用户不能随意篡改安全属性
系统强制执行，保证安全策略的一致性

✅ 决策机制

系统通过比较主体和客体的安全属性决定访问
应用安全规则（如BLP的上读下写、Biba的下读上写）
系统自动执行，无需用户干预

强制访问控制（MAC）的正确理解：

graph TB A["强制访问控制 MAC"] B["主体
Subject"] C["客体
Object"] D["安全属性"] E["访问决策"] A --> B A --> C A --> D A --> E B --> B1["安全许可级别"] C --> C1["安全分类级别"] D --> D1["由系统管理"] D --> D2["不可随意修改"] E --> E1["系统强制执行"] E --> E2["基于安全策略"] style A fill:#ffebee,stroke:#c62828 style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00 style E fill:#f3e5f5,stroke:#7b1fa2

MAC vs DAC对比：

特性	强制访问控制（MAC）	自主访问控制（DAC）
控制主体	系统	资源所有者
安全属性	固定的安全级别	用户定义的权限
修改权限	只能由安全管理员修改	资源所有者可修改
访问决策	基于安全策略自动执行	基于用户授权
灵活性	低	高
安全性	高	相对较低
适用场景	军事、政府高安全环境	一般商业环境
典型模型	BLP、Biba	ACL、CL
用户控制	用户不能控制	用户可以控制

强制访问控制的关键特征：

强制访问控制（MAC）的特征：
├── 1. 安全属性
│   ├── 主体有安全许可级别
│   ├── 客体有安全分类级别
│   ├── 由系统或安全管理员确定
│   └── 用户不能随意修改
├── 2. 强制执行
│   ├── 系统自动执行
│   ├── 基于安全策略
│   ├── 不依赖用户意愿
│   └── 用户无法绕过
├── 3. 访问决策
│   ├── 比较主体和客体的安全属性
│   ├── 应用安全规则（如BLP、Biba）
│   ├── 系统级控制
│   └── 非用户级控制
└── 4. 应用场景
    ├── 军事系统
    ├── 政府机构
    ├── 高安全要求环境
    └── 多级安全系统

⚠️ MAC与DAC的本质区别

**强制访问控制（MAC）**是系统级的访问控制机制，基于安全策略强制执行，用户无法改变访问控制决策。

**自主访问控制（DAC）**是对单个用户执行访问控制的过程控制措施，由资源所有者决定访问权限。

🔐 MAC的核心特征：

系统级强制性控制
基于安全属性（安全标签）
由安全管理员或系统管理
用户无法修改安全策略
适用于高安全环境（军事、政府）

👤 DAC的核心特征：

用户级自主控制
资源所有者决定权限
用户可以修改权限
灵活但安全性较低
适用于一般商业环境

MAC的实际应用示例：

军事系统的MAC实现：

安全级别（从低到高）：
公开 < 内部 < 机密 < 绝密

用户A：
├── 安全许可：机密级
├── 可以访问：公开、内部、机密级文件
├── 不能访问：绝密级文件
└── 用户A无法修改自己的安全许可级别

文件X：
├── 安全分类：绝密级
├── 可被访问：只有绝密级许可的用户
├── 不能被访问：机密级及以下用户
└── 文件的安全分类由系统管理员设定

访问控制决策：
├── 用户A请求访问文件X
├── 系统比较：用户A（机密级） vs 文件X（绝密级）
├── 应用BLP规则：不能上读（No Read Up）
└── 结果：拒绝访问（系统强制执行，用户无法绕过）

5.2 强制访问控制（MAC）

需要安全标签的访问控制策略：

**强制访问控制（MAC）**策略需要安全标签。

💡 强制访问控制的特点

为什么MAC需要安全标签：

🏷️ 安全标签必需

主体需要安全许可标签
客体需要安全分类标签
系统根据标签强制执行访问控制

🔒 系统强制执行

用户无法改变访问控制
基于安全策略自动决策
防止特权滥用

📊 多级安全

支持分级信息保护
实现BLP或Biba模型
适用于高安全环境

访问控制策略对比：

策略类型	需要安全标签	控制方式	灵活性	安全性	适用场景
强制访问控制（MAC）	✅ 是	系统强制	⭐⭐ 低	⭐⭐⭐⭐⭐ 高	军事、政府
自主访问控制（DAC）	❌ 否	用户自主	⭐⭐⭐⭐⭐ 高	⭐⭐ 低	一般企业
基于角色（RBAC）	❌ 否	角色授权	⭐⭐⭐⭐ 高	⭐⭐⭐ 中	企业应用
基于属性（ABAC）	❌ 否	属性决策	⭐⭐⭐⭐⭐ 高	⭐⭐⭐⭐ 高	云计算

八、安全模型总结

8.1 模型分类汇总

按保护目标分类：

安全模型分类：
├── 机密性模型
│   ├── Bell-LaPadula模型
│   └── 信息流模型
├── 完整性模型
│   ├── Biba模型
│   └── Clark-Wilson模型
└── 多边安全模型
    ├── Chinese Wall模型（金融）
    └── BMA模型（医疗）

8.2 模型选择指南

根据需求选择合适的模型：

需求	推荐模型	原因
保护分级信息机密性	Bell-LaPadula + 信息流	专门设计用于机密性保护
保护数据完整性	Biba + Clark-Wilson	防止数据污染和篡改
金融机构信息保护	Chinese Wall	防止利益冲突
医疗资料保护	BMA	保护患者隐私
需要安全标签	强制访问控制（MAC）	系统强制执行

九、总结

访问控制的核心要点：

机密性保护：使用Bell-LaPadula模型和信息流模型
完整性保护：使用Biba模型和Clark-Wilson模型
多边安全：Chinese Wall用于金融，BMA用于医疗
BLP规则：上读下写，保护机密性
Biba规则：下读上写，保护完整性
强制访问控制：需要安全标签，系统强制执行

🎯 关键要点

Bell-LaPadula模型和信息流模型保护机密性
Biba模型和Clark-Wilson模型保护完整性
Chinese Wall模型用于金融机构
BMA模型用于医疗资料保护
BLP模型：上读下写（No Read Up, No Write Down）
Biba模型：下读上写（No Read Down, No Write Up）
强制访问控制（MAC）需要安全标签
Chinese Wall和BMA都是多边安全模型
访问控制实施流程四要素：主体→实施部件→客体→决策部件
实施部件执行决策，决策部件判断权限

💡 实践建议

根据保护目标选择合适的安全模型
机密性和完整性可以同时实施
多边安全模型适用于特定行业
强制访问控制适用于高安全环境
定期审查和更新访问控制策略

Cybersecurity

一、访问控制概述

1.1 访问控制的定义与作用

1.2 主体和客体

1.3 访问控制的目标

二、安全模型分类

2.1 机密性模型

2.2 完整性模型

2.3 多边安全模型

三、Bell-LaPadula模型（BLP）

3.1 BLP模型规则

3.2 BLP模型的应用

四、Biba模型

4.1 Biba模型规则

4.2 BLP vs Biba对比

五、访问控制实现机制

5.1 访问控制实现方法

5.2 ACL vs CL对比

5.3 大量用户系统的最佳选择

5.4 访问控制实现方案对比

5.5 实现机制 vs 安全模型

5.6 ACL实际应用示例

六、Kerberos协议

6.1 Kerberos协议概述

6.2 Kerberos认证流程

6.3 Kerberos的优势

6.4 Kerberos的关键概念

6.5 Kerberos安全特性

6.6 Kerberos应用场景

6.7 Kerberos vs 其他认证协议

七、访问控制实施步骤

7.1 访问控制实施流程

7.2 四要素详解

7.3 访问控制实施详细流程

7.4 实际应用示例

7.5 关键理解要点

八、访问控制策略

7.1 访问控制策略类型

7.2 强制访问控制（MAC）的特点

5.2 强制访问控制（MAC）

八、安全模型总结

8.1 模型分类汇总

8.2 模型选择指南

九、总结