18. 安全架构设计理论与实践

发表于 分类于

1 安全架构概述

对于信息系统来说，威胁可以是针对物理环境、通信链路、网络系统、操作系统、应用系统以及管理系统等方面。

信息系统受到的安全威胁分类

  • 人为蓄意破坏
  • 灾害性攻击
  • 系统故障
  • 人员无意识行为。

具体来讲，常见的安全威胁有以下几种:

  1. 信息泄露：信息被泄露或透露给某个非授权的实体。
  2. 破坏信息的完整性：数据被非授权地进行增删、修改或破坏而受到损失。
  3. 拒绝服务：对信息或其他资源的合法访问被无条件地阻止
  4. 非法使用(非授权访问):某一资源被某个非授权的人或以非授权的方式使用。
  5. 窃听：用各种可能的合法或非法的手段窃取系统中的信息资源和敏感信息。例如对通信线路中传输的信号进行搭线监听，或者利用通信设备在工作过程中产生的电磁泄漏截取有用信息等。
  6. 业务流分析：通过对系统进行长期监听，利用统计分析方法对诸如通信频度、通信的信息流向、通信总量的变化等态势进行研究，从而发现有价值的信息和规律。
  7. 假冒：通过欺骗通信系统 ( 或 用 户 ) 达到非法用户冒充成为合法用户，或者特权小的用户冒充成为特权大的用户的目的。黑客大多是采用假冒进行攻击。
  8. 旁路控制：攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权。例如，攻击者通过各种攻击手段发现原本应保密，但是却又暴露出来的一些系统“特性”。利用这些“特性”,攻击者可以绕过防线守卫者侵入系统的内部。
  9. 授权侵犯：被授权以某一目的使用某一系统或资源的某个人，却将此权限用于其他非授权的目的，也称作“内部攻击”。
  10. 特洛伊木马：软件中含有一个察觉不出的或者无害的程序段，当它被执行时，会破坏用户的安全。这种应用程序称为特洛伊木马 (Trojan Horse)。
  11. 陷阱门：在某个系统或某个部件中设置了“机关”,使得当提供特定的输入数据时，允许违反安全策略。
  12. 抵赖：这是一种来自用户的攻击，例如，否认自己曾经发布过的某条消息、伪造一份对方来信等。
  13. 重放：所截获的某次合法的通信数据备份，出于非法的目的而被重新发送。
  14. 计算机病毒：所谓计算机病毒，是一种在计算机系统运行过程中能够实现传染和侵害的功能程序。一种病毒通常含有两个功能：一种功能是对其他程序产生“感染”;另外一种或者是引发损坏功能或者是一种植入攻击的能力。
  15. 人员渎职：一个授权的人为了钱或利益、或由于粗心，将信息泄露给一个非授权的人。
  16. 媒体废弃：信息被从废弃的磁盘或打印过的存储介质中获得。
  17. 物理侵入：侵入者通过绕过物理控制而获得对系统的访问。
  18. 窃取：重要的安全物品，如令牌或身份卡被盗。
  19. 业务欺骗：某一伪系统或系统部件欺骗合法的用户或系统自愿地放弃敏感信息。

1.2 安全架构的定义和范围

安全架构是架构面向安全性方向上的一种细分，通常的产品安全架构、安全技术体系结构和审计架构可组成一道安全防线。

  1. 产品安全架构
    • 构建产品安全质量属性的主要组成部分以及它们之间的关系。
  2. 安全技术体系架构
    • 构建安全技术体系的主要组成部分以及它们之间的关系。
  3. 审计架构
    • 独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险。

1.3 与信息安全相关的国内外标准及组织

  1. 国外标准
    • 可信计算机系统评估准则 (TCSEC)。
    • 信息技术安全评估准则 (ITSEC)。
    • 加拿大可信计算机产品评估准则 (CTPEC)。
    • 美国联邦准则 (FC)。
    • …
  2. 国内标准
    • 标准缩写含义
      • GA: 国家安全行业标准规范。由中国安全技术防范认证中心组织发布。
      • GB: 国家标准规范，由中国国家标准化管理委员会组织发布
      • GJB: 国家军用标准规范。
    • 主要技术标准
      • GB 15834-1995 信息处理数据加密实体鉴别机制
      • GA163-1997 计算机信息系统安全专用产品分类原则
      • GB17859-1999 计算机信息系统安全保护等级划分准则
      • …
  3. 相关标准化组织
    • 可信计算机国际标准化组织 (ISO)
    • 国际电工委员会 (IEC)
    • 中国国家标准化管理委员会 ( SAC )
    • 全国信息技术标准化技术委员会(简称“信标委”)

