Day37-01｜18.1 安全架构概述：从安全目标到可信、可控、可恢复的体系

对应教材：第 18 章 安全架构设计理论与实践——18.1 安全架构概述
学习定位：理解安全架构的定义、范围、目标和组成，建立从资产、威胁、风险到安全控制的分析框架，掌握安全架构与业务架构、数据架构、技术架构和运维治理之间的关系，为后续安全模型、体系规划和案例设计打基础。

一、为什么系统架构必须包含安全架构

现代信息系统很少是孤立运行的。它们通常连接互联网、移动终端、云平台、第三方系统、物联网设备和内部办公网络，数据在多个区域、多个组织和多个处理节点之间流动。系统一旦上线，安全问题就不再只是某个防火墙或杀毒软件的问题，而是会影响业务连续性、数据可信度、组织责任和法律合规。

安全架构的任务，是把安全目标落实到系统的结构、边界、组件、接口、流程和运营机制中，使系统具备可预防、可检测、可响应、可恢复和可审计的能力。它回答的不仅是“如何阻止攻击”，还包括：

1. 哪些资产最重要，为什么重要？
2. 谁可以访问哪些资源，访问依据是什么？
3. 如果攻击者已经进入内部，如何限制横向移动？
4. 如果配置或数据被篡改，如何发现和恢复？
5. 如果核心组件失效，业务如何继续或安全降级？
6. 谁负责安全决策、审批、操作、监控和事件处置？

安全架构不是在项目末期添加的一层设备，而是贯穿需求、设计、开发、部署、运维和退役的系统性约束。可以把它理解为一种“可信运行结构”：系统不仅要完成业务功能，还要能够证明业务是在正确身份、正确权限、正确边界和可追踪状态下完成的。

二、安全架构的定义与范围

2.1 安全架构的基本定义

安全架构是围绕信息系统的保密性、完整性、可用性、真实性、不可否认性和可审计性等目标，对安全策略、组织机制、技术措施、系统组件、数据流和运行流程进行整体设计的结果。

安全架构具有三个特点：

第一，整体性。安全控制需要覆盖人员、流程、技术、数据、设备、网络、应用和基础设施，不能只看某个边界设备。

第二，层次性。不同层次负责不同安全目标，例如终端层负责设备可信和恶意软件防护，网络层负责区域隔离和访问控制，应用层负责认证授权和输入校验，数据层负责加密、完整性和备份。

第三，动态性。系统资产、攻击手段、业务流程和法规要求会变化，安全架构要支持监控、评估、变更、应急和持续改进。

2.2 安全架构的范围

安全架构至少覆盖以下范围：

如果安全架构只覆盖网络边界，应用账号、数据库权限、云资源、开发流水线和供应链仍可能成为薄弱环节。架构师应根据系统范围和风险选择重点，但要明确未覆盖部分的责任和风险接受方式。

三、安全目标与基本属性

3.1 保密性

保密性要求信息只能被授权主体访问。实现手段包括身份认证、访问控制、分区隔离、加密、密钥管理、数据脱敏和最小权限。保密性不只是防止外部窃取，也包括内部越权、日志泄露、备份泄露和调试接口暴露。

3.2 完整性

完整性要求数据、配置、代码、日志和通信内容不被未经授权地修改。常见措施包括数字签名、消息认证码、完整性校验、版本控制、双人审批、不可变备份和配置差异审计。

3.3 可用性

可用性要求授权用户在需要时能够使用系统。高可用、容灾、限流、DDoS 防护、资源隔离、故障切换、备份恢复和应急降级都属于可用性控制。安全设计不能为了阻断攻击而轻易阻断关键业务，应设计分级防护和安全降级策略。

3.4 真实性与不可否认性

真实性要求确认通信主体、操作人员、设备和数据来源确实可信；不可否认性要求主体不能轻易否认其完成过的操作。证书、数字签名、多因素认证、统一身份、可信时间、审计日志和审批记录可以共同支撑这两个目标。

3.5 可审计性

可审计性要求系统能够记录、保护和分析关键活动。有效审计应包含主体、时间、来源、对象、动作、结果、审批和关联上下文。只保存一条“登录成功”日志，通常不足以还原完整事件。

