Day37-23｜18.7.1 系统架构的脆弱性分析概述：从“哪里可能被攻破”到“风险如何被控制”

对应教材目录：第 18 章 安全架构设计理论与实践 → 18.7 系统架构的脆弱性分析 → 18.7.1 概述

学习目标：理解脆弱性、威胁、风险和安全事件的区别；掌握系统架构脆弱性分析的对象、方法和输出物；能够从边界、身份、数据流、依赖、配置、部署和运维角度识别架构弱点，并在案例题中给出优先级明确的改进方案。

一、什么是系统架构脆弱性

脆弱性是系统在设计、实现、配置、部署或运行管理中存在的缺陷或弱点，可能被威胁主体利用，导致机密性、完整性、可用性或抗抵赖能力受到影响。脆弱性不一定已经造成事故，但它表示系统在某些条件下缺少足够防护。

例如，管理接口暴露在公网是架构暴露面；多个服务共用一个超级账号是身份和权限脆弱性；数据库备份没有加密是数据保护脆弱性；系统只依赖单一机房是可用性脆弱性；日志由业务节点本地保存且无集中备份是审计脆弱性。

可以用下面的关系理解：

资产 Asset + 威胁 Threat + 脆弱性 Vulnerability
                    |
                    v
                 风险 Risk
                    |
                    v
      被利用后形成安全事件 Security Incident

脆弱性是“系统哪里不够强”，威胁是“谁可能以什么方式攻击”，风险是“发生可能性和影响的组合”，事件是“已经发生并造成或可能造成影响的事实”。考试中如果把四者混写，往往会导致分析不完整。

二、脆弱性分析的目标

脆弱性分析不是为了列出尽可能多的漏洞，而是为了支持架构决策。主要目标包括：

  1. 识别关键资产、信任边界和暴露面。
  2. 发现设计阶段无法通过简单补丁解决的结构性问题。
  3. 判断攻击者能否沿攻击路径到达高价值资产。
  4. 评估现有控制的覆盖范围、强度和失效后果。
  5. 按业务影响和修复成本安排优先级。
  6. 为安全架构、测试、运维和应急响应提供依据。

优秀的脆弱性分析应当能够回答：弱点在哪里？需要什么前置条件？谁能利用？会影响哪些资产？现有控制能否阻断？修复后如何验证？如果暂时不能修复，如何降低风险？

三、分析对象的七个层面

1. 业务与数据层

识别核心业务、关键流程、敏感数据、重要操作和合规要求。例如支付、审批、权限变更、生产控制和个人信息处理，通常比普通查询具有更高风险。

2. 应用与接口层

检查身份认证、授权、输入校验、会话、接口暴露、错误处理、文件上传、批量导出和业务状态机。架构层面要关注接口是否有统一入口、是否存在绕过路径、服务是否过度信任客户端。

3. 服务与组件层

检查服务之间的信任关系、服务账号、消息队列、缓存、搜索引擎、任务调度和中间件。一个低权限服务如果能够访问整个数据库，就可能成为横向移动跳板。

4. 数据与存储层

检查数据库、对象存储、日志、备份、快照、临时文件和数据同步。要追踪数据副本，而不是只看主库。敏感数据往往在报表、缓存、搜索和测试环境中形成新的泄露面。

5. 网络与部署层

检查公网入口、管理面、网络分区、访问控制、负载均衡、容器编排、云安全组和跨地域链路。内网横向访问过宽、管理接口与业务接口混在一起，都是典型架构弱点。

6. 供应链与依赖层

检查第三方库、镜像、插件、外包服务、云服务、证书和构建制品。依赖组件虽然不在业务代码中，但可能拥有执行、联网或读取数据的能力。

7. 运维与治理层

检查账号生命周期、变更审批、补丁、密钥轮换、日志分析、备份恢复、应急权限和安全培训。很多重大事故不是设计完全错误，而是上线后配置漂移、临时例外长期保留和离职权限未回收造成的。

四、信任边界与攻击面

1. 信任边界

信任边界是安全策略、身份或权限发生变化的地方，例如互联网与内网之间、用户与服务之间、服务与数据库之间、租户之间、生产与测试之间。边界越模糊，越容易出现“默认信任”。

