Day37-03｜18.1.2 安全架构的定义和范围：建立跨层次、可治理的安全控制体系

对应教材：第 18 章 安全架构设计理论与实践——18.1.2 安全架构的定义和范围
学习定位：准确理解安全架构的定义、边界、层次和组成，掌握安全策略、组织、技术、数据、运维和生命周期之间的映射关系，能够在案例分析中避免把安全架构写成设备清单或单一网络防护方案。

一、安全架构到底解决什么问题

安全架构解决的是“系统如何在不可信环境中可信运行”的问题。它需要对系统中的主体、资源、数据、通信关系、运行环境和管理流程进行结构化设计，并为保密性、完整性、可用性、真实性、不可否认性和可审计性建立可执行的控制。

安全架构不是某一项产品、某一层网络或某一份管理制度，而是多个视角共同形成的整体结构。一个完整的安全架构至少要说明：

1. 保护对象是什么，价值和重要程度如何？
2. 哪些主体可以做哪些操作，依据是什么？
3. 哪些区域、系统和数据之间可以通信或共享？
4. 控制措施部署在什么位置，由谁负责？
5. 控制措施失效、被绕过或发生冲突时怎么办？
6. 如何监控、审计、评估和持续改进？

可以将安全架构看作一张“约束与保障地图”：

业务目标 → 资产与主体 → 安全策略 → 控制域 → 技术组件 → 运营流程 → 证据与指标

如果只写“部署防火墙、堡垒机、杀毒和备份”，实际上只列出了部分技术组件，没有说明策略、边界、责任和效果，也没有说明应用、数据、身份和恢复环节。

二、安全架构的定义

2.1 广义定义

广义上的安全架构，是组织或信息系统围绕风险治理和安全目标建立的结构、原则、策略、标准、流程、角色、技术控制和运行机制的集合。它适用于企业级安全治理，强调组织、制度、流程与技术之间的协同。

2.2 系统级定义

系统级安全架构，是针对具体系统和业务边界，对资产、数据流、主体、信任边界、威胁、控制措施、部署位置、接口和故障模式进行的安全设计。它要能够指导系统架构、详细设计、开发、部署、运维和验收。

广义架构提供统一原则和治理框架，系统级架构将这些原则映射到具体系统。两者不能互相替代：企业有统一身份平台，并不代表每个应用都自动实现正确授权；系统有完善的 API 鉴权，也不代表企业账号生命周期和审计治理已经完成。

2.3 安全架构的三个视角

可以从三个视角理解安全架构：

1. 结构视角：安全域、组件、边界、数据流、信任关系和依赖。
2. 行为视角：认证、授权、加密、检测、响应、恢复和变更行为。
3. 治理视角：责任、策略、标准、审批、评估、审计和风险接受。

只有三个视角相互一致，安全控制才不会出现“有组件无策略”“有策略无执行”或“有执行无证据”的问题。

三、安全架构的范围

3.1 业务与治理范围

包括业务重要性、合规要求、风险偏好、组织职责、预算、服务等级、供应商责任和决策机制。安全架构要与业务连续性、数据治理和企业风险管理结合，明确哪些风险必须降低，哪些风险可以接受，哪些风险需要转移给服务提供商。

3.2 身份与访问范围

包括员工、客户、供应商、管理员、设备、服务和自动化程序等主体，以及认证、授权、会话、凭据、权限复核、临时访问和权限撤销。身份范围不仅包含“登录”，还包含服务间调用、设备接入、批处理任务和机器身份。

3.3 网络与通信范围

包括互联网、办公网、生产网、数据中心、云、边缘、物联网、无线、远程接入和第三方互联。需要设计安全域、路由边界、访问控制、加密、流量检测、控制面和管理面保护。

3.4 主机、终端与平台范围

包括操作系统、虚拟机、容器、编排平台、移动终端、网络设备、数据库、中间件和云资源。控制内容包括安全基线、补丁、配置、漏洞、运行时、主机身份、可信启动和资源隔离。

3.5 应用与接口范围

包括 Web、移动应用、API、微服务、消息队列、文件接口、批处理和第三方集成。重点是输入校验、身份、授权、会话、接口暴露、数据流、错误处理、依赖组件、密钥和业务风控。

3.6 数据范围

包括数据分类、数据生命周期、存储、传输、处理、共享、备份、归档、脱敏、加密、密钥、完整性和销毁。数据保护要覆盖生产库、缓存、消息、日志、备份、测试环境和开发人员本地副本。

3.7 运营与应急范围

包括资产管理、漏洞治理、配置管理、日志、监控、告警、威胁分析、事件响应、备份恢复、灾备、演练和复盘。安全架构不是上线即结束，必须在运行期间持续验证和改进。

四、安全架构的层次模型

4.1 战略与治理层

治理层确定安全愿景、风险偏好、政策、责任和评价方法。常见输出包括安全战略、管理制度、角色职责、风险接受规则和合规要求。

4.2 业务与信息层

该层分析业务流程、信息分类、业务连续性、数据流和安全等级。它将“财务系统重要”“生产控制不能中断”等业务描述转化为数据、身份、访问和可用性约束。