四、资产、威胁、脆弱性和风险

4.1 资产识别

资产包括业务流程、数据、账号、应用、接口、主机、容器、网络设备、密钥、日志、备份、配置和品牌信誉。资产识别要同时考虑价值和依赖关系。例如，支付数据库是核心资产，但身份服务、密钥服务、DNS、时间同步和网络路径也可能是其关键依赖。

可以按价值、敏感度、可用性要求、影响范围和恢复难度进行分类。资产清单需要有责任人、位置、版本、依赖、数据流和生命周期，不能只列出 IP 地址。

4.2 威胁识别

威胁是可能利用弱点造成不利影响的因素，包括恶意攻击、内部越权、供应链植入、误配置、误操作、设备故障、自然灾害和法规变化。识别威胁时应结合业务场景，例如互联网暴露接口面临自动化扫描，生产系统面临操作中断和协议滥用，移动终端面临丢失和恶意应用。

4.3 脆弱性识别

脆弱性是可能被威胁利用的弱点，包括默认密码、过度权限、未修复漏洞、弱加密、配置错误、缺少隔离、日志缺失、备份不可恢复和应急流程未演练。

4.4 风险分析

风险可以理解为威胁利用脆弱性后对资产造成影响的可能性和严重程度。架构设计中不一定要求精确计算一个数学值，但必须能够说明高风险场景、风险优先级、控制措施和剩余风险。

常用分析链条是：

资产 → 威胁 → 脆弱性 → 事件 → 影响 → 现有控制 → 剩余风险 → 处置策略

风险处置可以采取规避、降低、转移、接受或共享。安全架构师要避免声称“完全消除风险”，更准确的表达是将风险降低到组织可接受范围，并通过监控和复评持续管理。

五、安全架构的分层结构

5.1 治理与组织层

治理层确定安全目标、责任、制度、策略、预算和风险接受机制。没有治理，技术控制很难长期执行。需要明确谁拥有资产、谁批准访问、谁负责运维、谁处理事件、谁审核日志，以及发生冲突时谁做最终决策。

5.2 物理与环境层

包括机房门禁、视频监控、供电、消防、温湿度、设备防拆和介质管理。云环境中虽然物理设施由服务商管理，但企业仍需要通过合同、审计报告和服务等级了解责任边界。

5.3 网络与通信层

包括安全域、边界、路由、访问控制、加密通信、入侵检测、流量分析和 DDoS 防护。网络层的主要作用是限制通信路径和传播范围，但不能替代应用和数据层的权限控制。

5.4 主机、终端与运行时层

包括操作系统基线、补丁、主机防火墙、终端检测、容器隔离、运行时防护和配置管理。云原生环境还需要关注镜像、编排平台、服务账号和临时凭据。

5.5 应用与数据层

应用层负责认证、授权、会话、输入校验、接口保护、依赖组件和安全开发；数据层负责分类分级、加密、脱敏、备份、完整性和生命周期。业务层要能够识别高风险操作并要求二次确认或审批。

5.6 运营与响应层

包括资产发现、漏洞管理、日志平台、告警分析、应急响应、威胁情报、演练和复盘。安全架构只有通过运营闭环才能持续有效。

六、安全架构的设计原则

6.1 纵深防御

在不同层次设置互补控制，避免单一防线失效后整体暴露。纵深防御不是简单叠加相同设备，而是让身份、网络、主机、应用、数据和运营控制形成相互验证。

6.2 零信任与持续验证

零信任思想强调不能因为主体位于内部网络就默认可信，每次访问都应结合身份、设备状态、资源、环境和风险进行验证。它不等于取消网络边界，而是将信任从“网络位置”转向“动态身份和策略”。

6.3 最小权限与默认拒绝

主体只获得完成任务所需的最小权限，未明确允许的访问默认拒绝。权限应有时间范围、资源范围和操作范围，并支持定期复审、自动回收和紧急吊销。

6.4 安全内建与失效安全

安全控制应在架构和开发阶段内建，而不是上线后外挂。组件失效时要有明确的安全模式：某些服务适合故障关闭，某些关键生产控制适合在受控条件下保持有限运行。要根据业务风险决定故障开放、故障关闭或降级运行。