互联网用户
    |
    v
WAF/网关 —— 信任边界 1
    |
    v
业务服务 —— 信任边界 2
    |
    v
数据访问层 —— 信任边界 3
    |
    v
数据库/对象存储

每个边界都应明确认证、授权、输入验证、加密、审计和故障策略。不能因为请求已经通过网关，就假设内部服务无需重新校验。

2. 攻击面

攻击面是攻击者能够接触或影响的入口集合，包括公网 API、登录页面、文件上传、远程管理、开放端口、消息主题、依赖组件、CI/CD、备份下载和人员账号。减少攻击面通常比在每个入口上增加复杂防护更有效。

五、常见架构脆弱性类型

1. 单点信任

系统把全部权限、密钥或决策集中在一个账号、一个服务或一个管理入口，一旦该点被攻破，攻击者可以直接获得全局能力。改进方式包括职责分离、多方授权、最小权限、分区和二次确认。

2. 隐式信任

服务通过网络位置、请求头或客户端传参判断调用者，而没有验证可信身份。改进方式是采用服务身份、双向认证、服务端生成租户和主体属性，并在每个敏感边界重新授权。

3. 权限累积

用户长期保留历史角色，服务账号获得超出职责范围的权限，临时管理员权限没有到期回收。改进方式包括定期复核、临时授权、自动回收和权限使用分析。

4. 数据副本失控

主库有加密和访问控制，但缓存、日志、报表、备份和测试数据没有同等级保护。需要建立数据血缘和生命周期管理，明确每个副本的责任人、保留期和销毁方式。

5. 依赖和配置漂移

生产环境使用未验证镜像，组件版本不一致，安全组被临时放宽后没有恢复，配置中心规则被手工覆盖。应采用版本化、签名制品、自动基线、配置审计和持续验证。

6. 故障降级失守

认证服务、策略服务或密钥服务故障时，应用为了保持可用而默认放行请求，形成严重安全漏洞。应按操作风险设计故障策略：普通读取可有限缓存，高风险写入和导出默认拒绝或转人工审批。

六、脆弱性分析方法

1. 资产—威胁—控制分析

先列出资产及价值，再列出威胁和攻击条件，然后检查现有控制。适合快速评审和案例题。

资产 威胁 脆弱性 现有控制 改进
用户隐私 批量导出 导出无审批 登录认证 字段脱敏、审批、限流、审计
交易金额 越权修改 客户端可传金额 接口登录 服务端重算、签名、状态机
数据库 内部滥用 共用超级账号 防火墙 个人账号、临时授权、堡垒机

2. 数据流图分析

沿数据流检查入口、转换、存储、共享和销毁。重点寻找未加密链路、未验证输入、信任边界穿越、异常流和旁路数据流。

3. 攻击树

以高价值目标为根节点，分解实现目标的路径。例如“窃取客户数据”可能通过盗取用户账号、利用接口越权、读取备份、入侵运维账号和攻击测试环境实现。攻击树有助于识别多条路径中的共同薄弱点。

4. STRIDE 等威胁建模方法

可以从仿冒、篡改、抵赖、信息泄露、拒绝服务和权限提升等方向分析。方法名称不是答题重点，重点是能把威胁对应到架构组件、控制措施和验证方法。

5. 故障和滥用案例

除了正常流程，还要分析账号被盗、消息重放、批量导出、策略服务不可用、密钥过期、数据库主备切换和供应链制品被替换。滥用案例往往比正常用例更容易暴露架构弱点。

七、风险排序与修复优先级

风险通常由发生可能性、影响程度、暴露范围和现有控制共同决定。可以采用定性分级，也可以在企业内部使用评分模型。

优先级 = 影响程度 × 利用可能性 × 暴露范围 × 控制失效程度

不能只按扫描工具的严重级别排序。一个中等漏洞如果位于公网入口并能直接访问核心数据，可能比内网孤立的高分漏洞更紧急。修复建议应说明：立即阻断措施、根本性架构改造、验证方法和剩余风险。

八、案例分析：多租户平台的脆弱性分析