4.3 应用与服务层

该层负责应用身份、接口、服务间调用、业务权限、应用安全开发、消息和服务治理。微服务环境中，需要特别关注服务账号、服务发现、API 网关和东西向访问。

4.4 技术与基础设施层

包括网络、主机、云、容器、数据库、终端、加密设施和安全设备。技术层要把上层安全策略落实为配置、规则、证书、日志和运行时控制。

4.5 运营与保障层

负责监控、检测、响应、恢复、审计、培训、演练和持续改进。运营层是把静态架构变成长期有效能力的关键。

五、安全架构的控制域

5.1 预防控制

预防控制降低事件发生的概率，包括安全设计、身份认证、最小权限、分区隔离、加密、输入校验、补丁、配置基线和供应链验证。

5.2 检测控制

检测控制发现已经发生或正在发生的异常，包括日志、流量分析、终端检测、漏洞扫描、配置审计、告警关联和威胁情报。检测覆盖范围要与资产价值和攻击路径匹配。

5.3 纠正与响应控制

包括账号吊销、流量阻断、设备隔离、策略回滚、恶意文件清除、配置恢复、证据保全和事件通报。响应动作要有权限、审批、自动化边界和回滚设计。

5.4 恢复控制

包括数据备份、不可变备份、灾备、配置恢复、密钥恢复、重建环境、业务降级和手工替代。恢复控制要通过演练确认实际可行，而不能只在文档中存在。

5.5 治理控制

包括策略制定、权限复核、风险评估、供应商审查、变更管理、审计、合规检查、培训和责任追踪。治理控制保证技术控制有明确的所有者和执行周期。

六、安全策略与技术控制的映射

安全架构设计中经常出现“策略写得很完整，但落不到配置”的问题。解决方法是建立策略—控制—组件—证据的映射表：

这张表可以帮助架构师在案例题中同时写出原则、技术和验证，不会停留在概念口号。

七、安全责任与信任边界

7.1 责任边界

安全架构必须明确责任人：业务负责安全等级和风险接受，数据负责人负责数据分类和使用授权，系统负责人负责应用控制，网络和平台团队负责基础设施控制，安全运营团队负责监控与响应，供应商负责合同约定范围内的安全能力。

如果责任不清，事件发生时会出现“大家都以为别人负责”。对云服务、外包运维和共享平台尤其要形成责任矩阵，明确由谁配置、谁审核、谁监控、谁恢复。

7.2 信任边界

信任边界可能是互联网与内部网、不同租户、不同业务域、应用与数据库、开发与生产、云与本地、管理面与业务面，也可能是同一网络中不同身份和服务之间。边界越重要，越需要明确认证、授权、审计和故障模式。

7.3 共享责任模型

在云或平台服务中，服务商通常负责物理设施、基础平台和部分底层安全，客户负责账号、数据、应用、配置和使用方式。架构师要将共享责任映射到具体控制，不能笼统写“云平台负责安全”。

八、安全架构的生命周期

8.1 规划阶段

识别业务目标、资产、数据、威胁、法规和风险，确定安全等级、原则、边界和预算。此阶段应尽早发现不可接受的架构方向。

8.2 设计阶段

完成信任边界、身份、访问、网络、应用、数据、加密、日志、恢复和责任设计，并进行威胁建模和安全评审。

8.3 实现与上线阶段

将策略转换为代码、配置、规则、证书、镜像和流程，进行安全测试、兼容性测试、性能测试、故障测试和上线前检查。

8.4 运行阶段

持续做资产发现、补丁、漏洞处置、日志分析、权限复核、配置审计、应急演练和指标复盘。运行阶段发现的威胁应反馈到架构设计。

8.5 变更与退役阶段

系统扩容、迁移、接口增加、云资源变化和供应商更换都可能改变攻击面。退役时要撤销账号、证书、密钥、DNS、路由、备份和数据副本，防止“系统下线但访问仍然存在”。

九、安全架构的质量属性

安全控制自身也需要质量属性：

1. 有效性：是否真正降低目标风险？
2. 覆盖性：关键资产和攻击路径是否都在控制范围？
3. 可用性：安全平台故障是否造成不可接受业务中断？
4. 性能：加密、检测和审计是否引入过大延迟？
5. 可扩展性：新增用户、租户、终端和区域后是否仍可管理？
6. 可运维性：规则、证书、权限、日志和事件是否易于维护？
7. 可审计性：是否能够提供配置、操作和事件证据？
8. 可恢复性：安全控制或数据受损后是否能够恢复？

架构评审时要同时查看安全目标和这些质量属性，避免一个安全措施改善了保密性，却严重破坏可用性或运维能力。

十、案例分析：混合云平台的安全架构范围划分

某企业将客户服务、订单、数据分析和研发环境部署在本地与公有云中。平台使用 Kubernetes、消息队列、数据库和对象存储，研发团队与运维团队共享部分云账号。企业要求客户数据不能被非授权人员导出，生产与测试隔离，研发能够自动发布，安全团队能够审计。