2 安全模型

信息系统的安全目标

  • 控制和管理主体（含用户和进程）对客体（含数据和程序）的访问。
  • 实现：
    • 保护信息系统的可用性；
    • 保护网络系统服务的连续性
    • 防范资源的非法访问及非授权访问
    • 防范入侵者的恶意攻击与破坏
    • 保护信息通过网上传输过程中的机密性、完整性；
    • 防范病毒的侵害
    • 实现安全管理

安全模型

安全模型是准确描述安全的重要方面及其与系统行为的关系，安全策略是从安全角度为系统整体和构成它的组件提出基本的目标。

安全模型有许多种，可针对不同的特性、场景以及控制关系使用不同的安全模型。当前比较被公认的模型有：状态机模型 (State Machine Model)、Bell-LaPadula(BLP) 模型、Biba模型、 Clark-Wilson(CWM) 模型、 ChineseWall 模型，以及信息流模型 (Information FlowModel)、 非干涉模型 (Noninterference Model)、 格子模型 (Lattice Model)、Brewer and Nash模型和 Graham-Denning模型等。这里简要介绍典型的五种安全模型。

2.1 状态机模型 (State Machine Model)

  • 状态机模型描述了一种无论处于何种状态都是安全的系统。
  • 状态机模型中一个状态是安全，如果所有迁移中允许并且不危及系统使之处于不安全状态，则系统执行了一个安全状态模型。

2.2 Bell-LaPadula 模型

  • Bell-LaPadula 模型是 David Bell 和 Len LaPadula 提出的第一个正式的安全模型。
  • 模型基本原理
    • 模型使用主体、客体、访问操作（读、写、读/写）以及安全级别这些概念。
    • 当主体和客体位于不同的安全级别时，主体对客体就存在一定的访问限制。
  • 模型安全规则
    • 简单安全规则 (Simple Security Rule): 安全级别低的主体不能读安全级别高的客体(No Read Up);
    • 星属性安全规则 (Star Security Property): 安全级别高的主体不能往低级别的客体写(No Write Down);
    • 强星属性安全规则 (Strong Star Security Property): 不允许对另一级别进行读写
    • 自主安全规则 (Discretionary Security Property)：使用访问控制矩阵来定义说明自主存取控制。

2.3 Biba 模型

2.3.1 模型基本原理

  • Biba 模型是 Bell-LaPadula 模型之后开发的，它跟 Bell-LaPadula 模型相似，被用于解决访问控制问题。
  • Biba 模型基于层次化的安全级别，将完整性威胁分为来源于系统内部威胁和外部威胁。

2.3.2 模型安全规则

  • 星完整性规则(*-integrity Axiom): 表示完整性级别低的主体不能对完整性级别高的客体写数据；
  • 简单完整性规则 (Simple Integrity Axiom): 表示完整性级别高的主体不能从完整性级别低的客体读取数据；
  • 调用属性规则 (Invocation Property): 表示一个完整性级别低的主体不能从级别高的客体调用程序或服务。

2.4 Clark-Wilson(CWM)模型

2.4.1 模型基本原理

  • Clark-Wilson 模型由 David Clark 和 David Wilson 于 1987 年提出，用于银行系统中以保证数据安全性。
  • 模型定义了对于变换过程中的应用相关验证。

2.4.2 模型安全规则

  • 需要进行完整性保护的客体称之为 CDI，不需要进行完整性保护的客体称之为 UD8；
  • 完整性验证过程 (Integrity Validation Procedure, IVP)：确认限制数据项处于一种有效状态，如果 IVP检 验C D I符合完整性约束，则系统处于一个有效状态；
  • 转换过程 (Transformation Procedures, TP)：将数据从一种有效状态改变至另一种有效状态；
  • 为了确保对 CDI 的 TP 是有效的，则需要授权 User 做 TP 的认证；
  • 为了防止合法用户对 CDI 做非法或错误操作，将 TP 过程分为多个子过程，将每个子过程授权给不同的 User；
  • 但是如果 TP 的每个子过程被授权的 User 之间存在某种利益同盟，则可能存在欺骗。从而使得 CDI 的完整性得不到保护。

