第四章：信息系统架构（4.7安全架构-4.8云原生架构）

4.7 安全架构

安全保障以风险和策略为基础，在信息系统的整个生命周期中，安全保障应包括技术、管理、人员和工程过程的整体安全，以及相关组织机构的健全等。

4.7.1 安全威胁

安全在日常中是重中之重，一起来看下都有哪些安全威胁：

安全威胁	具体描述
信息泄露	信息被泄露或透露给某个非授权的实体
破坏信息的完整性	数据被非授权地进行增删、修改或破坏而受到损失
非法访问(非授权访问)	某一资源被某个非授权的人或非授权的方式使用
窃听	窃取系统中的信息资源和敏感信息
业务流分析	对系统进行长期监听
假冒	非法用户冒充成为合法用户,或者特权小的用户冒充成为特权大的用户的目的
旁路控制	攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权
授权侵犯	被授权以某一目的使用某一系统或资源的某个人，却将此权限用于其他非授权的目的，也称"内部攻击"
特洛伊木马	软件中含有一个察觉不出的或者无害的程序段
陷阱门	在某个系统或某个部件中设置了机关
抵赖	一种来自用户的攻击，否认自己曾经发布过的某条消息或伪造一份对方来信
重放	出于非法的目的而被重新发送
计算机病毒	传染和侵害的功能程序
人员渎职	一个授权人为了钱或利益、或由于粗心而将信息泄露给一个非授权的人
媒体废弃	信息被从废弃的磁盘或打印过的存储介质中获得
物理侵入	物理控制获得对系统的访问
窃取	重要的安全物品，如令牌或身份卡被盗
业务欺骗	某一伪系统或系统部件欺骗合法用户或系统自愿地放弃敏感信息

4.7.2 定义和范围

安全架构是在架构层面聚焦信息系统安全方向上的一种细分。

安全防线	详细描述
系统安全架构	指构建信息系统安全质量属性的主要组成部分以及它们之间的关系。系统安全架构的目标是如何在不依赖外部防御系统的情况下,从源头打造自身的安全
安全技术体系架构	指构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各部分的安全防御能力
审计架构	指独立的审计部门或其所能提供的风险发现能力，审计的范围主要包括安全风险在内的所有风险

4.7.3 整体架构设计

构建信息安全保障体系框架应包括技术体系、组织机构体系和管理体系等三部分。也就是说，人、管理和技术手段是信息安全架构设计的三大要素，而构建动态的信息与网络安全保障体系框架是实现系统安全的保障。

WPDRRC模型有六个环节三大要素：

六个环节： 预警(w)、保护(P)、检测(P)、响应(R)、恢复（R）和反击(C)，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。

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

信息系统安全设计重点考虑两个方面 : 一是系统安全保障体系; 二是信息安全体系架构。

系统安全保障体系：
是由安全服务、协议层次和系统单元三个层面组成

信息安全体系架构： 包括物理安全，系统安全，网络安全，应用安全，安全管理

4.7.4 网络安全架构设计

1.OSI安全架构

OSI开放系统互联安全体系的5类安全服务包括鉴别、访问控制、数据机密性、数据完整性和抗抵赖性

OSI定义分层多点安全技术体系架构，也称为深度防御安全技术体系架构，它通过以下三种方式将防御能力分布至整个信息系统中。

a：多点技术防御 ：网络和基础设施、边界、计算环境

b:分层技术防御 ：一个有效的措施是在对手和目标间使用多个防御机制。为了减少这些攻击成功的可能性和对成功攻击的可承担性，每种机制应代表一种唯一的障碍，并同时包括保护和检测方法。

c:支撑性基础设施 : 包括公钥基础设施以及检测和响应基础设施。

2.认证框架

鉴别的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。

鉴别信息是指申请者要求鉴别到鉴别过程结束所生成、使用和交换的信息。

鉴别信息的类型有交换鉴别信息、申请鉴别信息和验证鉴别信息。

鉴别服务分为以下阶段:安装阶段、修改鉴别信息阶段、分发阶段、获取阶段、传送阶段、验证阶段、停活阶段、重新激活阶段、取消安装阶段。

3.访问控制框架

