一、安全体系结构概述

（一）从系统设计之初就考虑安全性

原则核心： 安全不是后期“补丁”，而是系统架构的有机组成部分。
课件依据： M. Gasser指出，若不在系统设计早期考虑安全，最终系统很难具备真正有效的安全性。
深入理解：

• 常见误区： “先实现功能，再添加安全”。这种思路常导致安全机制与系统逻辑冲突，增加修改成本与风险。
• 实践要点： 在需求分析与架构设计阶段，就需明确安全目标、威胁模型与安全策略，确保安全与功能同步设计、同步实现。

---

（二）应尽量考虑未来可能面临的安全需求

原则核心： 设计应具备前瞻性与适应性，避免因需求变化导致架构颠覆性改动。
课件依据： 需从“预设”角度考虑系统未来可能新增的安全属性。
深入理解：

• 方法：
  1. 抽象化设计： 安全机制应基于抽象接口，便于未来替换或扩展。
  2. 策略可配置化： 安全策略（如访问控制规则）应支持灵活调整。
  3. 避免过度具体： 不过度绑定具体技术或威胁，保持架构的通用性。

---

（三）实现安全控制的极小化和隔离性

原则核心： 安全机制应简洁、独立、易于验证，减少系统复杂性带来的安全隐患。
课件依据： 安全相关部分应“复杂性极小化”且“相对独立”，数据隔离要适度。
深入理解：

• 极小化： 安全模块功能应单一、代码量小，便于形式化验证与测试。
• 隔离性：
  • 物理隔离： 关键安全组件（如加密模块）可在独立硬件中实现。
  • 逻辑隔离： 通过权限划分、进程空间分离等手段限制访问。
• 注意： 隔离不宜过度，否则影响性能与可维护性。

---

（四）实施极小特权

原则核心： 任何实体（用户、进程、模块）仅拥有完成其任务所必需的最小权限。
课件依据： 涉及硬件特权与软件特权的结构化控制。
深入理解：

• 实施层面：
  1. 用户权限： 按角色分配权限，避免普通用户拥有管理员权限。
  2. 进程权限： 进程运行在最小必要权限模式下（如Linux的Capability机制）。
  3. 模块权限： 安全模块仅能访问其必需的数据与资源。
• 益处： 限制攻击面，即便某部分被破坏，影响范围也有限。

---

（五）安全相关功能必须结构化

原则核心： 安全功能应模块化、接口清晰，便于检查、测试与维护。
课件依据： 安全控制应“易于确定”且具有“清晰规范的接口”。
深入理解：

• 结构化体现：
  • 模块化设计： 将认证、授权、审计等功能分离为独立模块。
  • 接口标准化： 模块间通过明确定义的接口交互，降低耦合度。
  • 可审查性： 架构应支持安全功能的独立审计与验证。

---

（六）使安全性能“友好”

原则核心： 安全机制不应给合法用户带来过度负担，应在安全与用户体验间取得平衡。
课件依据： 安全不应影响遵守规则的用户，且应便于授权存取与约束存取。
深入理解：

• 用户友好设计：
  1. 透明性： 安全操作（如加密传输）应对用户无感。
  2. 灵活性： 提供简便的授权机制（如单点登录）。
  3. 可控性： 允许用户方便地管理自身数据的安全设置（如隐私开关）。
• 避免“安全暴力”： 不应以牺牲用户体验为代价追求绝对安全。

---

（七）使安全性不依赖于保密

原则核心： 系统的安全性不应建立在“攻击者不知道内部机制”的假设上。
课件依据： 安全不应依赖对机制保密，公开设计反而可能提升安全性。
深入理解：

• Kerckhoffs原则： 密码系统应即使除密钥外全部公开仍安全。
• 实践意义：
  1. 机制公开可审计： 通过同行评审发现潜在漏洞。
  2. 不依赖“隐匿安全”： 不假设攻击者无法获取系统信息（如源代码、手册）。
  3. 安全靠数学与工程： 依靠加密算法强度、访问控制模型等科学机制，而非信息隐瞒。

二、安全系统设计的基本原则

安全系统设计的基本原则由Saltzer和Schroeder于1975年提出，共八项，是构建可信系统的核心指导思想：

（一）机制经济性