2.4.3 模型特征

CWM 的主要特征是：

  1. 采用 Subject/Program/Object 三元素的组成方式。 Subject要访问 Object 只能通过 Program 进行；
  2. 权限分离原则：将要害功能分为有 2 个或多个 Subject 完成，防止已授权用户进行未授权的修改；
  3. 要求具有审计能力 (Auditing)。

2.5 Chinese Wall 模型

2.5.1 模型基本原理

Chinese Wall 模型是一种安全模型，最初由 Brewer 和 Nash 提出，用于多边安全系统。该模型通过行政规定和划分，内部监控、IT 系统等手段防止各部门之间出现有损客户利益的冲突事件。

2.5.2 模型的安全规则

  • 与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问。
  • 属于一个完全不同的利益冲突组的可以访问。
  • 主体能够对一个客体进行写的前提是主体未对任何属于其他公司数据集进行过访问。

3 系统安全体系架构规划框架

3.1 安全技术体系架构

安全技术体系架构的目标是建立可持续改进的安全技术体系架构的能力，信息技术系统千变万化，有各种各样的分类方式，为从技术角度建立一个通用的对象分析模型。

3.2 信息系统安全体系规划

信息系统安全体系规划是一个非常细致和非常重要的工作，首先需要对企业信息化发展的历史情况进行深入和全面的调研，并针对信息系统安全的主要内容进行整体的发展规划工作。

信息系统安全体系主要是由技术体系、组织机构体系和管理体系三部分共同构成的。

  • 技术体系是全面提供信息系统安全保护的技术保障系统，该体系由物理安全技术和系统安
    全技术两大类构成。
  • 组织体系是信息系统的组织保障系统，由机构、岗位和人事三个模块构成。
  • 管理体系由法律管理、制度管理和培训管理三部分组成。

3.3 信息系统安全规划框架

  1. 信息系统安全规划依托企业信息化战略规划
  2. 信息系统安全规划需要围绕技术安全、管理安全、组织安全考虑
  3. 信息系统安全规划以信息系统与信息资源的安全保护为核心

4 信息安全整体架构设计 (WPDRRC 模型)

4.1 WPDRRC 信息安全体系架构模型

WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack) 信息安全模型是我国“八六三”信息安全专家组提出的适合中国国情的信息系统安全保障体系建设模型。

  • WPDRRC模型是信息安全体系模型，包括预警(Waring Protect/Detect)、保护(React)、检测(Detect)、响应(Restore)、恢复(Recover)和反击(Counter)六个环节。

WPDRRC 模型有 6 个环节和 3 大要素。

6 个环节包括：预警、保护、检测、响应、恢复和反击，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。

  • W: 预警
  • P: 防护通常是通过采用成熟的信息安全技术及方法来实现网络与信息的安全。
  • D: 检测通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。
  • R: 响应是指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态
  • R: 恢复灾难恢复系统是当前网络、数据、服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。
  • C: 反击是指采用一切可能的高新技术手段，侦察、提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。

3 大要素包括：人员、策略和技术。人员是核心，策略是桥梁，技术是保证，落实在 WPDRRC 的 6 个环节的各个方面，将安全策预警略变为安全现实。

4.2 信息安全体系架构设计

要设计一个信息安全体系架构，应当选择合适的安全体系结构模型。信息系统安全设计重点考虑两个方面；其一是系统安全保障体系；其二是信息安全体系架构。

4.2.1 系统安全保障体系

安全保障体系是由安全服务、协议层次和系统单元等三个层面组成，且每个层都涵盖了安全管理的内容。

系统安全保障体系设计工作主要考虑以下几点：

  1. 安全区域策略的确定：根据安全区域的划分，主管部门应制定针对性的安全策略。
  2. 统一配置和管理防病毒系统：主管部门应当建立整体防御策略，以实现统一的配置和管理。
  3. 网络安全管理：在网络安全中，除了采用一些技术措施之外，加强网络安全管理，制定有关规章制度。在安全管理中，任何的安全保障措施，最终要落实到具体的管理规章制度以及具体的管理人员职责上，并通过管理人员的工作得到实现。