访问控制(Access Control）决定开放系统环境中允许使用哪些资源，在什么地方适合阻止未授权访问的过程。

●ACI(访问控制信息） 是用于访问控制目的的任何信息，其中包括上下文信息。

●ADI(访问控制判决信息） 是在做出一个特定的访问控制判决时可供ADF使用的部分(或全部)ACl。

●ADF(访问控制判决功能) 是一种特定功能，它通过对访问请求、ADI以及该访问请求的上下文使用访问控制策略规则而做出访问控制判决。

●AEF（访问控制实施功能) 确保只有对目标允许的访问才由发起者执行。

4.机密性框架

机密性(Confidentiality)服务的目的是确保信息仅仅是对被授权者可用。

1.通过禁止访问提供机密性；
2.通过加密提供机密性

5.完整性框架

完整性（Integrity)框架的目的是通过阻止威胁或探测威胁，保护可能遭到不同方式危害的数据完整性和数据相关属性完整性。所谓完整性，就是数据不以未经授权方式进行改变或损毁的特征。

6.抗抵赖性框架

抗抵赖服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。框架所描述的抗抵赖服务的目的是提供有关特定事件或行为的证据。

抗抵赖由4个独立的阶段组成 : 分别为证据生成，证据传输、存储及恢复，证据验证和解决纠纷。

4.7.5 数据库系统安全设计

数据库的安全问题可以说已经成为信息系统最为关键的问题。

1.数据库完整性设计原则

(1）静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。

(2）实体完整性约束和引用完整性约束是关系数据库最重要的完整性约束

(3）要慎用目前主流DBMS都支持的触发器功能，一方面由于触发器的性能开销较大;另一方面，触发器的多级触发难以控制，容易产生错误，非用不可时，最好使用Before型语句级触发器。

(4）在需求分析阶段就必须制定完整性约束的命名规范。

(5）要根据业务规则对数据库完整性进行细致的测试

(6）要有专职的数据库设计小组

(7）应采用合适的CASE(计算机辅助软件工程)工具来降低数据库设计各阶段的工作量。

2.数据库完整性设计示例

数据库完整性约束可分为6类:列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。动态约束通常由应用软件来实现。

3.数据库完整性设计示例

基于DBMS的数据库完整性设计大体分为需求分析阶段、概念结构设计阶段和逻辑结构设计阶段。

4.7.6 (了解为主)

4.8 云原生架构

4.8.1 发展概述

DevOps可以看作是开发、技术运营和质量保障三者的交集

4.8.2 架构定义

技术部分依赖于传统云计算的3层概念：即基础设施即服务(laas)、平台即服务(PaaS）和软件即服务(SaaS）

云原生的代码通常包括三部分:业务代码、三方软件、处理非功能特性的代码

a)业务代码： 实现业务的逻辑代码

b)三方软件： 业务代码中依赖的第三方库

c)处理非功能特性的代码： 指实现高可用、安全、可观测性等非功能性能力的代码

PS: 三部分中只有业务代码是核心，是给业务真正带来价值的，另外两个部分都只算附属物。

4.8.3 基本原则

常见原则	描述
服务化原则	微服务架构、小服务(MiniService)架构等
弹性原则	可以随着业务量的变化而自动伸缩
可观测化原则	主动通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况
韧性原则	核心目标是提升软件的平均无故障时间(Mean Time Between Failure, MTBF)。从架构设计上，韧性包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ(Availability Zones,可用区）内的高可用、单元化、跨region(区域)容灾、异地多活容灾等。
所有过程自动化原则	实现整个软件交付和运维的自动化
零信任原则	引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制
架构持续演进原则	此云原生架构本身也必须是一个具备持续演进能力的架构，而不是一个封闭式架构

4.8.4 常用架构模式

常用架构模式	描述
服务化架构模式	标准架构模式，典型模式是：微服务和小服务模式
Mesh化架构模式	把中间件架构从业务中分离，让中间件软件包与业务代码进一步解耦
Serverless模式	将“部署"这个动作从运维中“收走”
储存计算分离模式	分布式环境中的CAP(一致性:Consistency:可用性: Availability:分区容错性: Partition tolerance)困难主要是针对有状态应用，因为无状态应用不存在c(一致性）这个维度，因此可以获得很好的A(可用性）和Р(分区容错性）
分布式事务模式	大颗粒度的业务需要访问多个微服务
可观测架构	包括Logging（日志)、Tracing（跟踪)、Metrics度量)
事件驱动架构	本质上是一种应用/组件间的集成架构模式

分布式事务模式分为一下几点：

①传统采用XA (eXtended Architecture）模式，虽然具备很强的一致性，但是性能差

②基于消息的最终一致性通常有很高的性能，但是通用性有限

③Tcc(Try-Confirm-Cancel模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效:但是对业务的侵入性非常强，设计开发维护等成本很高

④SAGA模式（指允许建立一致的分布式应用程序的故障管理模式)与TCC模式的优缺点类似但没有Try这个阶段，而是每个正向事务都对应一个补偿事务，也使开发维护成本高

⑤开源项目SEATA的AT模式: 非常高性能，无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制

PS: 更多关于系统集成项目管理工程师笔记 点击专栏订阅(持续更新~~~)