安全架构设计理论与实践
1 信息安全面临的威胁
1.1 信息系统安全威胁的来源
威胁可以来源于物理环境、通信链路、网络系统、操作系统、应用系统、管理系统。
1.2 网络与信息安全风险类别
网络与信息安全风险类别可分为认为蓄意破坏（被动攻击，主动攻击）、灾害性攻击、系统故障、人员无意识行为。
如图，网络与信息安全的风险类别：
1.3 常见的安全威胁
(1) 信息泄露 ：信息被泄露或透露给某个非授权的实体。
(2) 破坏信息的完整性 ：数据被非授权地进行增删、修改或破坏而受到损失。
(3) 拒绝服务 ：对信息或其他资源的合法访问被无条件地阻止。
(4) 非法使用(非授权访问) :某一资源被某个非授权的人或以非授权的方式使用。
(5) 窃听 ：用各种可能的合法或非法的手段窃取系统中的信息资源和敏感信息。例如对通信线路中传输的信号进行搭线监听，或者利用通信设备在工作过程中产生的电磁泄漏截取有用信息等。
(6) 业务流分析 ：通过对系统进行长期监听，利用统计分析方法对诸如通信频度、通信的信息流向、通信总量的变化等态势进行研究，从而发现有价值的信息和规律。
(7) 假冒 ：通过欺骗通信系统(或用户)达到非法用户冒充成为合法用户，或者特权小的用户冒充成为特权大的用户的目的。黑客大多是采用假冒进行攻击。
(8) 旁路控制 ：攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权。例如，攻击者通过各种攻击手段发现原本应保密，但是却又暴露出来的一些系统“特性”。利用这些“特性”,攻击者可以绕过防线守卫者侵入系统的内部。
(9) 授权侵犯 ：被授权以某一目的使用某一系统或资源的某个人，却将此权限用于其他非授权的目的，也称作“内部攻击”。
(10) 特洛伊木马 ：软件中含有一个察觉不出的或者无害的程序段，当它被执行时，会破坏用户的安全。这种应用程序称为特洛伊木马 。
(11) 陷阱门 ：在某个系统或某个部件中设置了“机关”,使得当提供特定的输入数据时，允许违反安全策略。
(12) 抵赖 ：这是一种来自用户的攻击，例如，否认自己曾经发布过的某条消息、伪造一份对方来信等。
(13) 重放 ：所截获的某次合法的通信数据备份，出于非法的目的而被重新发送。
(14) 计算机病毒 ：所谓计算机病毒，是一种在计算机系统运行过程中能够实现传染和侵害的功能程序。一种病毒通常含有两个功能：一种功能是对其他程序产生“感染”;另外一种或者是引发损坏功能或者是一种植入攻击的能力。
(15) 人员渎职 ：一个授权的人为了钱或利益、或由于粗心，将信息泄露给一个非授权的人。
(16) 媒体废弃 ：信息被从废弃的磁盘或打印过的存储介质中获得。
(17) 物理侵入 ：侵入者通过绕过物理控制而获得对系统的访问。
(18) 窃取 ：重要的安全物品，如令牌或身份卡被盗。
(19) 业务欺骗 ：某一伪系统或系统部件欺骗合法的用户或系统自愿地放弃敏感信息。
2 安全体系架构的范围
2.1 安全架构的范围
安全架构是架构面向安全性方向上的一种细分，比如细分领域含有运维架构、数据库架构等。如果安全性体现在产品上，那么， 通常的产品安全架构、安全技术体系架构和审计架构可组成三道安全防线 。
(1) 产品安全架构 ：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品。
(2) 安全技术体系架构 ：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力。
(3) 审计架构 ：独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险。
2.2 安全架构的特性
安全架构应具备可用性、完整性和机密性等特性 。
- 可用性 (Availability) 是指要防止系统的数据和资源丢失；
- 完整性(Integrity) 是指要防止系统的数据和资源在未经授权情况下被修改；
- 机密性 (Confidentiality) 是指要防止系统的数据和资源在未授权的情况下被披露。
2.3 安全技术架构
安全架构设计可以从安全技术的角度考虑，
主要包括：身份鉴别、访问控制、内容安全、冗余恢复、审计响应、恶意代码防范和密码技术 等。
3 与信息安全相关的国内外标准及组织
3.1 国外标准
(1)可信计算机系统评估准则 (Trusted Computer System Evaluation Criteria,TCSEC), 也称为“橘皮书”,1985年12月由美国国防部公布。
(2)信息技术安全评估准则 (Information Technology Security Evaluation Criteria,ITSEC),英、法、德、荷四国联合编制。
(3)加拿大可信计算机产品评估准则 (Canadian Trusted Computer Product Evaluation Criteria,CTCPEC), 加拿大，1993年。
(4)美国联邦准则 (FC),TCSEC 的升级版，美国，1992年。
(5)信息技术安全性评价通用准则 (The Common Criteria for Information Technology Security Evaluation), 由美国国家安全局和国家技术标准研究所联合加、英、法、德、荷等国编制，1993年。
(6)ISO/IEC 7498-2, 信息处理系统，开放系统互联，基本参考模型。第2部分：安全结构 (Information Processing System; Open System Intercommection; base reference model;Part2:SecurityArchitecture), 由国际标准化组织 (ISO) 发布，1989年。
(7)信息保障技术框架 (Infornation Assurance Technical Framework,IATF), 由美国国家安全局 (NSA) 发布，1999年。
(8)ISO/IEC 15408-1999, 信息技术安全技术信息技术安全性评估准则，替代原C C 标准。由国际标准化组织 (ISO) 发布，1999年。
(9)IEC 61508-2010, 电气/电子/可编程电子安全系统的功能安全 (Functional safety of electrical/ electronic/ programmable electronic safety-related systems), 由国际电工委员会发布，2010年。
3.2 国内标准
1)标准缩写含义
(1)GA: 国家安全行业标准规范。由中国安全技术防范认证中心组织发布。
(2)GB: 国家标准规范，由中国国家标准化管理委员会组织发布。
(3)GJB: 国家军用标准规范。
2)主要技术标准
(1)GB 15834-1995 信息处理数据加密实体鉴别机制。
(2)GA163-1997 计算机信息系统安全专用产品分类原则。
(3)GB17859-1999计算机信息系统安全保护等级划分准则。
(4)GB/T 9387.2-1995 信息处理系统开放系统互连基本参考模型第2部分：安全体系结构。
(5)GB/T 20269-2006信息安全技术信息系统安全管理要求。
(6)GB/T 20270-2006信息安全技术网络基础安全技术要求。
(7)GB/T 20271-2006信息安全技术信息系统通用安全技术要求。
(8)GB/T20272-2006信息安全技术操作系统安全技术要求。
(9)GB/T20273-2006信息安全技术数据库管理系统安全技术要求。
(10)GB/T 20274.1-2006 信息安全技术信息系统安全保障评估框。
(11)GB/T 18231-2000信息系统低层安全。
(12)GB/T 18237.1-2000信息技术开放系统互联通用高层第1部分：概述、模型和记法。
(13)GB/T 18237.2-2000信息技术开放系统互联通用高层第2部分：安全交换服务元素服务定义。
(14)GB/T18336-2015 信息系统信息技术安全评估准则。
(15)GB/T 20438.1~7-2017 电气/电子/可编程电子安全相关系统的功能安全，由中国国家标准化管理委员会发布。
3.3 相关标准化组织
- (1)国际标准化组织 (ISO)
- (2)国际电工委员会 (IEC)
- (3)中国国家标准化管理委员会 (SAC)
- (4)全国信息技术标准化技术委员
4 安全模型
4.1 信息系统的安全目标
信息系统的安全目标是控制和管理主体(含用户和进程)对客体(含数据和程序)的访问 。作为信息系统安全目标，就是要实现：
- 保护信息系统的可用性；
- 保护网络系统服务的连续性；
- 防范资源的非法访问及非授权访问；
- 防范入侵者的恶意攻击与破坏；
- 保护信息通过网上传输过程中的机密性、完整性；
- 防范病毒的侵害；
- 实现安全管理。
4.2 典型的安全模型
4.2.1 状态机模型
状态机模型， 一个安全状态模型系统，总是从一个安全状态启动，并且在所有迁移中保持安全状态，只允许主体以和安全策略相一致的安全访问资源。
4.2.2 BLP模型
BLP模型（Bell-LaPadula Model）。该模型为数据规划机密性，依据机密性划分安全级别，按安全级别强制访问控制。
4.2.2.1 基本原理
（1）安全级别是“机密”的主体访问安全级别为“绝密”的客体时，主体对客体可写不可读。
（2）安全级别是“机密”的主体访问安全级别为“机密”的客体时，主体对客体可写可读。
（3）安全级别是“机密”的主体访问安全级别为“秘密”的客体时，主体对客体可读不可写。
4.2.2.2 安全规则
（1）简单安全规则 (Simple Security Rule): 安全级别低的主体不能读安全级别高的客体(No Read Up);
（2）星属性安全规则 (Star Security Property): 安全级别高的主体不能往低级别的客体写(No Write Down);
（3）强星属性安全规则 (Strong Star Security Property): 不允许对另一级别进行读写；
（4）自主安全规则 (Discretionary Security Property): 使用访问控制矩阵来定义说明自由存取控制。其存取控制体现在内容相关和上下文相关。
4.2.3 Biba模型
Biba 模型不关心信息机密性的安全级别，因此它的访问控制不是建立在安全级别上，而是建立在完整性级别上。
完整性的三个目标：
（1）保护数据不被未授权用户更改 ；
（2）保护数据不被授权用户越权修改(未授权更改) ;
（3）维持数据内部和外部的一致性 。
4.2.3.1 基本原理
（1）当完整性级别为“中完整性”的主体访问完整性为“高完整性”的客体时，主体对客体可读不可写 (No Write Up), 也不能调用主体的任何程序和服务 ；
（2）当完整性级别为“中完整性”的主体访问完整性为“中完整性”的客体时，主体对客体可读读可写 ；
（3）当完整性级别为“中完整性”的主体访问完整性为“低完整性”的客体时，主体对客体可写不可读； (No Read Down) ;
4.2.3.2 安全规则
Biba模型能够防止数据从低完整性级别流向高完整性级别 ，其安全规则如下：
（1）星完整性规则(*-integrity Axiom): 表示完整性级别低的主体不能对完整性级别高的客体写数据；
（2）简单完整性规则 (Simple Integrity Axiom): 表示完整性级别高的主体不能从完整性级别低的客体读取数据；
（3）调用属性规则 (Invocation Property): 表示一个完整性级别低的主体不能从级别高的客体调用程序或服务。
4.2.4 CWM模型
CWM模型（Clark-Wilson Model）。将完整性目标、策略、机制融为一体，提出职责分离目标，应用完整性验证过程，实现了成型的事务处理机制，常用于银行系统。CWM模型具有以下特征：
（1）包含主体、程序、客体三元素，主体只能通过程序访问客体。
（2）权限分离原则，功能可分为多主体，防止授权用户进行未授权修改。
（3）具有审计能力。
4.2.5 Chinese Wall模型
Chinese Wall模型，是一个混合策略模型，应用于多边安全系统，防止多安全域存在潜在的冲突。该模型为投资银行设计，常见于金融领域。
4.2.5.1 工作原理
通过自主访问控制（DAC）选择安全域，通过强制访问控制（MAC）完成特定安全域内访问控制。
4.2.5.2 安全规则
（1）墙内客体可读取。
（2）不同利益冲突组客体可读取。
（3）访问其他公司客体和其他利益冲突组客体后，主体对客体写入受限。
5 信息安全整体架构设计（WPDRRC模型）
5.1 WPDRRC信息安全体系架构模型
WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack) 信息安全模型是我国“八六三”信息安全专家组提出的适合中国国情的信息系统安全保障体系建设模型。 WPDRRC是在PDRR(Protect/Detect/React/React/Restore) 信息安全体系模型的基础上前后增加了预警和反击功能。针对网络安全防护问题，美国曾提出了多个网络安全体系模型和架构，其中比较经典的包括PDRR模型、P2DR模型。
而 WPDRRC模型由中国提出。在PDRR模型中，安全的概念已经从信息安全扩展到了信息保障，信息保障内涵已超出传统的信息安全保密，它是保护 (Protect)、 检测 (Detect)、 反应 (React)、 恢复 (Restore) 的有机结合，称为 PDRR模型。PDRR模型把信息的安全保护作为基础，将保护视为活动过程，要用检测手段来发现安全漏洞，及时更正；同时采用应急响应措施对付各种入侵；在系统被入侵后，要采取相应的措施将系统恢复到正常状态，这样才能使信息的安全得到全方位的保障。该模型强调的是自动故障恢复能力。
WPDRRC模型有6个环节和3大要素 。
- 6个环节 包括：预警、保护、检测、响应、恢复和反击 ，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。
- 3大要素 包括：人员、策略和技术 。人员是核心，策略是桥梁，技术是保证，落实在WPDRRC 的6个环节的各个方面，将安全策 预警略变为安全现实。
这里，6个环节说明如下：
● W : 预警主要是指利用远程安全评估系统提供的模拟攻击技术来检查系统存在的、可能被利用的薄弱环节，收集和测试网络与信息的安全风险所在，并以直观的方式进行报告，提供解决方案的建议，在经过分析后，分解网络的风险变化趋势和严重风险点，从而有效降低网络的总体风险，保护关键业务和数据。
● P : 防护通常是通过采用成熟的信息安全技术及方法来实现网络与信息的安全。主要内容有加密机制，数字签名机制，访问控制机制，认证机制，信息隐藏和防火墙技术等。
● D : 检测通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。在这个过程中采用入侵检测、恶意代码过滤等技术，形成动态检测的制度，奖励报告协调机制，提高检测的实时性。主要内容有入侵检测，系统脆弱性检测，数据完整性检测和攻击性检测等。
● R : 响应是指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态。为此需要相应的报警、跟踪、处理系统，其中处理包括了封堵、隔离、报告等能力。主要内容有应急策略、应急机制、应急手段、入侵过程分析和安全状态评估等。
● R : 恢复灾难恢复系统是当前网络、数据、服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。主要内容有容错、冗余、备份、替换、修复和恢复等。
● C : 反击是指采用一切可能的高新技术手段，侦察、提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。
5.2 信息安全体系架构设计
通过对网络应用的全面了解，按照安全风险、需求分析结果、安全策略以及网络的安全目标等方面开展安全体系架构的设计工作。具体在安全控制系统，我们可以从 物理安全、系统安全、网络安全、应用安全和管理安全 等5个方面开展分析和设计工作。
物理安全（前提）：包括环境安全、设备安全、媒体安全。
系统安全（基础）：包括网络结构安全、操作系统安全、应用系统安全。
网络安全（关键）：包括访问控制、通信保密、入侵检测、网络安全扫描、防病毒。
应用安全：包括资源共享、信息存储。
安全管理：包括健全的体制、管理平台、人员安全防范意识。
6 网络安全架构设计
6.1 OSI安全架构
OSI 定义了7层协议，其中除第5层(会话层)外，每一层均能提供相应的安全服务。实际上，最适合配置安全服务的是在物理层、网络层、运输层及应用层上，其他层都不宜配置安全服务。
OSI开放系统互联安全体系的 5类安全服务 包括 鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。
如下，信息安全体系结构示意图：
如下，安全服务和安全机制的对应关系：
OSI 定义分层多点安全技术体系架构 ，也称为 深度防御安全技术体系架构 ，它通过以下 三种方式将防御能力分布至整个信息系统中 。
（1）多点技术防御
在对手可以从内部或外部多点攻击一个目标的前提下，多点技术防御通过对以下多个防御核心区域的防御达到抵御所有方式的攻击目的。
通过网络和基础设施，边界防御（流量过滤、控制、如前检测），计算环境等方式进行防御。
(1)网络和基础设施。为了确保可用性，局域网和广域网需要进行保护以抵抗各种攻击，如拒绝服务攻击等。为了确保机密性和完整性，需要保护在这些网络上传送的信息以及流量的特征以防止非故意的泄露。
(2)边界。为了抵御主动的网络攻击，边界需要提供更强的边界防御，例如流量过滤和控制以及入侵检测。
(3)计算环境。为了抵御内部、近距离的分布攻击，主机和工作站需要提供足够的访问控制。
（2）分层技术防御
即使最好的可得到的信息保障产品也有弱点，其最终结果将使对手能找到一个可探查的脆弱性，一个有效的措施是在对手和目标间使用多个防御机制。为了减少这些攻击成功的可能性和对成功攻击的可承担性，每种机制应代表一种唯一的障碍并同时包括保护和检测方法。例如，在外部和内部边界同时使用嵌套的防火墙并配合以入侵检测就是分层技术防御的一个实例。
外部和内部边界使用嵌套防火墙，配合入侵检测进行防御。
（3）支撑性基础设施
支撑性基础设施为网络、边界和计算环境中信息保障机制运行基础的支撑性基础设施，包括公钥基础设施以及检测和响应基础设施。
使用公钥基础设施以及检测和响应基础设施进行防御。
(1)公钥基础设施。提供一种通用的联合处理方式，以便安全地创建、分发和管理公钥证书和传统的对称密钥，使它们能够为网络、边界和计算环境提供安全服务。这些服务能够对发送者和接收者的完整性进行可靠验证，并可以避免在未获授权的情况下泄露和更改信息。公钥基础设施必须支持受控的互操作性，并与各用户团体所建立的安全策略保持一致。
(2)检测和响应基础设施。检测和响应基础设施能够迅速检测并响应入侵行为。它也提供便于结合其他相关事件观察某个事件的“汇总”性能。另外，它也允许分析员识别潜在的行为模式或新的发展趋势。
6.2 认证框架
鉴权(Authentication) 的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。鉴别提供了实体声称其身份的保证，只有在主体和验证者的关系背景下，鉴别才是有意义的。鉴别有两种重要的关系背景：一是实体由申请者来代表，申请者与验证者之间存在着特定的通信关系(如实体鉴别);二是实体为验证者提供数据项来源。
鉴别的方式主要基于以下5种：
（1）已知的，如一个秘密的口令。
（2）拥有的，如 I C卡、令牌等。
（3）不改变的特性，如生物特征。
（4）相信可靠的第三方建立的鉴别(递推)。
（5）环境(如主机地址等)。
鉴别服务分为以下阶段：安装阶段、修改鉴别信息阶段、分发阶段、获取阶段、传送阶段、验证阶段、停活阶段、重新激活阶段、取消安装阶段。
6.3 访问控制框架
当发起者请求对目标进行特殊访问时，访问控制管制设备（Access Control Enforcement Facilities，AEF）就通知访问控制决策设备（Access Control Decision Facilities，ADF），ADF可以根据上下文信息（包括发起者的位置、访问时间或使用中的特殊通信路径）以及可能还有以前判决中保留下来的访问控制决策信息（Access Control Descision Information，ADI）做出允许或禁止发起者试图对目标进行访问的判决
6.4 机密性框架
完整性服务目的是 确保信息仅仅是对被授权者可用。
机密性机制包括： 通过禁止访问提供机密性、通过加密提供机密性。
6.5 完整性框架
完整性服务目的是 组织威胁或探测威胁，保护数据及其相关属性的完整性。
完整性服务分类有： 未授权的数据创建、数据创建、数据删除、数据重放。
完整性机制类型分为 阻止媒体访问与探测非授权修改两种。
6.6 抗抵赖框架
抗抵赖服务的目的是 提供特定事件或行为的证据。
抗抵赖服务阶段分为： 证据生成、证据传输、存储及回复、证据验证、解决纠纷这5个阶段。
7 数据库系统安全设计
7.1 数据库完整性设计原则
（1） 根据数据库 完整性约束的类型确定其实现的系统层次和方式 ，并提前 考虑对系统性能 的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。
（2）实体完整性约束、引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。
（3） 要慎用 目前主流DBMS都支持的 触发器 功能，一方面由于触发器的性能开销较大；另一方面，触发器的多级触发难以控制，容易发生错误，非用不可时，最好使用 Before型语句级触发器。
（4） 在需求分析阶段就 必须制定完整性约束的命名规范 ，尽量使用有意义的英文单词、缩写词、表名、列名及下画线等组合，使其易于识别和记忆，如CKC_EMP_REAL_INCOME_EMPLOYEE、PK_EMPLOYEE、CKT_EMPLOYEE。 如果使用CASE工具，一般有默认的规则，可在此基础上修改使用。
（5） 要根据业务规则对数据库完整性进行细致的测试，以尽早 排除隐含的完整性约束间的冲突和对性能的影响 。
（6） 要有专职的数据库设计小组 ， 自始至终负责 数据库的 分析、设计、测试、实施及早期维护 。数据库设计人员不仅负责基于DBMS 的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。
（7） 应采用合适的 CASE工具来降低数据库设计各阶段的工作量 。好的CASE工具能够支持整个数据库的生命周期，这将使数据库设计人员的 工作效率得到很大提高，同时也容易与用户沟通 。
7.2 数据库完整性的作用
（1）数据库完整性约束能够 防止 合法用户使用数据库时向数据库中 添加不合语义的数据 。
（2）利用基于DBMS 的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以 降低应用程序的复杂性，提高应用程序的运行效率 。同时，基于DBMS 的完整性控制机制是集中管理的，因此比应用程序更容易实现数据库的完整性。
（3）合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。例如装载大量数据时，只要在装载之前临时使基于DBMS 的数据库完整性约束失效，此后再使其生效，就能保证既不影响数据装载的效率又能保证数据库的完整性。
（4）在应用软件的 功能测试 中，完善的数据库完整性有助于 尽早发现应用软件的错误。
（5）数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。动态约束通常由应用软件来实现。不同DBMS支持的数据库完整性基本相同。
8 系统架构脆弱性分析
8.1 系统架构的脆弱性组成
系统架构脆弱性 包括 物理装备脆弱性、软件脆弱性、人员管理脆弱性、规章制度脆弱性、安全策略脆弱性 等。
8.2 典型架构的脆弱性表现
软件架构脆弱性通常与软件架构的风格和模式有关，不同风格和模式的软件架构，其脆弱性体现和特点有很大不同，且解决脆弱性问题需要考虑的因素和采取的措施也有很大不同。
8.2.1 分层架构
分层架构被广泛应用于企业应用软件架构设计，大多数分层架构模式通常包括4个层次：即表示层、业务层、持久化层和数据库层。分层架构将应用系统正交地划分为若干层，每一层只解决问题的一部分，通过各层的协作提供整体解决方案。分层架构的脆
弱性主要表现在两个方面：
（1） 层间的脆弱性 。一旦某个底层发生错误，那么整个程序将会无法正常运行，如产生一些数据溢出，空指针、空对象的安全性问题，也有可能会得出错误的结果。
（2） 层间通信的脆弱性 。将系统隔离为多个相对独立的层，这就要求在层与层之间引入通信机制，在使用面向对象方法设计的系统中，通常会存在大量细粒度的对象，以及它们只见大量的消息交互——对象成员方法的调用。本来“直来直去”的操作现在要层层传递，势必造成性能下降。
8.2.2 C/S架构
C/S 架构是客户机和服务器结构。 C/S分为两部分：服务器部分和客户机部分。服务器部分是多个用户共享的信息与功能，执行后台服务，如控制共享数据库的操作等；客户机部分为用户所专有，负责执行前台功能，在出错提示、在线帮助等方面都有强大的功能，并且可以在子程序间自由切换。
C/S 架构的脆弱性主要表现在以下几个方面：
（1） 客户端软件的脆弱性 。只要安装了特定客户端软件的用户才可以使用 C/S 架构系统，正因为在用户计算机上安装了客户端软件，所以这个系统就面临着程序被分析、数据被截取的安全隐患。
（2） 网络开放性的脆弱性 。目前很多传统的C/S 系统还是采用二层结构，也就是说所有客户端直接读取服务器端中的数据，在客户端包括了数据的用户名，密码等致命的信息，这样会给系统带来安全隐患。如果这样的系统放在Internet上，那么这个服务器端对于 Internet上的任何用户都是开放的。
（3） 网络协议的脆弱性 。 C/S 可以使用多种网络协议，也可以自定义协议，从这个角度来看，C/S 架构的安全性是有保障的。但是， C/S架构不便于随时与用户交流(主要是不便于数据包共享),并且 C/S 架构软件在保护数据的安全性方面有着先天的弊端。由于 C/S 架构软件的数据分布特性，客户端所发生的火灾、盗抢、地震、病毒等都将成为可怕的数据杀手。
8.2.3 B/S架构
B/S 架构是浏览器/服务器结构模式，是一种以Web技术为基础的新型管理信息系统平台模式，它是利用通用浏览器实现了原来要用复杂专用软件才能实现的强大功能。 B/S架构的优点在于可以在任何地方进行操作而不用安装任何专门的软件，只要有一台能上网的计算机即刻，客户端零维护；系统的扩展非常容易，并且数据都集中存放在数据库服务器，所以不存在数据不一致现象。
B/S架构的脆弱性主要表现在：
系统如果使用 HTTP 协议， B/S架构相对C/S 架构而言更容易被病毒入侵 ，虽然最新的HTTP协议在安全性方面有所提升，但还是弱于 C/S
8.2.4 事件驱动架构
事件驱动架构是一种流行的分布式异步架构，是一种适合高扩展工程的、较流行的分布式异构架构模式，有较高柔性，它由高度解耦、单一目的异步接收的事件处理组件和处理事件组成。事件驱动架构通常有两种拓扑结构： Mediator结构和Broker结构， Mediator结构通常适用于事件的多个步骤需要通过中间角色来指挥和协调的情形，而 Broker结构适用于事件是链式关系而不需要中间角色的情形。
事件驱动架构的脆弱性主要表现在：
（1） 组件的脆弱性 。组件削弱了自身对系统的控制能力，一个组件触发事件，并不能确定响应该事件的其他组件及各组建的执行顺序。
（2） 组件间交换数据的脆弱性 。组件不能很好地解决数据交换问题，事件触发时，一个组件有可能需要将参数传递给另一个组件，而数据量很大的时候，如何有效传递是一个脆弱性问题。
（3） 组件间逻辑关系的脆弱性 。事件架构使系统中各组件的逻辑关系变得更加复杂。
（4） 事件驱动容易进入死循环 ，这是由编程逻辑决定的。
（5） 高并发的脆弱性 。虽然事件驱动可实现有效利用 CPU 资源，但是存在高并发事件处理造成的系统响应问题，而且，高并发容易导致系统数据不正确、丢失数据等现象。
（6） 固定流程的脆弱性 。因为事件驱动的可响应流程基本都是固定的，如果操作不当，容易引发安全问题。
8.2.5 MVC架构
MVC 架构是Model、View、Controller 的缩写，它是把一个应用的输入、处理、输出流程按照 Model、View、Controller的方式进行分离，即应用可被分成三层：模型层、视图层和控制层。
MVC架构的脆弱性主要表现在：
（1） MVC架构的复杂性带来脆弱性 。 MVC架构增加了系统结构和实现的复杂性。比如说一个简单的界面，如果严格遵循MVC方式，使得模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2） 视图与控制器间紧密连接的脆弱性 。视图与控制器是相互分离但确是联系紧密的部件，没有控制器的存在，视图应用是很有限的。反之亦然，这样就妨碍了它们的独立重用。
（3） 视图对模型数据的低效率访问的脆弱性 。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。可以说， MVC架构的脆弱性主要表现在缺少对调用者进行安全验证的方式和数据传输不够安全等两个方面，这些不足也是导致MVC存在比较大的脆弱性、容易招致攻击的主要原因。
8.2.6 微内核架构
微内核架构是指内核的一种精简形式，将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入选，达到系统的可扩展性、更好地适应环境要求。微内核架构也被称为插件架构模式 (Plug-in Architecture Pattern), 通常由内核系统和插件组成。
微内核架构的脆弱性主要表现在：
（1） 微内核架构难以进行良好的整体化优化 。由于微内核系统的核心态只实现了最基本的系统操作，这样内核以外的外部程序之间的独立运行使得系统难以进行良好的整体优化。
（2） 微内核系统的进程间通信开销也较单一内核系统要大得多 。从整体上看，在当前硬件条件下，微内核在效率上的损失小于其在结构上获得的收益。
（3） 通信损失率高。微内核把系统分为各个小的功能块 ，从而降低了设计难度，系统的维护与修改也容易，但通信带来的效率损失是一个问题。
8.2.7 微服务架构
微服务架构是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间相互协调、相互配合、为用户提供最终价值。微服务架构中的每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等中。
微服务架构的脆弱性主要表现在：
（1） 开发人员需要处理分布式系统的复杂结构。
（2） 开发人员要设计服务之间的通信机制，通过写代码来处理消息传递中速度过慢或者不可用等局部实效问题。
（3） 服务管理的复杂性，在生产环境中要管理多个不同的服务实例，这意味着开发团队需要全局统筹。
9 安全架构设计实践
9.1 电子商务系统的安全性设计
具体的电子商务系统——高性能的RADIUS, 来阐明电子商务系统的安全设计的基本原理和设计方法。
电子商务系统的安全性设计原理介绍：
认证、授权和审计 (Authentication Authorization and Accounting,AAA) 是运行于宽带网络接入服务器上的客户端程序。 AAA提供了一个用来对认证、授权和审计三种安全功能进行配置的一致的框架，实际上是对网络安全的一种管理。这里的网络安全主要指访问控制，包括哪些用户可以访问网络服务器?如何对正在使用网络资源的用户进行记账?下面简单介绍验证、授权和记账的作用。
（1）认证 (Authentication): 验证用户是否可以获得访问权，认证信息包括用户名、用户密码和认证结果等。
（2）授权 (Authorization): 授权用户可以使用哪些服务，授权包括服务类型及服务相关信息等。
（3）审计 (Accounting): 记录用户使用网络资源的情况，用户IP地址、 MAC 地址掩码等。
远程认证拨号用户服务（Remote Authentication Dial-In User Service，RADIUS）
RADIUS是应用最广泛的高安全级别的 认证、授权、审计协议（Authentication，Authorization，Accounting，AAA），具有高性能和高可扩展性 ，且可用多种协议实现 。
RADIUS通常由 协议逻辑层，业务逻辑层和数据逻辑层3 层组成层次式架构。
（1） 协议逻辑层 ：起到分发处理功能，相当于转发引擎。
（2） 业务逻辑层 ：实现认证、授权、审计三种类型业务及其服务进程间的通信。
（3） 数据逻辑层 ：实现统一的数据访问代理池，降低数据库依赖，减少数据库压力，增强系统的数据适应能力。
9.2 基于混合云的工业安全架构设计
混合云融合了公有云和私有云 。在基于混合云的工业安全生产管理系统中，工厂内部的产品设计、数据共享、生产集成使用私有云实现。公有云则用于公司总部与智能工厂间的业务管理、协调和统计分析等。 整个生产管理系统架构采用层次式架构，分为设备层、控制层、设计/管理层、应用层 。
（1） 设备层 ：包括智能工厂生产设备，包括智能传感器、智能仪器仪表、工业机器人、其他生产设备。
（2） 控制层 ：包括智能设备控制用自动控制系统，包括采集与监视控制系统（SCADA）、分布式控制系统（FCS）、可编程控制器（PLC）、人机接口（HMI），其他现场控制程序。
（3） 设计/管理层 ：包括智能工厂所有控制开发，业务控制和数据管理相关系统及其功能的集合，实现了数据集成和应用。
（4） 应用层 ：云平台上的信息处理，包括数据处理与管理、数据与行业应用相结合，如定制业务、协同业务、产品服务。