第一，确定范围。安全架构覆盖本地与云网络、统一身份、云组织和账号、Kubernetes 控制面、镜像仓库、CI/CD、消息和数据库、对象存储、终端、日志和备份，而不是只保护公网入口。

第二，划分信任域。研发、测试、生产、数据分析和管理分别建立逻辑区域；不同租户或客户数据按标签、数据库、密钥和访问策略隔离；CI/CD 发布身份与人工管理员身份分离。

第三，建立控制映射。生产变更需要审批和签名镜像；对象存储默认私有并限制导出；数据库使用最小权限和敏感字段脱敏；服务间使用身份认证和网络策略；云账号采用组织级策略、多因素认证和短期凭据。

第四，建立运营。集中采集云审计、Kubernetes、CI/CD、数据库、对象存储和身份日志，建立异常导出、权限提升、镜像变更和生产登录告警；漏洞、配置偏差和密钥泄露进入统一处置流程。

第五，设计故障和恢复。云身份或安全平台故障时，生产已有服务按有限策略运行，高风险变更暂停；数据和配置使用隔离、不可变备份，定期验证跨区域恢复；平台恢复后执行状态对账和权限复核。

十一、常见失分点

1. 把安全架构定义为网络设备集合。
2. 没有界定系统范围、责任范围和信任边界。
3. 只列控制措施，不说明控制部署位置和运行证据。
4. 忽略生命周期，未考虑新增、变更、迁移和退役。
5. 忽略云、容器、CI/CD、服务账号和供应链。
6. 未分析安全控制本身的性能、可用性和故障模式。

十二、今日必背清单

1. 安全架构是围绕风险和安全目标形成的结构、策略、控制、责任和运营机制。
2. 范围覆盖治理、身份、网络、主机、应用、数据、平台、运营和生命周期。
3. 需要从结构、行为和治理三个视角理解安全架构。
4. 控制域包括预防、检测、响应、恢复和治理。
5. 建立“策略—控制—组件—证据”映射，才能验证安全措施真正落地。
6. 必须明确责任边界、信任边界和云共享责任。
7. 安全架构贯穿规划、设计、实现、运行、变更和退役。
8. 安全控制还要评价有效性、覆盖性、可用性、性能、扩展性和可恢复性。

十三、课后练习

练习一：单项选择

下列哪项最能体现“策略—控制—组件—证据”的安全架构映射？

A. 写明系统需要安全
B. 规定管理员必须强认证，并由 MFA、IAM 和堡垒机实现，保留认证与授权日志
C. 采购一台高性能防火墙
D. 要求员工注意安全

练习二：判断题

安全架构只在系统上线前设计一次，运行阶段不需要根据威胁和业务变化调整。（ ）

练习三：简答题

请说明安全架构与网络安全、应用安全和数据安全之间的关系。

练习四：案例题

某企业将系统迁移到公有云，认为云服务商会负责全部安全。请从共享责任、身份、网络、数据和运营五个方面指出这种观点的问题，并给出改进措施。

十四、参考答案

练习一答案

答案：B。

解析：B 同时表达了安全策略、控制要求、技术组件和可审计证据，形成闭环。其他选项只有口号、单一产品或抽象要求。

练习二答案

答案：错误。

解析：威胁、业务、技术和法规会持续变化，安全架构需要在运行期间进行监控、漏洞治理、权限复核、应急演练、变更评估和持续改进。

练习三答案

参考答案：安全架构是上位的整体框架，定义安全目标、边界、原则、责任和控制体系；网络安全负责通信、区域、链路和流量控制；应用安全负责认证、授权、接口、代码和业务逻辑；数据安全负责分类、访问、加密、完整性、备份和生命周期。三者相互依赖，网络边界不能替代应用授权，应用控制也不能替代数据加密和备份。

练习四答案

参考要点：

共享责任方面，云服务商通常负责物理设施和部分基础平台，客户仍负责账号、配置、网络、数据、应用和使用方式，应通过责任矩阵和合同明确边界。

身份方面，采用企业统一身份、多因素认证、最小权限、短期凭据、服务账号分离和定期复核，禁止共享根账号。

网络方面，划分云账号、VPC、子网和安全域，控制公网入口、东西向访问、云互联、管理面和安全组，建立日志和故障边界。

数据方面，分类分级，传输和存储加密，使用密钥管理、脱敏、导出审批、备份隔离和不可变副本。

运营方面，启用云审计、配置基线、漏洞扫描、镜像检查、日志集中、告警关联、应急剧本和定期复盘，持续验证云资源没有产生新的暴露面。

十五、今日复盘

请回答：“一个安全架构设计完成后，如何证明它不是一张漂亮的架构图？”答案应包括：每项策略有对应控制，每项控制有部署组件，每个组件有配置和责任人，每个关键活动有日志或测试证据，每个故障场景有演练和恢复结果，并且在生命周期变化中持续复评。

下一篇进入 18.1.3「与信息安全相关的国内外标准及组织」，学习标准、法规和组织在安全架构中的作用及答题表达方式。