系统设计应尽可能简单小巧，复杂的设计易引入漏洞且难以审查。保护机制需通过逐行代码审查或硬件物理检查来确保安全。

（二）基于“许可”的安全

访问控制应基于明确定义的许可，而非排除。默认状态为“禁止访问”，只有被明确授权的请求才被允许。这种保守策略能避免因设计疏漏导致未授权访问。

（三）完全的访问仲裁

系统必须对每一次访问请求进行权限检查，包括初始化、恢复、关机等所有操作阶段。不能依赖缓存或历史记录跳过验证，确保权限变更后及时更新。

（四）开放型系统设计

安全不应依赖“设计保密”，而应依靠受保护的密钥或密码。开放设计便于同行评审，用户也可自行验证系统安全性，符合现代安全透明化趋势。

（五）权限分离

重要操作应要求多个独立条件同时满足（如双人授权、多因素认证），避免单点失效。该原则广泛应用于金融、军事和关键系统中。

（六）最小特权

每个用户和程序仅被授予完成其任务所必需的最小权限。这既能限制错误或恶意行为的影响范围，也简化了安全审计的复杂度。

（七）公共机制最小化

应尽量减少用户间共享的机制，因为共享路径可能成为信息泄漏或攻击的通道。共享组件必须经过严格设计与验证。

（八）用户友好

安全机制应易于理解和使用，使用户能够正确、习惯性地运用保护措施。若界面复杂或与用户心智模型不符，将导致误操作或规避行为。

---

三、安全内核的三种实现方法

安全内核是在不安全操作系统上构建安全系统的核心模块，有三种典型实现策略：

（一）虚拟机法

• 做法：在硬件与原有操作系统之间插入一个安全内核层，原操作系统作为虚拟机运行，几乎无需修改。
• 优点：
  • 保持原有应用兼容性，用户接口和系统效率不受影响。
  • 操作系统无需感知安全内核存在，便于支持未来版本。
• 缺点：
  • 高度依赖硬件虚拟化支持。
  • 难以实现高级别安全（如B3以上）。

（二）仿真法

• 做法：修改原操作系统内核以增强安全性，并在其之上编写仿真程序，模拟原系统接口，使原有应用程序仍可运行。
• 优点：
  • 不受现有应用程序限制，可自由定义内核接口。
  • 保留了部分兼容性。
• 缺点：
  • 需同时设计仿真程序与安全内核，复杂度高。
  • 某些不安全或不明确的接口难以仿真或实现。

（三）新建法

• 做法：彻底重新设计操作系统，包括全新安全内核、接口和应用程序。
• 优点：
  • 完全自主设计，可实现高安全级别。
  • 内核可最小化，系统性能与安全性可优化平衡。
• 缺点：
  • 开发周期长、成本高、难度大。
  • 需重建生态，兼容性差。

---

四、安全操作系统的一般开发过程、设计与实现方法

（一）一般开发过程（基于CC标准与安全模型）

1. 安全需求分析
   明确系统需抵御的威胁、保护的对象及安全功能，形成安全策略。

2. 建立安全模型
   将安全策略形式化为数学模型（如BLP、Biba），用于精确描述系统安全行为，并验证模型与策略的一致性。

3. 高层设计与机制实现
   基于模型设计安全机制（如访问控制、审计、加密），并在系统中实现。设计时需权衡安全、兼容性与效率。

4. 测试与验证
   包括：

   • 功能测试
   • 渗透测试
   • 形式化验证（如使用定理证明）
   • 非形式化确认（如代码审查）

5. 可信度认证
   提交权威机构进行安全评估与等级认证（如依据GB/T 20272或Common Criteria）。

（二）设计与实现关键考虑

1. TCB的设计与实现

   • 可信计算基包括所有安全相关硬件、软件和规程。
   • 需实施严格的配置管理、生命周期支持、指导性文档。
   • 进行脆弱性评定，包括隐蔽通道分析、抗攻击性评估等。

2. 安全机制的友好性

   • 安全应对合法用户透明，不影响正常操作。
   • 机制间应无缝协同，避免冲突。
   • 提供清晰的授权与控制接口。

3. 兼容性与效率的平衡

   • 优先级：安全 > 兼容性 > 效率。
   • 在满足安全目标的前提下，尽量减少对原有功能和性能的影响。