某 SaaS 平台通过 API 网关、微服务和共享数据库服务多个租户。初步发现：租户 ID 由客户端传入；服务间使用共享令牌；管理员可导出全库；备份保存在公开对象存储；策略服务故障时网关默认放行；审计日志只保存在应用本地。

分析结果如下：

  1. 租户 ID 不可信，可能导致水平越权。应从认证上下文取得租户，服务端强制过滤，并增加行级策略或数据访问层隔离。
  2. 共享令牌导致主体不可区分和权限过大。应采用服务身份、短期凭据和服务间最小授权。
  3. 全库导出属于高风险能力。应拆分字段和数据范围权限，采用审批、脱敏、水印和数量限制。
  4. 公开备份导致批量泄露。应关闭公开访问，启用加密、短期链接、访问审计和恢复演练。
  5. 策略服务故障默认放行属于降级失守。普通查询可使用短时缓存，高风险操作应拒绝或转人工。
  6. 本地日志易丢失和篡改。应集中采集、统一关联标识、只追加保存并设置告警。

优先级上，公开备份和默认放行应立即处置；租户隔离和共享身份应作为根本改造；审计和恢复能力作为短期增强与持续治理项目推进。

九、架构评审输出物

一份可用的脆弱性分析不应只有问题列表，还应包括：

  • 系统边界、信任边界和关键数据流图。
  • 资产清单、数据分级和关键业务清单。
  • 威胁场景、攻击路径和前置条件。
  • 脆弱性描述、影响范围和风险等级。
  • 现有控制、控制缺口和改进方案。
  • 责任人、完成期限、验证用例和剩余风险。
  • 例外批准、临时补偿措施和复评时间。

十、案例题答题模板

可以采用“资产—边界—路径—控制—验证”结构：

  1. 识别高价值资产及其安全目标。
  2. 画出外部入口、信任边界、服务、数据和管理面的关系。
  3. 列出可被利用的脆弱点及攻击前置条件。
  4. 判断脆弱点造成的机密性、完整性、可用性或抗抵赖影响。
  5. 提出预防、检测、响应和恢复四类控制。
  6. 按风险和修复成本安排优先级。
  7. 写出验证方式，包括越权测试、配置检查、渗透、恢复演练和审计复核。

十一、课后练习

练习 1

区分威胁、脆弱性、风险和安全事件。

参考答案：威胁是可能造成危害的主体或行为；脆弱性是系统可被利用的弱点；风险是威胁利用脆弱性后造成影响的可能性和程度；安全事件是已经发生或正在发生的异常和攻击事实。

练习 2

为什么“内网服务默认可信”是一种架构脆弱性？

参考答案：攻击者一旦通过低权限服务、被盗账号或供应链漏洞进入内网，就可能横向访问其他服务。内网位置不能证明主体身份和请求合法性，应采用服务身份、最小权限和边界内重新授权。

练习 3

请对“策略服务故障时默认放行”进行分析。

参考答案要点：这是故障降级脆弱性，可能导致所有未授权请求通过；应根据操作风险分类，低风险读取使用短缓存，高风险写入、导出和权限变更默认拒绝或人工审批；同时增加健康检查、超时、告警和恢复验证。

练习 4

论文题：论“云原生多租户系统的安全脆弱性分析”。请列出至少八个分析点。

参考答案要点：身份与租户隔离、服务间信任、API 暴露、容器和镜像、编排权限、密钥、对象存储、数据库副本、网络策略、配置漂移、日志审计、供应链、故障降级和备份恢复。

十二、今日复盘

  • 我能否准确区分威胁、脆弱性、风险和事件？
  • 我是否能从七个层面检查架构弱点？
  • 我能否画出信任边界和攻击路径？
  • 我是否考虑了正常流程之外的滥用和故障降级？
  • 我能否按影响和暴露面安排修复优先级？
  • 我能否输出“问题—影响—改进—验证”的完整答案？

脆弱性分析的核心结论是：不是发现问题越多越好，而是要把资产、边界、威胁、弱点、控制和验证连接起来，识别真正能够到达高价值资产的攻击路径，并用分层防御和可执行的治理措施降低风险。