6.5 可恢复性

不能假设所有攻击都能被阻止。系统需要准备不可变备份、隔离恢复环境、配置回滚、密钥恢复、灾备切换和业务手工替代流程。恢复能力是安全架构的重要组成部分。

6.6 可观测与可审计

安全控制必须能够被监控和验证。没有日志、指标、事件关联和配置差异，架构师无法证明策略有效。可观测性也要考虑日志本身的敏感性和完整性。

七、安全架构与其他架构的关系

7.1 与业务架构的关系

业务流程决定资产重要性、权限关系、可用性目标和合规要求。安全架构要把业务职责映射为主体、资源、动作和审批，而不是脱离业务建立一套难以使用的规则。

7.2 与数据架构的关系

数据分类、数据流、数据存储位置和共享方式决定加密、脱敏、备份、访问控制和跨境传输要求。安全架构要识别数据从产生到销毁的全生命周期，而非只保护数据库。

7.3 与应用架构的关系

微服务、API、消息队列、容器和无服务器架构会产生大量服务身份和东西向通信。安全架构需要提供服务认证、密钥管理、接口授权、服务网格策略和运行时检测，并避免把所有权限集中在网络边界。

7.4 与技术架构的关系

技术架构决定安全控制可以落在哪些组件上。架构师要明确控制器、云平台、虚拟网络、数据库、负载均衡和终端平台的安全能力，避免方案依赖设备并不支持的功能。

7.5 与运维架构的关系

安全架构需要通过监控、配置、发布、漏洞、备份和应急运维落地。权限分离、审批、自动化、审计和演练都属于安全运行的一部分。

八、安全架构的设计过程

第一步，明确业务目标、合规边界和安全等级。

第二步，识别资产、数据流、信任边界和关键依赖。

第三步，分析威胁、脆弱性、攻击路径和业务影响。

第四步，建立安全目标和质量属性指标，例如认证成功率、日志覆盖率、故障恢复时间和漏洞修复时限。

第五步，设计安全域、身份体系、访问控制、加密、检测、响应和恢复架构。

第六步，将安全控制映射到网络、主机、应用、数据和运营组件，明确责任人和接口。

第七步，进行风险评估、性能评估、可用性评估和成本评估，处理控制之间的冲突。

第八步，通过测试、演练、审计和指标监控验证安全架构，并根据变化持续改进。

九、案例分析：企业统一身份与业务安全架构

某集团有办公系统、订单系统、财务系统和云上数据平台，员工、供应商和服务账号较多，历史上存在共享账号、权限长期不回收和日志分散的问题。企业希望统一身份、加强高风险操作审计，并保证核心业务在身份平台短时故障时可以安全运行。

第一，识别主体和资源。主体包括员工、供应商、管理员、应用服务账号和设备；资源包括办公系统、订单、财务、数据库、云资源、管理接口和敏感数据；动作包括登录、查询、修改、审批、导出和运维。

第二，建设统一身份。采用统一目录或身份联邦，建立账号申请、审批、开通、变更、冻结和注销流程；员工和供应商分离管理，供应商权限设置有效期；高风险操作启用多因素认证和二次审批。

第三，建立基于策略的访问控制。除了身份，还结合角色、设备状态、来源位置、时间、资源敏感度和风险等级判断访问。订单查询、财务导出和生产管理等操作按最小权限配置，默认拒绝未声明访问。

第四，设计故障模式。身份平台短时不可用时，已有有效会话可以在有限期限内继续；高风险新登录必须暂停或使用经过审批的应急账号；应急账号使用双人审批、短时授权和全量审计，身份平台恢复后进行对账。

第五，集中审计。身份、应用、数据库、云平台和管理设备日志统一采集，建立主体关联、时间同步和不可篡改保存；发生异常导出、异地登录或权限提升时触发告警和自动或人工处置。

第六，持续治理。定期进行权限复核、账号清理、异常行为分析、灾备演练和应急账号测试，保证身份架构与组织变化、业务变化和合规要求同步。

十、常见失分点

