系统架构-安全架构设计

概述

对于信息系统来说，威胁有：物理环境（最基础）、通信链路、网络系统、操作系统、应用系统、管理系统

• 物理安全：系统所用设备的威胁，如自然灾害、电源故障
• 通信链路安全：在传输线路上安装窃听装置，或对通信链路进行干扰
• 网络安全：通过技术手段窃取互联网信息
• 操作系统安全：对系统平台的软件或硬件芯片中植入威胁
• 应用系统安全：对于网络服务或用户业务系统安全的威胁
• 管理系统安全：由于人员管理上疏忽而引发人为的安全漏洞

具体安全威胁：

• 信息泄露：信息机密
• 破坏信息的完整性：被非授权地进行增删、修改或破坏
• 拒绝服务：Dos攻击，大量访问导致合法访问被无条件阻止
• 非法使用（非授权访问）：被非授权的人或非授权的方式使用
• 窃听：窃取信息资源中的敏感信息，属于被动攻击
• 业务流分析：通过长期监听，利用统计分析方法对信息进行研究
• 假冒：通过欺骗信息系统达到非法用户冒充成为合法用户
• 旁路控制：利用系统薄弱之处获得非授权的权利
• 授权侵犯：被授权地使用某一信息资源，却用于其他非授权的目的
• 特洛伊木马：软件中含有不易察觉或无害程序段，常用于监听
• 陷阱门：后门，在系统中设置机关，使当提供特定的输入数据时，允许违反安全策略
• 抵赖：来自用户的攻击，如否认自己发送过消息
• 重放：所截获某次合法的通信数据进行备份，非法的重新发送备份
• 计算机病毒：主动攻击，传染性强，破坏性强
• 人员渎职：授权人将信息泄露给非授权人
• 媒体废弃：信息从废弃磁盘或打印过的存储介质中获得
• 物理侵入：侵入者通过物理控制而获得对系统的访问
• 窃取：重要的安全物品，如盗取令牌
• 业务欺骗：某伪系统欺骗合法用户或系统资源放弃敏感信息

安全架构是架构面向安全性方向上的一种细分，通常有三道安全防线：产品安全架构、安全技术体系架构、审计架构。

1. 产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。从源头打造自身安全的产品
2. 安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系，构建安全基础设施、安全工具和技术、安全组件与支持系统
3. 设计架构：独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险 

安全模型

信息系统的安全目标是控制和管理主体（用户和进程）对客体（数据和程序）的访问

安全模型准确得描述安全的重要方面及其与系统行为的关系

安全策略是从安全角度为系统整体和构成它的组件提出基本的目标

分类：

1. 机密性：访问控制：MAC强制（BLP、Chinese Wall）、DAC自主、RBAC角色（最常用，根据角色赋予相应的权限）
2. 完整性：Biba、Clark-Wilson 

状态机模型

一种无论处于何种状态都是安全的系统。用状态语言将安全系统描述成抽象的状态机，用状态变量表述系统的状态，用转换规则描述变量变化的过程

BLP模型

Bell -LaPadula 模型，主要保护信息的机密性，不能保证信息完整性

使用主体、客体、访问操作（读、写、读/写）以及安全级别这些概念

安全规则：

1. 简单安全规则：安全级别的主体不能读安全级别高的客体：只能下读
2. 星属性安全规则： 安全级别高的主体不能往级别低的客体写：只能上写（为了保证级别高的主体的信息不流入级别低的客体）
3. 强星属性安全规则：不允许对另一级别进行读写
4. 自主安全规则：使用访问控制矩阵来定义说明自由存取控制

Biba模型

Biba模型不关心信息机密性的安全级别，它的访问控制不是建立在安全级别上，而是建立在完整性级别上

完整性的三个目标：保护数据不被未授权用户更改；保护数据不被授权用户越权修改；维持数据内部和外部的一致性

安全规则：

• 星完整性规则：完整性级别低的主体不能对完整性级别高的客体写数据：只能下写
• 简单完整性规则：完整性级别高的主体不能从完整性级别低的客体读数据：只能上读（防止高完整性信息被低完整性信息wuran）
• 调用属性规则：一个完整性级别低的主体不能从级别高的客体调用程序或服务

CWM模型

 Clark-Wilson模型是一种将完整性目标、策略和机制融为一体的模型。

CWM提出职责隔离目标：体现用户完整性

CWM提出应用相关的完整性验证进程：保证数据完整性

CWM定义了变换过程的应用相关验证：建立过程完整性

Chinese Wall模型

又名Brew and Nash模型，通过行政规定和划分、内部监控、IT系统等手段防止各部门之间出现有损客户利益的利益冲突。Chinese Wall安全策略的基础是客户访问的信息不会与当前他们可支配的信息产生冲突。多应用于金融领域。

安全规则：

• 与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问
• 属于一个完全不同的利益冲突组的可以访问
• 主体若未对任何属于其他公司数据集进行过访问，则可以“写”相关客体

定理：

1. 一个主体一旦访问过一个客体，则该主体只能访问位于同一公司数据集的客体或在不用利益组的客体
2. 在一个利益冲突组中，一个主体最多只能访问一个公司数据集

信息安全整体架构设计

WPDRRC模型

