18.1安全架构概述
18.1.1信息安全面临的威胁
对于信息系统来说，威胁可以是针对物理环境、通信链路、网络系统、操作系统、应用系统以及管理系统等方面。
| 威胁类型 | 核心威胁内容 | 典型示例 |
|---|---|---|
| 物理安全威胁 | 针对硬件设备、环境与物理资产的破坏或异常 | 自然灾害、电源故障、设备被盗/损毁、系统引导失败、数据库数据丢失、物理泄密 |
| 通信链路安全威胁 | 针对传输线路的监听、干扰、劫持 | 线路窃听装置部署、通信信号干扰、链路劫持 |
| 网络安全威胁 | 依托互联网开放性，利用网络技术窃取、攻击 | 网络嗅探、数据窃取、外网渗透攻击等互联网层面恶意行为 |
| 操作系统安全威胁 | 底层系统、固件、硬件芯片植入恶意风险 | 木马、陷阱门、BIOS万能密码、系统底层后门 |
| 应用系统安全威胁 | 业务服务、应用程序层面的安全隐患 | 业务系统漏洞、Web服务攻击、应用层木马与后门 |
| 管理系统安全威胁 | 人员管理疏漏、人为违规操作造成泄密 | 私自拷贝、拍照、抄录涉密数据，内部人员违规泄密、管理制度缺失 |
- 物理：设备、环境、硬件损坏丢失
- 链路：线路窃听、干扰
- 网络：互联网开放带来的数据窃取、外网攻击
- 系统：OS、固件、底层后门/木马
- 应用：业务服务、应用程序漏洞威胁
- 管理：内部人员人为泄密、管理疏漏
| 序号 | 安全威胁 | 核心描述 |
|---|---|---|
| 1 | 信息泄露 | 信息泄露或透露给非授权实体 |
| 2 | 破坏完整性 | 非授权增删、修改、破坏数据 |
| 3 | 拒绝服务 | 阻止对资源的合法访问 |
| 4 | 非法使用 | 非授权人员/方式使用系统资源 |
| 5 | 窃听 | 搭线监听、电磁泄漏截取敏感信息 |
| 6 | 业务流分析 | 监听通信流量、频度、流向，统计分析获取情报 |
| 7 | 假冒 | 冒充合法用户/高权限用户实施非法访问 |
| 8 | 旁路控制 | 利用系统脆弱点、隐蔽特性绕过安全边界入侵 |
| 9 | 授权侵犯 | 合法授权用户滥用权限，用作非授权用途（内部攻击） |
| 10 | 特洛伊木马 | 隐藏恶意程序段，执行后破坏系统安全 |
| 11 | 陷阱门 | 预留特殊入口，特定输入即可绕过安全策略 |
| 12 | 抵赖 | 否认操作行为、伪造数据，拒绝承担责任 |
| 13 | 重放 | 截取合法通信数据，重复发送实施非法操作 |
| 14 | 计算机病毒 | 具备自我感染、破坏系统或植入攻击的恶意程序 |
| 15 | 人员渎职 | 授权人员因利益或疏忽，主动泄露信息 |
| 16 | 媒体废弃 | 从废弃存储介质、打印资料中恢复窃取数据 |
| 17 | 物理侵入 | 绕过物理防护，物理层面非法接入系统 |
| 18 | 窃取 | 盗取令牌、身份卡等安全物理凭证 |
| 19 | 业务欺骗 | 伪造系统/服务，诱导用户主动泄露敏感信息 |
18.1.2安全架构的定义和范围
安全性体现在产品上为：产品安全架构、安全技术体系架构和审计架构
| 分类 | 核心定义 | 建设目标/任务 |
|---|---|---|
| 产品安全架构 | 产品安全质量属性组成及相互关系 | 不依赖外部防御，从源头实现产品自身安全 |
| 安全技术体系架构 | 安全技术体系组成及相互关系 | 搭建通用安全技术基础设施，整体增强各类产品防御能力 |
| 审计架构 | 独立审计部门具备的风险发现能力 | 全覆盖审计各类风险，重点识别安全风险 |
安全架构应具备可用性、完整性和机密性等特性。
可用性 (Availability) ：是指要防止系统的数据和资源丢失；
完整性(Integrity) ：是指要防止系统的数据和资源在未经授权情况下被修改；
机密性 (Confidentiality) ：是指要防止系统的数据和资源在未授权的情况下被披露。
18.1.3与信息安全相关的国内外标准及组织
国外标准
| 序号 | 标准/框架全称 | 简称 | 发布方/背景 |
|---|---|---|---|
| 1 | 可信计算机系统评估准则 | TCSEC（橘皮书） | 美国国防部，1985年 |
| 2 | 信息技术安全评估准则 | ITSEC | 英、法、德、荷联合编制 |
| 3 | 加拿大可信计算机产品评估准则 | CTCPEC | 加拿大，1993年 |
| 4 | 美国联邦准则 | FC | 美国，1992年，TCSEC升级版 |
| 5 | 信息技术安全性评价通用准则 | CC | 美、加、英、法、德、荷等联合编制，1993年 |
| 6 | OSI安全结构标准 | ISO/IEC 7498-2 | ISO，1989年 |
| 7 | 信息保障技术框架 | IATF | 美国NSA，1999年 |
| 8 | 信息技术安全技术 信息技术安全性评估准则 | ISO/IEC 15408 | ISO，1999年，替代原CC |
| 9 | 电气/电子/可编程电子安全系统功能安全标准 | IEC 61508 | 国际电工委员会，2010年 |
国内标准
标准缩写含义
(1)GA: 国家安全行业标准规范。由中国安全技术防范认证中心组织发布。
(2)GB: 国家标准规范，由中国国家标准化管理委员会组织发布。
(3)GJB: 国家军用标准规范。
| 序号 | 标准编号 | 标准名称 |
|---|---|---|
| 1 | GB 15834-1995 | 信息处理数据加密实体鉴别机制 |
| 2 | GA 163-1997 | 计算机信息系统安全专用产品分类原则 |
| 3 | GB 17859-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/T 20272-2006 | 信息安全技术 操作系统安全技术要求 |
| 9 | GB/T 20273-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/T 18336-2015 | 信息技术 安全评估准则 |
| 15 | GB/T 20438.1~7-2017 | 电气/电子/可编程电子安全相关系统的功能安全 |
相关标准化组织
| 机构 | 核心信息&职责 |
|---|---|
| ISO（国际标准化组织） | TC97下设SC20负责数据加密标准；后合并为ISO/IEC JTC1；SC27主管信息技术通用安全标准化；TC68负责银行业信息安全行业标准 |
| IEC（国际电工委员会） | 1906年成立，最早国际电工标准化机构；负责电气、电子工程领域国际标准；曾并入ISO，后独立，聚焦电工电子标准化与安全、环保 |
| SAC（中国国家标准化管理委员会） | 2001年成立，归口全国标准化管理；审批发布国标、对接ISO/IEC、统筹各级标准，现归口市监总局 |
| 全国信息技术标准化技术委员会（信标委） | 1983年设立，工信部与SAC共管；负责全国信息技术全领域标准化制定与落地 |
18.2安全模型
信息系统的安全目标是控制和管理主体(含用户和进程)对客体(含数据和程序)的访问。
安全目标要实现：
● 保护信息系统的可用性；
● 保护网络系统服务的连续性；
● 防范资源的非法访问及非授权访问；
● 防范入侵者的恶意攻击与破坏；
● 保护信息通过网上传输过程中的机密性、完整性；
● 防范病毒的侵害；
● 实现安全管理。
安全模型是准确地描述安全的重要方面及其与系统行为的关系，安全策略是从安全角度为系统整体和构成它的组件提出基本的目标，它是一个系统的基础规范，使系统集成后评估它的基准。
当前比较被公认的模型有：状态机模型 (State Machine Model)、Bell-LaPadula(BLP) 模型、Biba模型、 Clark-Wilson(CWM) 模型、 ChineseWall 模型，以及信息流模型 (Information FlowModel)、 非干涉模型 (Noninterference Model)、 格子模型 (Lattice Model)、Brewer and Nash模型和 Graham-Denning模型等。
18.2.1状态机模型
状态机模型描述了一种无论处于何种状态都是安全的系统。它是用状态语言将安全系统描述成抽象的状态机，用状态变量表述系统的状态，用转换规则描述变量变化的过程。
状态机模型中一个状态 (state) 是处于系统在特定时刻的一个快照。如果该状态所有方面满足安全策略的要求，则称此状态是安全的；如果所有行为都在系统中允许并且不危及系统使之处于不安全状态，则断言系统执行了一个安全状态模型 (Secure State Model)。 一个安全状态模型系统，总是从一个安全状态启动，并且在所有迁移中保持安全状态，只允许主体以和安全策略相一致的安全方式访问资源。
状态机模型工作原理如图18-4所示，具体步骤描述如下：
(1)状态变量的默认值必须安全；
(2)用户试图使用变量的默认值；
(3)系统检查主体的身份验证；
(4)系统确保变更不会使系统置于不安全状态；
(5)系统允许变量值变更，发生状态改变(STATE CHANGE);
(6)再重复执行(1)~(5)步，会导致另一次状态变化。
18.2.2Bell-LaPadula模型
Bell-LaPadula模型属于强制访问控制模型，以敏感度来划分安全级别。将数据划分为多安全级别与敏感度的系统，即多级安全系统。
本模型是为美国国防部多级安全策略形式化而开发，其机密性模型是第一个能够提供分级别数据机密性保障的安全策略模型(即多级安全)。
模型基本原理
Bell-LaPadula模型使用主体、客体、访问操作(读、写、读/写)以及安全级别这些概念，当主体和客体位于不同的安全级别时，主体对客体就存在一定的访问限制。通过该模型可保证信息不被不安全主体访问。
(1)安全级别为"机密"的主体访问安全级别为"绝密"的客体时，主体对客体可写不可读 (No Read Up);
(2)当安全级别为"机密"的主体访问安全级别为"机密"的客体时，主体对客体可写可读；
(3)当安全级别为"机密"的主体访问安全级别为"秘密"的客体时，主体对客体可读不可写 (No Write Down)。
模型安全规则
1)简单安全规则 (Simple Security Rule): 安全级别低的主体不能读安全级别高的客体(No Read Up);
(2)星属性安全规则 (Star Security Property): 安全级别高的主体不能往低级别的客体写(No Write Down);
(3)强星属性安全规则 (Strong Star Security Property): 不允许对另一级别进行读写；
(4)自主安全规则 (Discretionary Security Property): 使用访问控制矩阵来定义说明自由存取控制。其存取控制体现在内容相关和上下文相关。
18.2.3Biba模型
Biba 模型是在 Bell-LaPadula模型之后开发的，它跟Bell-LaPadula模型很相似，被用于解决应用程序数据的完整性问题。
模型基本原理
Biba 模型不关心信息机密性的安全级别，因此它的访问控制不是建立在安全级别上，而是建立在完整性级别上。
完整性的三个目标：保护数据不被未授权用户更改；保护数据不被授权用户越权修改(未授权更改);维持数据内部和外部的一致性。
Biba模型的安全策略是基于层次化的完整性级别。它将完整性威胁分为来源于子系统内部和外部的威胁。如果子系统的一个组件是恶意或不正确，则产生内部威胁；如果一个子系统企图通过错误数据或不正确调用函数来修改另一个子系统，则产生外部威胁。内部威胁可以通过程序测试或检验来解决。所以本模型主要针对外部威胁，解决了完整性的第一目标：即防止非授权用户的篡改。
(1)当完整性级别为"中完整性"的主体访问完整性为"高完整性"的客体时，主体对客体可读不可写 (No Write Up), 也不能调用主体的任何程序和服务；
(2)当完整性级别为"中完整性"的主体访问完整性为"中完整性"的客体时，主体对客体可读读可写；
(3)当完整性级别为"中完整性"的主体访问完整性为"低完整性"的客体时，主体对客体可写不可读； (No Read Down);
模型安全规则
Biba模型能够防止数据从低完整性级别流向高完整性级别，其安全规则如下：
(1)星完整性规则(*-integrity Axiom): 表示完整性级别低的主体不能对完整性级别高的客体写数据；
(2)简单完整性规则 (Simple Integrity Axiom): 表示完整性级别高的主体不能从完整性级别低的客体读取数据；
(3)调用属性规则 (Invocation Property): 表示一个完整性级别低的主体不能从级别高的客体调用程序或服务。
18.2.4Clark-Wilson模型
Clark-Wilson模型是由 David Clark 和 David Wilson 于1987年提出的完整性模型，简称为CWM , 这个模型实现了成型的事务处理机制，常用于银行系统中以保证数据完整性。
模型基本原理
CWM是一种将完整性目标、策略和机制融为一体的模型。为了体现用户完整性， CWM提出了职责隔离 (Separation of Duty) 目标；为了保证数据完整性， CWM提出了应用相关的完整性验证进程；为了建立过程完整性， CWM定义了对于变换过程的应用相关验证。
(1)需要进行完整性保护的客体称之为 CDI, 不需要进行完整性保护的客体称之为 UDI;
(2)完整性验证过程 (Integrity Verification Procedure,IVP): 确认限制数据项处于一种有效状态，如果IVP检 验C D I符合完整性约束，则系统处于一个有效状态；
(3)转换过程 (Transformation Procedures,TP): 将数据项从一种有效状态改变至另一种有效状态；
(4)为了确保对 C D I 的 T P是有效的，则需要授权 User做 T P 的认证；
(5)为了防止合法用户对 C D I做非法或错误操作，将 T P过程分为多个子过程，将每个子过程授权给不同的 User;
(6)但是如果 TP 的每个子过程被授权的 User之间存在某种利益同盟，则可能存在欺骗。从而使得 CDI 的完整性得不到保护。
模型特征
CWM的主要特征是：
(1)采用 Subject/Program /Object 三元素的组成方式。 Subject要 访 问Object只能通过Program进行；
(2)权限分离原则：将要害功能分为有2个或多个Subject完成，防止已授权用户进行未授权的修改；
(3)要求具有审计能力 (Auditing)。
18.2.5Chinese Wall模型
Chinese Wall模型(又名 Brew and Nash模型，最初是由 Brewer和Nash 提出)是应用在多边安全系统中的安全模型。也就是说，是指通过行政规定和划分、内部监控、 IT系统等手段防止各部门之间出现有损客户利益的利益冲突事件。
模型基本原理
Chinese Wall模型的安全策略的基础是客户访问的信息不会与当前他们可支配的信息产生冲突。
Chinese Wall 模型同时包括D A C和M A C 的属性，是强制访问控制模型 ( M A C ) 的一种混合策略模型，比如银行家可以选择为谁工作 (DAC), 一旦选定，他就只能为该客户工作 (MAC)。
模型的安全规则
Chinese Wall 模型的访问客体控制的安全规则如下：
(1)与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问；
(2)属于一个完全不同的利益冲突组的可以访问；
(3)主体能够对一个客体进行写的前提是主体未对任何属于其他公司数据集进行过访问。
定理1: 一个主体一旦访问过一个客体，则该主体只能访问位于同一公司数据集的客体或在不同利益组的客体。
定理2: 在一个利益冲突组中，一个主体最多只能访问一个公司数据集。
比如，假设Chinese Wall 安全策略包括三个信息存储模块：某家企业的单位信息 ©、 该家企业的所有信息集合 (Company Data,CD) 和该家企业与互为竞争关系企业的全部信息集合(Conflict of Interest,COI)。 那么， Chinese Wall 模型规定：
(1)每个 C 只能唯一对应一个CD;
(2)每个 C D 只能唯一对应一个利益冲突类COI;
(3)一个C O I类却可以同时包含多个CD。
模型举例
在一个企业投资顾问公司里，一个咨询师大部分是同时为若干个企业提供投资咨询服务的，该咨询师就掌握了他所服务的所有企业的全部信息，包括企业的内部机密信息。如果该咨询师所服务的若干企业中有两家企业是在同一行业内的竞争对手，那么我们可以联想到，该咨询师可能会在给一家企业提供咨询过程中，有意或者无意地透露一些自己知道的有关另一家竞争企业的内部信息，使得一方得到利益，另一方遭受损失，这就导致了利益冲突，这是Chinese Wall安全模型策略需要解决的首要问题。
18.3系统安全体系架构规划框架
安全技术体系架构是对组织机构信息技术系统的安全体系结构的整体描述。
安全技术体系架构框架是拥有信息技术系统的组织机构根据其策略的要求和风险评估的结果，参考相关技术体系构架的标准和最佳实践，结合组织机构信息技术系统的具体现状和需求，建立的符合组织
机构信息技术系统战略发展规划的信息技术系统整体体系框架。
这个框架是组织机构信息技术系统战略管理的具体体现。技术体系架构能力是组织机构执行安全技术整体能力的体现，它反映了组织机构在执行信息安全技术体系框架管理，达到预定的成本、功能和质量目标上的度量。
18.3.1安全技术体系架构
安全技术体系架构的目标是建立可持续改进的安全技术体系架构的能力，信息技术系统千变万化，有各种各样的分类方式，为从技术角度建立一个通用的对象分析模型，这里，我们将信息系统抽象成一个基本完备的信息系统分析模型，如图18-9所示。从信息技术系统分析模型出发，建立整个信息技术系统的安全架构。
一般来说，国际标准化组织 (ISO) 提出一种网络标准架构 (OSI) 参考模型将网络划分为物理、数据链路、网络、传输、会话、表示和应用等7层，
Andrew S.Tanenbau综 合OSI 参考模型和 TCP/IP 参考模型将网络划分为物理、数据链路、网络、传输和应用等5层。
18.3.2信息系统安全体系规划
信息系统安全体系主要是由技术体系、组织机构体系和管理体系三部分共同构成的。
技术体系是全面提供信息系统安全保护的技术保障系统，该体系由物理安全技术和系统安全技术两大类构成。
组织体系是信息系统的组织保障系统，由机构、岗位和人事三个模块构成。机构分为领导决策层、日常管理层和具体执行层；岗位是信息系统安全管理部门根据系统安全需要设定的负责某一个或某几个安全事务的职位；人事是根据管理机构设定的岗位，对岗位上在职、待职和离职的员工进行素质教育、业绩考核和安全监管的机构。
管理体系由法律管理、制度管理和培训管理三部分组成
18.3.3信息系统安全规划框架
建立了信息系统安全体系之后，就可以针对以上描述的内容进行全面的规划。信息系统安全规划的层次方法与步骤可以有不同，但是规划内容与层次应该是相同。规划的具体环节、相互之间的关系和具体方法如图18-11所示。
| 要点 | 核心内容 |
|---|---|
| 依托信息化战略规划 | 安全规划对齐企业信息化战略目标，为信息化建设提供安全保障；安全目标更具体、贴合安全业务诉求，整体保持同向统一。 |
| 三大规划维度 | 围绕技术安全、管理安全、组织安全统筹设计；覆盖物理、网络、系统、运营、人员五大安全领域。 |
| 分层安全覆盖 | 物理安全：环境、设备、资产物理防护 网络安全：拓扑、线路、边界访问控制（防火墙、IDS、VPN） 系统安全：操作系统、应用软件、应用策略安全 运营安全：备份恢复、加密认证、漏洞补丁、口令管理 人员安全：组织架构、安全培训、人员全周期、第三方管控 |
| 核心保护目标 | 以信息系统与信息资源安全保护为核心，从蓝图、现状、需求、措施四方面开展规划落地。 |
| 规划四项内容 | 1.结合信息化蓝图，制定安全发展目标 2.全面复盘信息化现状，梳理优劣短板 3.拆解中长期安全需求，便于落地实施 4.明确落地措施与方法，强化规划执行力 |
18.4信息安全整体架构设计 ( WPDRRC模型)
人、管理和技术手段是信息安全架构设计的三大要素。
而构成动态的信息与网络安全保障体系框架是实现系统的安全保障。
18.4.1WPDRRC信息安全体系架构模型
WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack) 信息安全模型是我国"八六三"
信息安全专家组提出的适合中国国情的信息系统安全保障体系建设模型。
W P D R R C是在P D R R(Protect/Detect/React/React/Restore) 信息安全体系模型的基础上前后增加了预警和反击功能。针对网络安全防护问题，美国曾提出了多个网络安全体系模型和架构，其中比较经典的包括PDRR模型、P2DR模型。而 W P D R R C模型由中国提出。
W P D R R C 模型有6个环节和3大要素。
6个环节包括：预警、保护、检测、响应、恢复和反击，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。
3大要素包括：人员、策略和技术。
人员是核心，策略是桥梁，技术是保证，落实在W P D R R C 的6个环节的各个方面，将安全策略变为安全现实。
| 六大环节 | 内容 |
|---|---|
| W 预警 | 风险评估、漏洞排查、模拟攻击、风险分析与趋势预判，提前规避安全隐患 |
| P 保护 | 加密、签名、访问控制、身份认证、信息隐藏、防火墙等静态防御技术 |
| D 检测 | 入侵检测、脆弱性扫描、完整性校验、攻击行为监控，动态发现威胁 |
| R 响应 | 安全事件告警、跟踪、隔离封堵、应急处置、事件分析与安全评估 |
| R 恢复 | 冗余容错、数据备份、系统修复、业务回迁，缩短故障中断时长 |
| C 反击 | 溯源取证、线索采集、留存证据，实现溯源追责与打击网络违法 |
18.4.2信息安全体系架构设计
| 项目 | 说明 |
|---|---|
| 安全保障体系三层组成 | 安全服务、协议层次、系统单元，各层级均包含安全管理 |
| 安全区域策略 | 按区域划分制定差异化安全策略，包含定时审计、入侵检测、统一授权与认证 |
| 防病毒系统管理 | 全局统一配置、集中管理，防御策略满足全面性、易用性、实时性、可扩展性 |
| 网络安全管理要求 | 配套制度与人员职责落地，遵循ISO 17799标准，兼顾有效性、经济性、全面性、普遍性、开放性 |
信息安全体系架构
| 安全维度 | 核心内容说明 |
|---|---|
| 物理安全 | 安全基础前提；包含环境安全、设备安全、媒体安全，防范自然灾害、人为破坏、操作失误与物理损毁 |
| 系统安全 | 整体安全底座；涵盖网络结构安全（拓扑、链路/路由冗余、防单点故障）、操作系统安全（安全配置、权限管控、漏洞扫描升级）、应用系统安全（关闭冗余端口服务、强化身份认证） |
| 网络安全 | 安全方案关键；包含访问控制、通信保密、入侵检测、安全扫描、全网防病毒；依托防火墙隔离域边界、IDS实时监控告警、防毒三步（预防/检测/查杀） |
| 应用安全 | 面向业务与数据；严控共享资源权限、共享目录加密口令认证；收紧主机无用服务、数据库定期备份与远程容灾，保障存储与业务数据安全 |
| 管理安全 | 制度+平台+人员；完善安全管理制度与岗位职责；搭建集中安全管理平台、统一管控设备；常态化安全培训，提升全员安全意识 |
18.5网络安全体系架构设计
18.5.1OSI的安全体系架构概述
1.OSI概述
OSI(Open System Interconnection/Reference Mode,OSI/RM) ：OSI 目的在于保证开放系统进程与进程之间远距离安全交换信息。这些标准在参考模型的框架内，建立起一些指导原则与约束条件，从而提供了解决开放互联系统中安全问题的一致性方法。
OSI 安全体系结构提供以下内容。
(1)提供安全服务与有关安全机制在体系结构下的一般描述，这些服务和机制必须是为体系结构所配备的。
(2)确定体系结构内部可以提供这些服务的位置。
(3)保证安全服务完全准确地得以配置，并且在信息系统的安全周期中一直维持，安全功能务必达到一定强度的要求。
2.OSI安全架构
OSI 定义了7层协议，其中除第5层(会话层)外，每一层均能提供相应的安全服务。实际上，最适合配置安全服务的是在物理层、网络层、运输层及应用层上，其他层都不宜配置安全服务。
OSI 开放系统互联安全体系的5类安全服务包括鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。
OSI 定义分层多点安全技术体系架构，也称为深度防御安全技术体系架构，它通过以下三种方式将防御能力分布至整个信息系统中。
| 分类 | 核心说明 |
|---|---|
| 多点技术防御 | 从多区域协同防御： 1.网络和基础设施：防护DoS，保障传输机密性、完整性与可用性 2.边界：流量过滤、访问控制、入侵检测，抵御外部主动攻击 3.计算环境：主机与终端访问控制，防范内部及近距离攻击 |
| 分层技术防御 | 部署多重、差异化防御屏障，每层独立形成防护+检测能力；嵌套防火墙、联动入侵检测为典型实现，降低攻击成功率 |
| 支撑性基础设施 | 为全网安全机制提供底层支撑： 1.公钥基础设施：统一密钥与证书管理，实现身份认证、完整性校验、防泄露篡改 2.检测和响应基础设施：实时入侵发现、事件汇总关联、行为分析、趋势研判与快速处置 |
18.5.2认证框架
鉴别 (Authentication) 的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。
鉴别提供了实体声称其身份的保证，只有在主体和验证者的关系背景下，鉴别才是有意义的。
鉴别有两种重要的关系背景：一是实体由申请者来代表，申请者与验证者之间存在着特定的通信关系(如实体鉴别);二是实体为验证者提供数据项来源。图18-18给出了申请者、验证者、可信第三方之间的关系及三种鉴别信息类型
鉴别的方式主要基于以下5种。
(1)已知的，如一个秘密的口令。
(2)拥有的，如 IC 卡、令牌等。
(3)不改变的特性，如生物特征。
(4)相信可靠的第三方建立的鉴别(递推)。
(5)环境(如主机地址等)。
鉴别服务分为以下阶段：安装阶段、修改鉴别信息阶段、分发阶段、获取阶段、传送阶段、验证阶段、停活阶段、重新激活阶段、取消安装阶段。
| 阶段 | 核心内容 |
|---|---|
| 安装阶段 | 定义申请鉴别信息、验证鉴别信息 |
| 修改鉴别信息阶段 | 申请并变更鉴别信息，例如修改口令 |
| 分发阶段 | 向各实体分发验证鉴别信息，用于鉴别交互 |
| 获取阶段 | 申请者/验证者获取交换鉴别信息所需数据，可通过可信第三方交互获取证书、密钥等 |
| 传送阶段 | 在申请者与验证者之间传输交换鉴别信息 |
| 验证阶段 | 使用验证鉴别信息，核验交换鉴别信息合法性 |
| 停活阶段 | 临时冻结实体鉴别能力，暂停鉴别服务 |
| 重新激活阶段 | 解除停活状态，恢复实体正常鉴别权限 |
| 取消安装阶段 | 彻底移除实体，从鉴别体系中注销 |
18.5.3访问控制框架
访问控制 (Access Control) 决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。在访问控制实例中，访问可以是对一个系统(即对一个系统通信部分的一个实体)或对一个系统内部进行的。
ACI (访问控制信息)是用于访问控制目的的任何信息，其中包括上下文信息。
A D I (访问控制判决信息)是在做出一个特定的访问控制判决时可供A D F 使用的部分(或全部) ACI。
A D F (访问控制判决功能)是一种特定功能，它通过对访问请求、 A D I 以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。
A E F (访问控制实施功能)确保只有对目标允许的访问才由发起者执行。
18.5.4机密性框架
机密性概述
机密性 (Confidentiality) 服务的目的是确保信息仅仅是对被授权者可用。由于信息是通过数据表示的，而数据可能导致关系的变化(如文件操作可能导致目录改变或可用存储区域的改变),因此信息能通过许多不同的方式从数据中导出。
机密性机制
数据的机密性可以依赖于所驻留和传输的媒体。因此，存储数据的机密性能通过使用隐藏数据语义(如加密)或将数据分片的机制来保证。数据在传输中的机密性能通过禁止访问的机制、通过隐藏数据语义的机制或通过分散数据的机制得以保证(如跳频等)。这些机制类型能被单独使用或者组合使用。
| 类型 | 核心机制与说明 |
|---|---|
| 通过禁止访问提供机密性 | 依托访问控制、物理媒体防护、路由选择控制实现；限制非授权访问，仅可信设备、安全链路处理数据，防止信息外泄 |
| 通过加密提供机密性 | 分为对称加密、非对称加密；防护传输与存储过程数据泄露；补充手段包含数据填充、虚假流量、PDU头保护、时间可变域伪装 |
18.5.5完整性框架
完整性概述
完整性(Integrity) 框架的目的是通过阻止威胁或探测威胁，保护可能遭到不同方式危害的数据完整性和数据相关属性完整性。所谓完整性，就是数据不以未经授权方式进行改变或损毁的特征。
完整性服务有几种分类方式：根据防范的违规分类，违规操作分为未授权的数据修改、未授权的数据创建、未授权的数据删除、未授权的数据插入和未授权的数据重放。依据提供的保护方法分为阻止完整性损坏和检测完整性损坏。依据是否支持恢复机制，分为具有恢复机制的和不具有恢复机制的。
完整性机制的类型
由于保护数据的能力与正在使用的媒体有关，对于不同的媒体，数据完整性保护机制是有区别的，可概括为以下两种情况。
(1)阻止对媒体访问的机制。包括物理隔离的不受干扰的信道、路由控制、访问控制。
(2)用以探测对数据或数据项序列的非授权修改的机制。未授权修改包括未授权数据创建、
数据删除以及数据重复。而相应的完整性机制包括密封、数字签名、数据重复(作为对抗其他类型违规的手段)、与密码变换相结合的数字指纹和消息序列号。按照保护强度，完整性机制可分为不作保护；对修改和创建的探测；对修改、创建、删除和重复的探测；对修改和创建的探测并带恢复功能；对修改、创建、删除和重复的探测并带恢复功能。
18.5.6抗抵赖框架
抗抵赖 (Non-repudiation) 服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。
| 阶段 | 核心描述 |
|---|---|
| 证据生成 | 由证据生成器为行为/事件生成举证资料，可由实体自身或可信第三方联合、独立完成 |
| 证据传输、存储及恢复 | 完成证据跨实体传输、持久化存储与后续调取恢复 |
| 证据验证 | 由验证者依据使用者请求校验证据有效性、完整性，可信第三方可辅助核验 |
| 解决纠纷 | 由仲裁机构依据有效证据判定权责，处理争议与抵赖行为 |
18.6数据库系统的安全设计
18.6.1数据库安全设计的评估标准
TDI是 T C S E C在数据库管理系统方面的扩充和解释，并从安全策略、责任、保护和文档4个方面进一步描述了每级的安全标准。按照T C S E C标准， D 类产品是基本没有安全保护措施的产品， C 类产品只提供了安全保护措施，一般不称为安全产品。 B 类以上产品是实行强制存取控制的产品，也是真正意义上的安全产品。所谓安全产品均是指安全级别在 B 1 以上的产品，而安全数据库研究原型一般是指安全级别在B 1 级以上的以科研为目的，尚未产品化的数据库管理系统原型。
18.6.2数据库的完整性设计
数据库完整性是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过D B M S或应用程序来实现，基于D B M S 的完整性约束作为模式的一部分存入数据库中。通过D B M S 实现的数据库完整性按照数据库设计步骤进行设计，而由应用软件实现的数据库完整性则纳入应用软件设计范畴。
数据库完整性设计原则
| 序号 | 核心原则 | 总结 |
|---|---|---|
| 1 | 按约束类型选择实现层级，静态约束纳入数据库模式，动态约束由应用实现，提前评估性能影响 | 分类型、分层级实现约束，兼顾性能 |
| 2 | 优先启用实体完整性、引用完整性，适度牺牲时空开销，提升系统易用性 | 优先保障核心约束，权衡时空与易用性 |
| 3 | 谨慎使用触发器，控制开销与管控难度，优先选用Before型语句级触发器 | 慎用触发器，优先选择指定类型 |
| 4 | 统一约束命名规范，语义清晰，结合CASE工具优化，便于维护 | 统一命名，适配工具，提升维护效率 |
| 5 | 结合业务开展完整性测试，排查约束冲突与性能隐患 | 业务导向测试，提前规避隐患 |
| 6 | 设立专职小组，全流程负责设计落地与应用层逻辑审核 | 专职负责，全流程管控，兼顾审核 |
| 7 | 选用适配CASE工具，覆盖全生命周期，提升设计与协作效率 | 借助工具，降低工作量，提升效率 |
数据库完整性的作用
| 序号 | 核心作用 | 总结 |
|---|---|---|
| 1 | 约束合法用户操作，阻止不符合业务语义的数据入库 | 防范语义错误数据写入 |
| 2 | DBMS集中实现业务规则，简化应用、易于维护、提升运行效率 | 集中管控，降低应用复杂度 |
| 3 | 可灵活启停约束，平衡数据批量操作效率与数据完整性 | 兼顾完整性与系统性能 |
| 4 | 辅助软件测试，提前暴露应用程序逻辑缺陷 | 助力测试，提前发现Bug |
| 5 | 完整性约束分为静态/动态、列/元组/关系六类，动态多由应用实现 | 约束分类清晰，分层落地 |
数据库完整性设计示例
| 阶段 | 核心内容 | 总结 |
|---|---|---|
| 需求分析阶段 | 联合多方梳理业务对象与业务规则，筛选需由数据库完整性承载的规则并分类，区分库层与应用层实现范围 | 梳理规则，划分实现边界 |
| 概念结构设计阶段 | 构建独立于DBMS的ER概念模型，提前规划实体、关联关系，为后续实体完整性、引用完整性打下基础 | 搭建概念模型，预埋基础约束 |
| 逻辑结构设计阶段 | 转换为目标DBMS数据模型并优化，结合数据库机制选型落地各类完整性约束，优先选择性能最优方案 | 落地约束设计，兼顾性能优化 |
18.7系统架构的脆弱性分析
安全架构的设计核心是采用各种防御手段确保系统不被破坏，而系统的脆弱性分析是系统安全性的另一方面技术，即系统漏洞分析。
对一个信息系统来说，信息系统的安全"木桶理论"是指安全性不在于它是否采用了最新的加密算法或最先进的设备，而是由系统自身最薄弱之处，即漏洞所决定。只要这个漏洞被发现，系统就有可能成为网络攻击的牺牲品。
18.7.1概述
漏洞的来源
| 序号 | 核心内容 | 总结 |
|---|---|---|
| 1 | 软件设计瑕疵，协议设计缺陷、后期组件叠加，引入未知安全漏洞 | 设计层面先天缺陷 |
| 2 | 软件代码实现环节存在弱点，编码方式不当引发安全隐患 | 编码实现引入漏洞 |
| 3 | 程序自身缺陷，包含数据校验缺失、异常处理不足、系统调用误用等问题 | 程序自身代码瑕疵 |
| 4 | 系统、网络部署配置错误，默认配置、不合理策略带来安全风险 | 配置不当造成漏洞 |
18.7.2软件脆弱性
软件脆弱性定义
软件脆弱性是指由软件缺陷的客观存在所形成的一个可以被攻击者利用的实例，每个脆弱性都由至少一个软件缺陷引起，但是一个软件缺陷也可能不产生任何脆弱性，而且不同的软件缺陷可能导致相同的脆弱性。
在软件开发过程中，软件脆弱性包含了软件基础模型的脆弱性、软件架构设计的脆弱性、软件模块设计的脆弱性、软件接口设计的脆弱性、软件界面设计的脆弱性、数据库设计的脆弱性、架构模式和设计模式的脆弱性以及实现的脆弱性等。
软件脆弱性的特点和分类
| 序号 | 核心内容 | 总结 |
|---|---|---|
| 1 | 脆弱性属于系统隐藏弱点，本身无害，被利用后才会造成安全危害 | 静态无害，利用即风险 |
| 2 | 开发过程中各类逻辑错误，是脆弱性产生的主要根源 | 逻辑错误为主要成因 |
| 3 | 依赖系统运行环境，环境差异会引发不同脆弱性问题 | 与运行环境高度相关 |
| 4 | 修复旧漏洞易引入新漏洞，脆弱性将长期持续存在 | 漏洞迭代，长期存在 |
| 序号 | 核心内容 | 总结 |
|---|---|---|
| ISOS分类法 | 面向信息系统安全与隐私，辅助管理人员理解安全问题、提升防护能力 | 聚焦安全与隐私管理 |
| PA分类法 | 针对操作系统安全缺陷，面向普通人员，提供模式化问题发现思路 | 面向系统安全缺陷排查 |
| Landwehr分类法 | 从起因、引入阶段、分布位置三维度划分软件安全缺陷 | 三维度多层次分类 |
| Aslam分类法 | 针对Unix系统，按生命周期分为编码故障、突发故障，配套决策树实现自动分类 | 基于生命周期，适配Unix |
| Bishop分类法 | 围绕6项轴线，对Unix及网络类脆弱性进行多维度划分 | 六轴线多维分类 |
| IBM分类法 | 基于Landwehr框架扩展升级，多层级划分，适配新型漏洞，服务检测工具研发 | 扩展升级，面向工具开发 |
18.7.3典型软件架构的脆弱性分析
1.分层架构
分层架构的脆弱性主要表现在两个方面：
(1)层间的脆弱性。一旦某个底层发生错误，那么整个程序将会无法正常运行，如产生一些数据溢出，空指针、空对象的安全性问题，也有可能会得出错误的结果。
(2)层间通信的脆弱性。将系统隔离为多个相对独立的层，这就要求在层与层之间引入通信机制，在使用面向对象方法设计的系统中，通常会存在大量细粒度的对象，以及它们只见大量的消息交互------对象成员方法的调用。本来"直来直去"的操作现在要层层传递，势必造成性能下降。
2.C/S 架构
C/S 架构的脆弱性主要表现在以下几个方面
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 客户端本地存在被破解风险 | 客户端需安装专用程序，易被逆向分析、本地数据截取，存在本地安全隐患 |
| 2 | 二层结构设计，敏感信息外露 | 多为二层架构，客户端直连服务器，账号密码等敏感信息暴露，外网部署开放风险高 |
| 3 | 数据分布分散，整体防护薄弱 | 协议灵活但交互性差、数据共享弱；数据分散在客户端，易受本地灾害、病毒、失窃威胁 |
3.B/S 架构
B/S架构的脆弱性主要表现在：
系统如果使用 HTTP 协议， B/S架构相对 C/S 架构而言更容易被病毒入侵，虽然最新的H T T P协议在安全性方面有所提升，但还是弱于 C/S。
4.事件驱动架构
事件驱动架构是一种流行的分布式异步架构，是一种适合高扩展工程的、较流行的分布式异构架构模式，有较高柔性，它由高度解耦、单一目的异步接收的事件处理组件和处理事件组成。
事件驱动架构的脆弱性主要表现在：
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 组件调度不可控 | 组件自主触发事件，无法确定响应组件与执行顺序，系统控制力下降 |
| 2 | 数据传输存在隐患 | 组件间事件传参，大数据量场景下的数据交换与传递机制存在短板 |
| 3 | 业务逻辑复杂度高 | 事件解耦导致组件间依赖隐晦，整体逻辑关系混乱、难以梳理 |
| 4 | 易触发逻辑死循环 | 事件联动由代码逻辑驱动，不合理编码极易形成循环调用死锁 |
| 5 | 高并发处理风险大 | 高并发事件易引发响应迟缓、数据错乱、数据丢失等问题 |
| 6 | 固化流程易被利用 | 响应流程固定僵化，操作违规或绕过限制时，易诱发安全漏洞 |
5.MVC架构
M V C架构的脆弱性主要表现在：
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 架构复杂、性能损耗 | MVC分层拆分提升结构复杂度，产生冗余更新，降低系统运行效率 |
| 2 | 视图与控制器耦合强 | 二者高度依赖、相互绑定，无法独立拆分，不利于组件复用 |
| 3 | 数据访问效率低下 | 视图需多次调用模型接口获取数据，存在无效重复访问，损耗性能 |
| 补充 | 安全机制存在短板 | 缺少调用方安全校验，数据传输防护不足，易被攻击利用 |
6.微内核结构
微内核架构是指内核的一种精简形式，将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入选，达到系统的可扩展性、更好地适应环境要求。微内核架构也被称为插件架构模式 (Plug-in Architecture Pattern), 通常由内核系统和插件组成。
微内核架构的脆弱性主要表现在：
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 整体优化能力不足 | 内核仅保留基础能力，外部服务独立运行，无法开展全局整体性能优化 |
| 2 | 进程通信开销更高 | 模块间频繁进程间通信，相比单内核架构，运行效率损耗明显 |
| 3 | 模块通信损耗严重 | 系统拆分大量独立功能模块，虽便于维护迭代，但通信延迟与损耗突出 |
7.微服务架构
微服务架构的脆弱性主要表现在：
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 分布式复杂度高 | 需面对分布式架构带来的各类复杂问题，开发难度大幅提升 |
| 2 | 服务通信容错难 | 自行设计服务通信机制，需代码处理网络延迟、服务不可用等失效问题 |
| 3 | 运维管理成本高 | 多服务、多实例部署，生产环境统筹管控与治理难度显著增加 |
18.8安全架构设计案例分析
18.8.1电子商务系统的安全性设计
原理介绍
认证、授权和审计 (Authentication Authorization and Accounting,AAA) 是运行于宽带网络接入服务器上的客户端程序。 A A A提供了一个用来对认证、授权和审计三种安全功能进行配置的一致的框架，实际上是对网络安全的一种管理。
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 身份核验 | 认证，校验用户访问权限，核验账号、口令等身份信息 |
| 2 | 权限分配 | 授权，限定用户可访问的服务范围，管控资源使用权限 |
| 3 | 行为记录 | 审计，记录用户资源使用行为，包含IP、MAC等日志信息 |
软件架构设计
RADIUS 软件主要应用于宽带业务运营的支撑管理，是一个需要可靠运行且高安全级别的软件支撑系统。 R A D I U S软件的设计还需要考虑一个重要的问题，即系统高性能与可扩展性。
RADIUS软件架构分为三个层面：协议逻辑层、业务逻辑层和数据逻辑层
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 协议逻辑层：通信转发 | 实现RFC标准协议，负责网络连接建立、通信与断开，作为转发引擎分发数据，隔离协议与业务 |
| 2 | 业务逻辑层：核心处理 | RADIUS架构核心，解析数据包并分发，提供认证、授权、计费业务进程，依托共享内存、进程+线程模型提升处理效率 |
| 3 | 数据逻辑层：数据统一管控 | 统一管理数据库代理池，复用数据库连接、降低库压力，减少数据库依赖，提升多数据库适配能力 |
18.8.2基于混合云的工业安全架构设计
混合云融合了公有云和私有云，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的。
| 序号 | 总结 | 核心内容 |
|---|---|---|
| 1 | 设备安全：生产硬件防护 | 管控生产危险有害因素，依托专用安全装置与设备，通过维护、保养、检测保障工业设备稳定可靠运行 |
| 2 | 网络安全：全域网络防护 | 保护网络软硬件与数据，防范破坏、篡改、泄露；部署防火墙、入侵检测、漏洞扫描、全网杀毒等防护手段 |
| 3 | 控制安全：生产过程可控 | 规避生产事故、规范安全管理、消除隐患；依靠冗余、容错、降级、备份、容灾等技术保障生产控制稳定 |
| 4 | 应用安全：业务应用防护 | 防范应用运行与数据传输泄露风险；通过密码策略、访问控制、时效管控、告警机制等强化应用访问安全 |
| 5 | 数据安全：全生命周期防护 | 覆盖数据采集至共享全流程，结合加密、完整性校验等数据防护，以及备份、异地容灾等存储防护，兼顾跨层交换与公有云存储安全 |