1. 把安全架构写成防火墙、杀毒和备份产品清单。
2. 只写保密性，不写完整性、可用性、真实性和可审计性。
3. 没有识别资产、数据流、信任边界和关键依赖。
4. 只描述预防，不写检测、响应、恢复和复盘。
5. 只写统一认证，不写授权、权限回收、应急账号和故障模式。
6. 只写零信任口号，不写主体、设备、资源和策略判断依据。
7. 忽略安全控制对性能、可用性、成本和用户体验的影响。

十一、今日必背清单

1. 安全架构是围绕安全目标对策略、组织、技术、组件、数据流和运营进行整体设计。
2. 安全架构范围覆盖治理、物理、网络、主机、应用、数据和安全运营。
3. 基本安全属性包括保密性、完整性、可用性、真实性、不可否认性和可审计性。
4. 风险分析链条是资产、威胁、脆弱性、事件、影响、控制和剩余风险。
5. 纵深防御、最小权限、持续验证、默认拒绝、安全内建和可恢复性是重要原则。
6. 安全架构必须与业务、数据、应用、技术和运维架构协同。
7. 安全控制要覆盖预防、检测、响应、恢复和持续改进。
8. 案例题要写清主体、资源、边界、策略、故障模式、审计和责任。

十二、课后练习

练习一：单项选择

下列哪项最符合安全架构的含义？

A. 只部署边界防火墙和入侵检测设备
B. 对安全策略、组织、技术、组件、数据流和运营机制进行整体设计
C. 只对数据库进行加密
D. 只制定一份安全管理制度

练习二：判断题

只要系统部署在内网，内部用户和设备就可以默认信任，不需要持续认证和授权。（ ）

练习三：简答题

请说明资产、威胁、脆弱性和风险之间的关系，并给出一个网络或应用场景示例。

练习四：案例题

某企业准备建设统一安全架构，要求保护核心数据、支持供应商远程运维、满足审计要求，并且在部分安全平台故障时保证核心业务可控运行。请从身份、网络、数据、运营和恢复五个方面给出设计要点。

十三、参考答案

练习一答案

答案：B。

解析：安全架构是整体性、层次性和动态性的系统设计，不能缩减为某类设备、某类数据或单份制度。

练习二答案

答案：错误。

解析：内部网络同样可能存在被攻陷的终端、越权账号和供应链风险。零信任和持续验证强调根据主体、设备、资源、环境和风险动态判断访问。

练习三答案

参考答案：资产是需要保护的对象，威胁是可能造成不利影响的因素，脆弱性是可被威胁利用的弱点，风险是威胁利用脆弱性后对资产造成影响的可能性和严重程度。例如，财务数据库是资产；外部攻击者是威胁；数据库账号权限过大且未启用多因素认证是脆弱性；攻击者利用该弱点导出敏感数据造成泄露，就是风险事件及其影响。

练习四答案

参考要点：

身份方面，建立员工、供应商、管理员和服务账号的统一身份体系，使用多因素认证、最小权限、临时授权、生命周期管理和高风险操作审批；供应商通过跳板机访问，禁止共享账号。

网络方面，划分互联网、DMZ、应用、数据库、管理和备份安全域，控制南北向和东西向访问；管理面与业务面分离，采用加密通道、微隔离和访问日志。

数据方面，进行数据分级，敏感数据在传输和存储中加密，建立密钥管理、脱敏、备份、完整性校验和数据导出审批。

运营方面，集中采集身份、网络、主机、应用、数据库和云平台日志，统一时间、权限和保留策略；建立漏洞管理、告警分级、事件响应和安全演练。

恢复方面，建立不可变备份、配置和策略版本、隔离恢复环境和灾备切换；安全平台故障时，根据业务风险采用有限会话、应急账号或安全降级，所有应急操作双人审批并全量审计，平台恢复后进行状态对账。

十四、今日复盘

请用一句话解释“安全架构不是产品清单，而是业务可信运行的结构”。参考答案：安全架构要把业务资产、主体、数据流、信任边界、风险和安全控制组织成可执行、可监控、可审计、可恢复的整体，并在业务变化和攻击变化中持续调整。

下一篇进入 18.1.1「信息安全面临的威胁」，进一步分析外部攻击、内部威胁、供应链、物理环境和新型技术带来的风险。