4.2.2 信息安全体系架构

具体在安全控制系统，我们可以从物理安全、系统安全、网络安全、应用安全和管理安全等5个方面开展分析和设计工作。

4.2.2.1 物理安全

保证计算机信息系统各种设备的物理安全是保障整个网络系统安全的前提。物理安全是保护计算机网络设备、设施以及其他媒体免受地震、水灾、火灾等环境事故以及人为操作失误或错误及各种计算机犯罪行为导致的破坏过程。它主要包括：环境安全、设备安全、媒体安全等。

4.2.2.2 系统安全

系统安全主要是指对信息系统组成中各个部件的安全要求。系统安全是系统整体安全的基础。它主要包括：网络结构安全、操作系统安全和应用系统安全。

4.2.2.3 网络安全

网络安全是整个安全解决方案的关键。它主要包括：访问控制、通信保密、入侵检测、网络安全扫描系统和防病毒等。

4.2.2.4 应用安全

应用安全主要是指多个用户使用网络系统时，对共享资源和信息存储操作所带来的安全问题。它主要包括资源共享和信息存储两个方面。

4.2.2.5 安全管理

安全管理主要体现在三个方面。其一是制定健全的安全管理体制。制定健全安全管理体制将是网络安全得以实现的重要保证，可以根据自身的实际情况制定如安全操作流程、安全事故的奖罚制度以及任命安全管理人员全权负责监督和指导；其二是构建安全管理平台。构建安全管理平台将会降低许多因为无意的人为因素而造成的风险。构建安全管理平台可从技术上进行防护，如：组成安全管理子网、安装集中统一的安全管理软件、网络设备管理系统以及网络安全设备统一管理软件等，通过安全管理平台实现全网的安全管理；其三是增强人员的安全防范意识。应该经常对单位员工进行网络安全防范意识的培训，全面提高员工的整体安全方法意识。

5 网络安全体系架构设计

5.1 OSI 的安全体系架构概述

5.1.1 OSI 概述

  • OSI (Open System Interconnection/Reference Mode, OSI/RM) 是国际标准化组织制定的开放式通信系统互联模型。
  • OSI 目的在于保证开放系统进程与进程之间远距离安全交换信息。这些标准在参考模型的框架内，建立起一些指导原则与约束条件，从而提供了解决开放互联系统中安全问题的一致性方法。

5.1.2 OSI 安全架构

  • OSI 定义了 7 层协议,最合适配置安全服务的是在物理层、网络层、运输层及应用层上。
  • OSI 安全架构包括五类安全服务：鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。
  • OSI 定义分层多点安全技术体系架构，也称为深度防御安全技术体系架构，它通过以下三种方式将防御能力分布至整个信息系统中。

5.1.2.1 多层技术防御

  • 在对手可以从内部或外部多点攻击一个目标的前提下，多点技术防御通过对以下多个防御核心区域的防御达到抵御所有方式的攻击目的。
  • 多层技术防御通过多个防御机制来抵御攻击，包括网络和基础设施保护、边界防御、计算环境防御等。

5.1.2.2 分层技术防御

一个有效的措施是在对手和目标间使用多个防御机制。为了减少这些攻击成功的可能性和对成功攻击的可承担性，每种机制应代表一种唯一的障碍并同时包括保护和检测方法。例如，在外部和内部边界同时使用嵌套的防火墙并配合以入侵检测就是分层技术防御的一个实例。

5.1.2.3 支撑性基础设施

支撑性基础设施为网络、边界和计算环境中信息保障机制运行基础的支撑性基础设施，包括公钥基础设施以及检测和响应基础设施。

  1. 公钥基础设施。提供一种通用的联合处理方式，以便安全地创建、分发和管理公钥证书和传统的对称密钥，使它们能够为网络、边界和计算环境提供安全服务。
  2. 检测和响应基础设施。检测和响应基础设施能够迅速检测并响应入侵行为。

这里必须注意的是，信息系统的安全保障不仅仅依赖于技术，还需要集成的技术和非技术防御手段。一个可接受级别的信息保障依赖于人员、管理、技术和过程的综合。

