《系统架构设计师教程（第2版）》第18章-安全架构设计理论与实践-07-系统架构的脆弱性分析

1. 脆弱性和漏洞

• 信息系统的脆弱性是一个系统问题
• 脆弱性包括：
  • 物理装备脆弱性：如计算机硬件、通信线路等
  • 软件脆弱性：如操作系统、网络协议簇、数据库管理系统、应用程序等
  • 人员管理、规章制度、安全策略的脆弱性
• 漏洞的主要来源：
  • 软件设计时的瑕疵
  • 软件实现中的弱点
  • 软件本身的瑕疵
  • 系统和网络的错误配置

2. 软件脆弱性

2.1 定义

• 定义：
  • 由软件缺陷的客观存在所形成的，一个可以被攻击者利用的实例

但是教材后文又诠释为：软件脆弱性就是软件规范、开发或配置中错误的实例，其执行结果将会违反安全策略。
这个说的并不正确，脆弱性本身并不是错误，也不会引起错误，只有被利用才会引起安全问题或错误。

• 和缺陷的关系

  • 每个脆弱性都由至少一个软件缺陷引起
  • 一个软件缺陷不一定会产生脆弱性
  • 不同的软件缺陷可能导致相同的脆弱性

• 软件开发过程中的脆弱性

  • 软件架构设计的脆弱性
  • 软件模块设计的脆弱性
  • 软件接口设计的脆弱性
  • 软件界面设计的脆弱性
  • 数据库设计的脆弱性
  • 软件基础模型的脆弱性
  • 设计模式的脆弱性
  • 实现的脆弱性

2.2 特点

• 脆弱性是软件系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的安全后果
• 在软件开发过程中，自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源
• 软件脆弱性与具体的系统环境密切相关，系统环境的差异都有可能导致不同的脆弱性问题
• 旧的脆弱性得到修补或纠正的同时可能引入新的脆弱性，因此脆弱性问题会长期存在

2.3 分类

1） ISOS分类法

• 范围：面向信息系统的安全和隐私方面的分类方法
• 目的：
  • 帮助信息系统管理人员理解安全问题
  • 为提高系统安全性提供相应信息

2） PA分类法

• 范围：操作系统中与安全保护相关的缺陷
• 目标：是希望能够让缺乏计算机安全领域知识的人可以利用模式指导的方法来发现计算机安全问题

3）Landwehr

• 提出：美国海军
• 基于三个维度对这些安全缺陷进行分类
  • 缺陷的起因（有意或无意）
  • 缺陷引入的时间（开发阶段、维护阶段、运行阶段）
  • 缺陷分布的位置（软件或硬件）
• 针对每个维度，可以进行更为细致的多层次分类和描述，并从不同角度绘制缺陷分布图

4）Aslam分类法

• 范围：是针对 Unix 操作系统中的安全故障
• 分类角度：从软件生命周期
• 分类
  • 编码故障
  • 突发故障
• 分类决策树：为了实现分类过程的自动化和无歧义化，设计了一系列问题

5）Bishop分类法

• 范围：针对信息安全领域的一种分类方法
• 概念：描述了一种针对Unix和网络相关脆弱性的分类方法
• 分类方法：使用6个轴线来对脆弱性进行分类
  • 6个轴线：脆弱性的性质、引入时间、利用率、影响域、最小数量、来源

6）IBM分类法

• 概念：
  • 以Landwehr分类法为基础
  • 以新出现的安全缺陷来扩充和改造

2.3 软件脆弱性的生命周期

1）脆弱性的引入阶段

• 引入软件脆弱性的原因：（吐槽：归纳了个寂寞）
  • 输入验证错误
  • 权限检查错误
  • 操作序列化错误
  • 边界检出错误
  • 软件设计时的缺陷
  • 其他错误

2）产生破坏效果阶段

• 非法执行代码
• 非法修改目标对象
• 非法访问数据对象
• 拒绝服务攻击

3）修补阶段

• 删除伪造实体
• 增加新的实体
• 写该实体不正确的位置
• 其他情况

2.4 软件脆弱性的分析方法

软件脆弱性分析可从三个方面考虑：

• 分析软件故障现象

分析故障的技术本质、总结脆弱性模式

• 分析软件开发

发现安全管理和技术的薄弱环节，提高软件安全性；

• 分析软件使用

发现其脆弱性，采取相应措施，避免脆弱性转化为安全故障。

3. 典型软件架构的脆弱性

软件架构脆弱性通常与软件架构的风格和模式有关

3.1 分层架构

• 层间的脆弱性

• 底层发生错误，将导致整个程序无法正常运行

• 层间通信的脆弱性

大量细粒度对象产生的消息交互层层传递，造成性能的下降

3.2 C/S 架构

• 客户端软件的脆弱性

客户端安装在用户计算机上，面临着程序被分析、数据被截取的安全隐患。

• 网络开放性的脆弱性

客户端存在于Internet上，使得服务器端服务器端对于 Internet上的任何用户都是开放的

• 网络协议的脆弱性

• 客户端和服务器端之间通常使用自由协议进行通信

3.3 B/S架构

• 系统如果使用 HTTP 协议， 相对C/S 架构而言更容易被病毒入侵

3.4 事件驱动架构

• 组件的脆弱性

组件削弱了自身对系统的控制能力，一个组件触发事件，并不能确定响应该事件的其他组件及各组建的执行顺序。

• 组件间交换数据的脆弱性
• 组件间逻辑关系的脆弱性

事件架构使系统中各组件的逻辑关系变得更加复杂

• 事件驱动容易进入死循环
• 高并发的脆弱性

事件驱动的高并发，可能造成系统响应问题、系统数据错误等问题

• 固定流程的脆弱性

教材原文：事件驱动的可响应流程基本都是固定的，如果操作不当，容易引发安全问题。
这个逻辑根本不通，难道不是固定流程，操作不当就不容易引发安全问题？
我理解，这里应该是 流程固定，容易被攻击者找到漏洞。

3.5 MVC架构

• MVC架构的复杂性带来脆弱性
• 视图与控制器间紧密连接的脆弱性

  视图与控制器是相互分离却联系紧密的部件，这妨碍了它们的独立重用

• 视图对模型数据的低效率访问的脆弱性

  依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。

后来教材对MVC的脆弱性进行了完全不靠谱的总结，总结内容不贴了。

3.6 微内核结构

微内核架构也被称为插件架构模式 (Plug-in Architecture Pattern), 通常由内核系统和插件组成。

• 微内核架构难以进行良好的整体优化
• 微内核系统的进程间通信开销大
• 通信损失率高

3.7 微服务架构

• 开发人员需要处理分布式系统的复杂结构
• 开发人员要设计服务之间的通信机制
• 服务管理的复杂性

---