WPDRRC模型有六个环节：Warning（预警）、Protect（保护）、检测（Detect）、React（响应）、Restore（恢复）、Counterattack（反击），它们具有较强的时序性和动态性

3大要素：人员、策略、技术。人员是核心，策略是桥梁，技术是保证

整体架构设计

重点考虑两个方面：系统安全保障体系；信息安全体系架构

系统安全保障体系：

由安全服务、协议层次和系统单元三个层面组成，具体工作中要考虑以下几点：

• 安全区域策略的确定
• 同一配置和管理防病毒系统
• 网络安全管理

信息安全体系架构：具体在安全控制系统中，有以下5各方面：

1. 物理安全
2. 系统安全
3. 网络安全
4. 应用安全
5. 安全管理 

网络安全体系架构设计 

一般包括5类安全服务：鉴别、访问控制、数据机密性、数据完整性和抗抵赖性

OSI定义分层多点安全技术体系架构

1. 多点技术防御：在对手可以从内部或外部多点攻击一个目标的前提下，部署安全防御
2. 分层技术防御：在对手和目标间使用多个防御机制
3. 支撑性基础设施：如公钥基础设施以及检测和响应基础设施

鉴别

基本目的：防止其他实体占用和独立操作被鉴别实体的身份。实体由申请者来代表，实体为验证者提供数据项来源

访问控制

决定开放系统环境中允许使用哪些资源、在什么地方合适阻止未授权访问的过程

数据机密性

依赖于所驻留和传输的媒体。

存储数据的机密性能通过隐藏数据语义（加密）或将数据分片来保证。

传输数据的机密性能通过禁止访问、隐藏数据语义或分散数据来保证

数据完整性

对于不同的媒体，数据完整性保护机制主要分为以下两个情况：

1. 阻止对媒体访问的机制，包括物理的隔离
2. 用以探测对数据或数据项序列的非授权修改的机制

抗抵赖服务

一般使用数字签名，包括证据生成；证据传输、存储及恢复；证据验证和解决纠纷 

数据库系统的安全设计

数据库完整性

数据库完整性是指数据的正确性和相容性，由完整性约束来完成。

数据库完整性约束可以通过DBMS或应用程序来实现

基本原则：

1. 根据数据库完整性约束的类型确定其实现的系统层次和方式 
2. 实体完整性约束、引用完整性约束时数据库中最重要的完整性约束
3. 要慎用目前主流DBMS都支持的触发器功能
4. 在需求分析阶段就必须指定完整性约束的命名规范，尽量使用有意义的英文单词
5. 根据业务规则对数据库完整性进行细致的测试
6. 要有专职的数据库设计小组
7. 采用合适的CASE工具来降低数据库设计各阶段的工作量

数据库完整性约束可分为6类：列级静态约束、元组静态约束（行）、关系级静态约束（表）、列级动态约束、元组级动态约束和关系级动态约束

系统架构的脆弱性分析 

脆弱性分析主要是分析信息系统中产生脆弱性的根源

从技术角度而言：软件设计时的瑕疵、软件实现中的弱点、软件本身的瑕疵、系统和网络的错误配置

脆弱性的四个特点：

1. 脆弱性是软件系统隐藏的弱点，本身不会引起危害
2. 大多数脆弱性来源于自觉或不自觉的引入逻辑错误
3. 系统环境的任何差异都有可能导致不同的脆弱性问题
4. 旧的脆弱性得到修补或纠正的同时可能会引入新的脆弱性 

脆弱性的声明周期：

• 引入阶段
• 产生破坏效果阶段
• 修补阶段 

典型软件架构脆弱性分析

分层架构： 

1. 层间的脆弱性，下层一旦发生错误，导致整个程序将会无法正常允许
2. 层间通信的脆弱性：层层通信势必导致性能下降

C/S架构：

1. 客户端软件脆弱性：客户端程序容易面临被分析、数据截取的安全隐患
2. 网络开放性：如果用二层C/S结构，客户端可以直接读取服务器端的数据，会给系统带来安全隐患
3. 网络协议：不便于随时与用户交流

B/S架构：

1. 如果使用HTTP协议，没有安全保护，容易被病毒入侵

事件驱动架构：

1. 组件的脆弱性：一个组件被触发了，不能确定响应该事件的其他组件及各组件间的执行顺序
2. 组件间交换数据的脆弱性：组件不能很好地解决数据交换的问题
3. 组件间逻辑关系的脆弱性
4. 事件驱动容易进入死循环：由编程逻辑决定
5. 高并发的脆弱性：高并发事件处理可能造成系统响应问题，也容易导致系统数据不正确、丢失数据等现象
6. 固定流程的脆弱性：事件驱动的可响应流程基本固定

MVC架构：

1. 结构复杂性带来的脆弱
2. 视图与控制器间紧密连接的脆弱性：视图与控制器高度绑定，妨碍了它们的独立重用
3. 视图对模型数据的低效率访问 

微内核架构：

1. 难以进行良好的整体化优化，微内核的核心态只实现了最基本的系统操作，系统难以进行良好的整体优化
2. 进程间通信开销也较单一内核系统大得多
3. 通信损失率高 

微服务架构：

1. 开发人员需要处理分布式的复杂结构
2. 服务之间的复杂通信机制
3. 服务管理的复杂性 

图片来源于网络