5.2 认证框架

  1. 认证框架概述
    • 认证框架的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。
    • 鉴别提供实体声称其身份的保证，只有定于主体和验证者的关系背景下，鉴别才有意义。
  2. 认证信息类型
    • 鉴别信息类型有交换鉴别信息、申请鉴别信息和验证鉴别信息。
  3. 鉴别阶段
    • 鉴别服务分为以下阶段：安装阶段、修改鉴别信息阶段、分发阶段、获取阶段、传送阶段、验证阶段、停活阶段、重新激活阶段、取消安装阶段。

5.3 访问控制框架

访问控制 (Access Control) 决定开放系统中允许使用哪些资源、在什么地方和什么时间使用。

  • ACI (访问控制信息)是用于访问控制目的的任何信息，其中包括上下文信息。
  • ADI (访问控制判决信息)是在做出一个特定的访问控制判决时可供 ADF 使用的部分(或全部) ACI。
  • ADF (访问控制判决功能)是一种特定功能，它通过对访问请求、 ADI 以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。
  • AEF (访问控制实施功能)确保只有对目标允许的访问才由发起者执行。

涉及访问控制的有发起者、AEF、ADF 和目标。发起者代表访问或试图访问目标的人和基于计算机的实体。目标代表被试图访问或由发起者访问的，基于计算机或通信的实体。

5.4 机密性框架

5.4.1 机密性概述

机密性 (Confidentiality) 服务的目的是确保信息仅仅是对被授权者可用。信息的保护是确保数据限制于授权者获得。

5.4.2 机密性机制

数据的机密性可以依赖于所驻留和传输的媒体。因此，存储数据的机密性能通过使用隐藏数据语义(如加密)或将数据分片的机制来保证。

  1. 通过禁止访问提供机密性
  2. 通过加密提供机密性：目的是防止数据泄露在传输或存储中。加密机制分为基于对称的加密机制和基于非对称加密的机密机制。

5.5 完整性框架

5.5.1 完整性概述

完整性框架的目的是通过阻止威胁或探测威胁，保护可能遭到不同方式危害的数据完整性和数据相关属性完整性。

5.5.2 完整性机制的类型

由于保护数据的能力与正在使用的媒体有关，对于不同的媒体，数据完整性保护机制是有区别的，可概括为以下两种情况。

  • 阻止对媒体访问的机制：包括物理隔离的不受干扰的信道、路由控制、访问控制。
  • 用以探测对数据或数据项序列的非授权修改的机制：未授权修改包括未授权数据创建、数据删除以及数据重复。

5.6 抗抵赖框架

5.6.1 抗抵赖概述

抗抵赖 (Non-repudiation) 服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。

抗抵赖服务提供下列可在试图抵赖的事件中使用的设备：证据生成、证据记录、验证生成的证据、证据的恢复和重验。

抗抵赖过程的四个独立阶段：

  1. 证据生成：证据生成请求者请求证据生成者为事件或行为生成证据。
  2. 证据传输、存储及恢复：证据在实体间传输或从存储器取出来或传到存储器。
  3. 证据验证：证据在使用者的请求下被证据验证者验证。
  4. 解决纠纷

6 数据库系统的安全设计

  • 数据库的安全问题已经成为信息系统最为关键的问题之一。
  • 数据库的安全策略应确保数据不会被有意地攻击或无意地破坏，不会发生数据的外泄、丢失和毁损。

下面分别从数据库安全设计的评估标准和完整性设计两方面进行讨论。

6.1 数据库安全设计的评估标准

  • 随着人们对安全问题的认识和对安全产品的要求不断提高，计算机安全技术方面逐步建立了一套安全评估标准。
  • 1985 年美国国防部颁布的可信计算机系统评估标准 (TCSEC) 是最重要的标准之一。
  • 1991 年，美国国家计算机安全中心 (NCSC) 颁布了“可信计算机评估标准关于可信数据库管理系统的解释 (TDI)”。
  • 1994 年 2 月，我国发布了《中华人民共和国计算机信息系统安全保护条例》。

在 TCSEC 中，将安全系统分为 4 大类 7 个等级。TDI 是 TCSEC 在数据库管理系统方面的扩充和解释，并从安全策略、责任、保护和文档 4 个方面进一步描述了每级的安全标准。按照 TCSEC 标准，

  • D 类产品是基本没有安全保护措施的产品，
  • C 类产品只提供了安全保护措施，一般不称为安全产品。
  • B 类以上产品是实行强制存取控制的产品，也是真正意义上的安全产品。所谓安全产品均是指安全级别在 B1 以上的产品，而安全数据库研究原型一般是指安全级别在 B1 级以上的以科研为目的，尚未产品化的数据库管理系统原型。

6.2 数据库的完整性设计

数据库完整性是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。

6.2.1 数据库完整性设计原则

在实施数据库完整性设计时，需要把握以下基本原则：

  1. 根据数据库约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。
  2. 实体完整性约束、引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。
  3. 要慎用目前主流 DBMS 都支持的触发器功能，一方面由于触发器的性能开销较大；另一方面，触发器的多级触发难以控制，容易发生错误，非用不可时，最好使用 Before 或者 After 型语句级触发器。
  4. 在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义和含义的英文单词、缩写词、表名、列名及下画线等组合，使其易于识别和记忆。
  5. 要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束的冲突和对性能的影响。
  6. 要有专职的数据库设计小组，自始至终负责数据库的分析、设计、测试、实施及早期维护。
  7. 应采用合适的 CASE 工具来降低数据库设计各阶段的工作量。

6.2.2 数据库完整性的作用

数据库完整性对于数据库应用系统非常关键，其作用主要体现在以下几个方面：

  1. 数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合法之的数据。
  2. 利用基于 DBMS 的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以降低应用程序的复杂性，提高应用程序的运行效率。
  3. 合理的数据库完整性约束，能够同时兼顾数据库的完整性和系统的效能。
  4. 在应用软件的功能测试中，完善的数据库完整性有助于尽早发现应用软件的错误。
  5. 数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。

6.2.3 数据库完整性设计示例

基于 DBMS 的数据库完整性设计大体分为以下几个阶段。

  1. 需求分析阶段
    • 经过系统分析员、数据库分析员和用户的共同努力，确定系统模型中应该包含的对象，如人事及工资管理系统中的部门、员工和经理等，以及各种业务规则。
  2. 概念结构设计阶段
    • 概念结构设计阶段是将依据需求分析的结果转换成一个独立于具体 DBMS 的概念模型，即实体关系图 (Entity-Relationship Diagram,ERD)。
  3. 逻辑结构设计阶段
    • 此阶段就是将概念结构转换为某个 DBMS 所支持的数据模型，并对其进行优化，包括对关系模型的规范化

7 系统架构的脆弱性分析

7.1 概述

信息系统受到各种安全威胁的根本原因就是系统存在脆弱性。脆弱性分析是分析信息系统中产生脆弱性的原因、脆弱性可能造成的影响、如何利用脆弱性进行攻击、如何修补脆弱性等问题。

从技术角度而言，漏洞的来源主要有以下几个方面:

  • 软件设计时的瑕疵：协议设计存在瑕疵。
  • 软件本身的弱点：实现方式可能引入漏洞。
  • 软件本身的瑕疵：未进行数据内容和大小检查。
  • 系统和网络的错误配置。

7.2 软件脆弱性

7.2.1 软件脆弱性定义

软件脆弱性是指由软件缺陷的客观存在所形成的一个可以被攻击者利用的实例，每个脆弱性都由至少一个软件缺陷引起，但是一个软件缺陷也可能不产生任何脆弱性，而且不同的软件缺陷可能导致相同的脆弱性。软件脆弱性就是软件规范、开发或配置中错误的实例，其执行结果将会违反安全策略。

7.2.2 软件脆弱性的特点和分类

软件脆弱性有以下特点：

  1. 脆弱性是软件系统中隐藏的一个弱点。
  2. 在软件开发过程中，自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源。
  3. 与具体的系统环境密切相关，系统环境的任何差异都可能导致不同的脆弱性问题。
  4. 目的脆弱性得到修补或纠正的同时可能引入新的脆弱性，因此脆弱性会长期存在。

软件脆弱性可以从不同视角进行分类，比较典型的分类法有：

  • ISSO 分类法
    • 主要是面向信息系统的安全和隐私方面分类的，其目的是帮助信息系统管理人员理解安全问题，并为提高系统安全性提供相应信息。
  • PA 分类法
    • 主要研究操作系统中与安全保护相关的缺陷，其目标是希望能够让缺乏计算机安全领域知识的人可以利用模式指导的方法来发现计算机安全问题。
  • Landwehr 分类法
    • 提出了基于缺陷的起因(有意的或无意的)，引入的时间(开发阶段、维护阶段或者运行阶段)和分布的位置 (软件或硬件)三个维度的分类。
  • Aslam 分类法
    • 针对 Unix 操作系统中的安全故障，从软件生命周期的角度将其分为编码故障和突发故障两大类。
  • Bishop 分类法
    • 针对信息安全领域的一种分类方法，它描述了一种针对 Unix 和网络相关脆弱性的分类方法
  • IBM 分类法
    • 以 Landwehr 分类法为分类框架的基础，以新出现的安全缺陷对其进行扩充和改造以适应现今脆弱性的变化。

7.2.3 软件脆弱性的生命周期

软件脆弱性的生命周期分为三个阶段：引入软件脆弱性的原因、软件脆弱性的传播、软件脆弱性的修补。

7.2.4 软件脆弱性的分析方法

软件脆弱性分析是对软件脆弱性进行研究，总结软件脆弱性的发生机理、发展规律、表征特点、预防措施以及危害效果等多方面的知识。

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

  1. 分析软件故障现象，分析故障的技术本质，总结脆弱性模式。
  2. 分析软件开发，发现安全管理和技术的薄弱环节，提高软件安全性。
  3. 分析软件使用，发现其脆弱性，采取相应措施，避免脆弱性转化为安全故障。

软件脆弱性分析首先要明确分析对象，脆弱性分析对象可以分为两类：脆弱性数据和软件系统。

脆弱性数据是关于安全故障的现象、原因以及影响等基本信息记录，反映了脆弱性外在表现的原始状态，是脆弱性分析的基础。

总之，软件的脆弱性分析是软件开发过程中必不可少的一项工作，尤其是在安全攸关系统中，脆弱性分析工作尤为重要，一旦缺乏有效的脆弱性预防措施，会引发重大灾难性事件。

7.3 典型软件架构的脆弱性分析

软件脆弱性包括了软件设计脆弱性和软件结构脆弱性，软件架构的脆弱性是结构脆弱性的一种。

7.3.1 分层架构

层间的脆弱性主要表现在两个方面：

  • 层间的脆弱性：一旦某个底层发生错误，那么整个程序将会无法正常运行，如产生一些数据溢出，空指针、空对象的安全性问题，也有可能会得出错误的结果。
  • 层间通信的脆弱性。：层间通信的脆弱性。将系统隔离为多个相对独立的层，这就要求在层与层之间引入通
    信机制，本来“直来直去”的操作现在要层层传递，势必造成性能下降。

7.3.2 C/S 架构

C/S 架构的脆弱性主要表现在以下几个方面：

  • 客户端软件的脆弱性。只要安装了特定客户端软件的用户才可以使用 C/S 架构系统，正因为在用户计算机上安装了客户端软件，所以这个系统就面临着程序被分析、数据被截取的安全隐患。
  • 网络开放性的脆弱性：C/S 系统采用二层结构。
  • 网络协议的脆弱性：C/S 架构使用多种网络协议。C/S架构不便于随时与用户交流(主要是不便于数据包共享),并且 C/S 架构软件在保护数据的安全性方面有着先天的弊端。

7.3.3 B/S 架构

B/S 架构的脆弱性主要表现在：系统如果使用 HTTP 协议， B/S 架构相对 C/S 架构而言更容易被病毒入侵，虽然最新的 HTTP 协议在安全性方面有所提升，但还是弱于 C/S。

7.3.4 事件驱动架构

事件驱动架构的脆弱性主要表现在：

  1. 组件的脆弱性。组件削弱了自身对系统的控制能力，一个组件触发事件，并不能确定响应该事件的其他组件及各组建的执行顺序。
  2. 组件间交换数据的脆弱性。组件不能很好地解决数据交换问题，事件触发时，一个组件有可能需要将参数传递给另一个组件，而数据量很大的时候，如何有效传递是一个脆弱性问题。
  3. 组件间逻辑关系的脆弱性。事件架构使系统中各组件的逻辑关系变得更加复杂。
  4. 事件驱动容易进入死循环，这是由编程逻辑决定的。
  5. 高并发的脆弱性。虽然事件驱动可实现有效利用 CPU 资源，但是存在高并发事件处理造成的系统响应问题，而且，高并发容易导致系统数据不正确、丢失数据等现象。
  6. 固定流程的脆弱性。因为事件驱动的可响应流程基本都是固定的，如果操作不当，容易引发安全问题。

7.3.5 MVC 架构

MVC 架构的脆弱性主要表现在：

  1. MVC 架构的复杂性带来脆弱性。 MVC 架构增加了系统结构和实现的复杂性。比如说一个简单的界面，如果严格遵循 MVC 方式，使得模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
  2. 视图与控制器间紧密连接的脆弱性。视图与控制器是相互分离但确是联系紧密的部件，没有控制器的存在，视图应用是很有限的。反之亦然，这样就妨碍了它们的独立重用。
  3. 视图对模型数据的低效率访问的脆弱性。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。

可以说， MVC 架构的脆弱性主要表现在缺少对调用者进行安全验证的方式和数据传输不够安全等两个方面，这些不足也是导致 MVC 存在比较大的脆弱性、容易招致攻击的主要原因。

7.3.6 微内核架构

微内核架构的脆弱性主要表现：

  • 微内核架构难以进行良好的整体化优化。
  • 微内核系统的进程间通信开销也较单一内核系统要大得多。从整体上看，在当前硬件条件下，微内核在效率上的损失小于其在结构上获得的收益。
  • 通信损失率高。微内核把系统分为各个小的功能块，从而降低了设计难度，系统的维护与修改也容易，但通信带来的效率损失是一个问题。

7.3.7 微服务架构

微服务架构的脆弱性主要表现：

  • 开发人员需处理分布式系统复杂结构。
  • 开发人员要设计服务之间的通信机制，通过写代码来处理消息传递中速度过慢或者不可用等局部实效问题。
  • 服务管理的复杂性，在生产环境中要管理多个不同的服务实例，这意味着开发团队需要全局统筹。

8 安全架构设计案例分析

8.1 电子商品系统的安全性分析

本节以一个具体的电子商务系统——高性能的RADIUS, 来阐明电子商务系统的安全设计的基本原理和设计方法。

8.1.1 原理介绍

认证、授权和审计 (Authentication Authorization and Accounting,AAA) 是运行于宽带网络接入服务器上的客户端程序。 A A A提供了一个用来对认证、授权和审计三种安全功能进行配置的一致的框架。

8.1.2 软件架构设计

RADIUS 软件架构分为三个层面：协议逻辑层、业务逻辑层和数据逻辑层。

RADIUS 软件分层架构的实现，一是对软件风险进行了深入的分析，并且在软件实现的过程中得到更多的体现；二是可以构建一个或多个重用的构件单元，同时也可以继承原来的成果。

8.2 基于混合云的工业安全架构设计

  • 混合云架构设计：被大型集团企业面临的主要任务和问题。大型企业希望通过云计算平台实现异构的计算、生产、制造、运营和数据处理等，并确保企业业务的安全性、保密性和数据的隐私。
  • 混合云架构的优势：混合云架构结合了私有云和公有云，企业可以在私有云中处理敏感数据，在公有云中处理非敏感数据，从而实现资源的最优配置和成本的降低。
  • 混合云架构设计的目标：设计一种安全、可靠、高效的混合云架构，以满足企业对数据安全、业务连续性和系统可扩展性的需求。
  • 混合云架构设计的挑战：如何在保证数据安全和隐私的前提下，实现数据在私有云和公有云之间的无缝迁移和共享。
  • 混合云架构设计的解决方案：采用分层的安全架构设计，包括设备安全、网络安全、控制安全、应用安全和数据安全。
    • 设备安全：确保智能设备（如工业机器人、智能传感器等）的安全性，防止未经授权的访问和操作。
    • 网络安全：保护网络系统免受攻击，确保数据传输的安全性和完整性。
    • 控制安全：确保控制系统的安全性，防止恶意软件和病毒的侵入。
    • 应用安全：保护应用程序免受攻击，确保应用程序的安全性和可靠性。
    • 数据安全：确保数据的安全性和隐私性，防止数据泄露和未经授权的访问。

参考书籍

软件架构理论与实践-机械工业出版社 2019 年出版的软件架构书籍