安全威胁建模是什么：敏感系统的安全分析定义

一、概念定义：什么是安全威胁建模

安全威胁建模（Security Threat Modeling，以下简称”威胁建模”）是一种结构化、系统化的安全分析方法。它在系统的设计、开发或变更阶段，结合业务特性、运行环境与所处理的数据，回答三个问题：系统可能受到哪些攻击、这些攻击会造成什么后果、应当优先采取哪些防护措施。威胁建模通常以”攻击者视角”（adversary view）审视系统，重点识别暴露给外部的攻击面和不同信任等级之间的信任边界。其最终产出不是一份结论文档，而是可跟踪、可验证的改进清单。

为便于理解，可以从三个视角解释这一概念：

• 技术视角：它本质上是一次”架构级的安全审查”。分析对象是系统架构、数据流向、组件之间的调用关系以及外部依赖。分析目标是找出攻击者可以利用的路径，例如未经鉴权的接口、缺少校验的回调、可被篡改的前端参数，以及权限校验的缺失点。
• 流程视角：它是一套可重复执行的方法论，通常遵循”界定范围 → 梳理架构 → 识别威胁 → 评估风险 → 制定缓解 → 验证与追踪”的固定步骤。识别威胁时，可以借助业界通用的威胁分类启发式。例如，按照身份伪造、数据篡改、抵赖、信息泄露、拒绝服务、权限提升等类别逐一排查；也可以针对数据流图中的每一个跨边界调用逐项提问。
• 业务与合规视角：它是连接业务风险与技术实现的桥梁。建模过程会让研发、测试、运维、安全甚至业务方共同明确：哪些资产最重要、哪些风险可以接受、哪些风险必须立即处理。

业界常用一个由四个问题构成的”四问框架”概括威胁建模的核心。这四个问题贯穿整个建模过程：

1. 我们正在构建什么？（What are we building?）
2. 哪里会出错？（What can go wrong?）
3. 针对这些问题，我们应该做什么？（What are we going to do about that?）
4. 我们做得怎么样？（Did we do a good job?）

二、背景与价值：为什么敏感项目需要建模

1. 安全漏洞的修复成本随时间推移急剧上升。 设计阶段发现的安全缺陷，只需修改文档或调整接口约定。上线后暴露的漏洞，往往需要紧急修复、回归测试、版本发布和数据修复，还可能引发资金损失、用户信任危机与监管处罚。威胁建模把安全问题的发现点尽量前移，是降低整体安全成本的有效手段。

2. 支付、账号、权限等系统一旦失守，后果难以挽回。 支付系统涉及资金流转，账号系统承载用户身份凭证，权限系统决定”谁能做什么”，数据敏感系统则直接处理个人身份、联系方式与交易记录等信息。这些系统的共同特点是：攻击成功的收益高、破坏难以逆转，事后补救往往无法恢复已造成的损失。

3. 自动化工具难以覆盖业务逻辑层面的缺陷。 漏洞扫描器和自动化代码分析工具擅长发现已知模式的缺陷，例如注入、跨站脚本、过时组件。但它们很难判断”退款接口是否校验了订单归属人””修改密码时旧密码是否失效””管理员的越权操作是否被记录”等问题。这类缺陷藏在业务规则与权限逻辑中，需要建模时的人工梳理与设计推演。

4. 分布式架构扩大了攻击面。 微服务、容器化、第三方接口与回调集成，使系统边界从”一台服务器”变成”一张调用关系网”。每一次服务间调用、每一条跨网络的数据传输、每一个对外暴露的接口，都可能成为攻击入口。只有先画出整体架构与数据流，才能看清攻击面全貌。

5. 威胁建模本身就是一种安全治理资产。 建模过程中形成的架构图、信任边界与风险清单，可以转化为安全需求、测试用例与上线检查项。它们是后续代码评审、渗透测试、安全审计与合规举证的重要输入。随着系统迭代，模型持续更新，团队对系统的安全认知也会逐步沉淀。

6. 普通小项目可以轻量使用。 功能单一、不处理敏感数据、暴露面很小的内部工具，未必需要投入大量精力做完整建模。但即使是最小的项目，也有必要在关键变更前快速评估”这个接口暴露了什么、可能被谁滥用”。如果条件允许，采用轻量版流程仍然值得。关键项目的投资回报更高，因为一次严重安全事件的损失，往往远超建模投入的成本。

三、核心组成：一个完整的威胁模型包含哪些要素

一个可用的威胁模型通常由以下要素构成。它们既可以是独立文档，也可以嵌入设计文档与需求管理系统。

1. 资产清单。 列出系统需要保护的对象，并为每一项标注价值与敏感度，例如用户口令、支付凭证、会话令牌、交易流水、个人身份信息、密钥与配置。资产清单决定后续所有分析的方向。

2. 系统边界与数据流图。 用组件与连线描述外部用户、前端应用、网关、业务服务、数据库、消息队列、缓存、第三方接口之间的关系，以及数据在各组件之间的流动方向与形态。数据流图是发现攻击面的基础。

3. 信任边界。 标注系统的信任等级发生切换的位置。例如，公网到内网、未认证区域到已认证区域、普通用户区域到管理员区域、应用区到数据区，以及本方系统与第三方系统之间。信任边界跨越处往往是漏洞集中出现的区域。

4. 攻击面清单。 枚举所有可能被攻击者接触的入口，包括对外 API 与页面、回调地址、文件上传、消息消费者、定时任务、管理后台、数据库连接串、云平台访问密钥与运维通道等。

5. 威胁条目。 每条威胁都应包含清晰的要素：威胁主体是谁、攻击入口在哪里、攻击路径是什么、影响哪些资产、后果是什么。以下示例展示了威胁条目的书写方式：

威胁编号 T-003｜支付结果回调伪造

• 威胁主体：外部攻击者
• 攻击入口：支付结果异步通知接口
• 攻击路径：猜测接口地址 → 构造”支付成功”通知 → 触发订单状态变更
• 受影响资产：订单状态、账户余额
• 潜在后果：未付款订单被标记为已支付，造成资金损失
• 现有控制：无（仅依赖接口保密）
• 建议缓解：校验通知签名、核对金额与商户号、使用幂等处理、与支付渠道主动对账

6. 风险评估。 通常从”发生的可能性”与”影响程度”两个维度评估，也可以结合威胁的利用难度、所需权限、检测难度等因素。评估可以使用定性等级（高、中、低），也可以采用数值打分，用于确定处理顺序。

7. 缓解措施与控制矩阵。 每条威胁都对应具体的应对措施与责任人，措施按控制层次可分为：

• 消除：从设计上移除风险，例如敏感数据不落前端；
• 预防：认证鉴权、参数校验、加密；
• 检测：日志审计、监控告警；
• 响应与恢复：限流熔断、资金对账、事件应急。

8. 验证方式与残余风险。 每条措施都要说明如何验证是否生效，例如测试用例、代码评审检查项或上线前的检查清单。对于暂不处理的威胁，需要记录理由、接受人或复评时间。

四、工作原理与实施流程

威胁建模一般按以下六个步骤推进。在迭代开发中，可以将其压缩为轻量流程，在每个需求评审或设计评审时执行。

第一步：界定建模范围。 明确本次建模覆盖哪些业务功能、哪些系统边界和哪些数据，以及本期不做哪些内容。范围一旦失控，建模会迅速沦为泛泛而谈；范围过窄，又会遗漏关键路径。

第二步：绘制架构与数据流。 基于真实架构而非理想化描述绘制数据流图，标注信任边界、外部实体与敏感数据流。若已有接口文档、部署拓扑和调用链记录，可以直接复用。

第三步：逐一识别威胁。 在每个跨信任边界的数据流上，按照通用威胁类别逐项提问。例如：

• 身份伪造：谁能冒用别人的身份调用这个接口？会话令牌与签名机制能否被伪造或重放？
• 数据篡改：请求参数、回调内容、客户端状态是否可被篡改？
• 抵赖：关键操作是否留存了不可否认的记录？
• 信息泄露：返回内容、日志、错误信息中是否暴露了敏感数据？
• 拒绝服务：高频调用、超大请求、阻塞操作是否可导致服务不可用？
• 权限提升：普通用户能否调用管理接口？横向越权访问他人的数据是否可行？

第四步：评估与排序风险。 综合可能性与影响，为每条威胁确定优先级，并把资源集中在高风险项上。对业务系统而言，”低概率但影响巨大”的风险同样需要重点处理。

第五步：设计缓解措施。 针对高风险威胁，从消除、预防、检测、响应四个层次选择控制手段，明确责任人、实施时间点与验证方法。

第六步：验证、追踪与迭代。 将缓解措施转化为测试用例、代码评审项、上线检查清单或监控指标。随着架构变更、新增接口或新的威胁情报出现，及时更新威胁模型。

下面用示意性的结构化清单描述建模要素。清单只是表达方式，真正的价值在于梳理过程与结论：

# 威胁建模要素清单（示意）
scope:
  feature: 支付下单与退款
  assets: [用户令牌, 订单数据, 支付凭证]
data_flows:
  - from: 用户端
    to: 下单接口
    crosses_boundary: true
    data: [用户标识, 金额, 商品编号]
threats:
  - id: T-001
    category: 数据篡改   # 客户端金额被修改
    likelihood: 中
    impact: 高
    mitigation: [服务端以商品定价重新计算金额, 订单幂等控制]
    verification: [金额一致性测试用例, 重复下单接口测试]
residual_risk: []

分析过程还可以抽象为如下伪代码，其思路是把”跨边界的数据流”作为威胁枚举的起点：

for flow in data_flows where flow.crosses_boundary:
    for category in [伪造, 篡改, 抵赖, 泄露, 拒绝服务, 越权]:
        ask: 攻击者能否利用此数据流，在 category 上得手？
        if yes:
            record(threat with path and impact)
            rate_risk(likelihood, impact)
            design_mitigation()
            define_verification()

通俗理解：可以把威胁建模看作在建造大楼之前绘制”安全图纸”。图纸会标出所有门窗与出入口、警戒区与公共区之间的分隔线，以及保险库的位置；接着设想窃贼、破坏者、冒名者分别从哪个入口进入、企图达到什么目的；然后据此决定在哪里安装门禁、监控与报警装置。威胁建模做的正是这件事，只不过对象是软件系统。

五、典型应用场景

威胁建模的适用范围很广，只要系统存在对外交互或处理敏感数据，都可以开展建模。以下几类场景对建模的需求尤为迫切：

• 支付与资金流转：下单、支付、退款、对账、分账等环节涉及金额计算与资金状态变更，是伪造回调、篡改金额、重复支付、越权退款等攻击的高发区。
• 账号与身份认证：注册、登录、找回密码、多因素认证、会话管理、单点登录等环节，需要重点排查暴力破解、凭证填充、会话劫持、重放攻击与验证码绕过等威胁。
• 权限与授权体系：基于角色的访问控制（RBAC）、多租户隔离、管理后台与数据权限，容易因判断逻辑疏漏而产生越权访问。尤其是只校验”是否登录”而缺少”是否属于该资源”的检查，是横向越权的常见成因。
• 数据敏感系统：个人信息、健康数据、金融数据的收集、存储、传输与共享环节，需要关注加密、脱敏、最小化收集、访问审计与数据出境等问题。
• 开放接口与第三方集成：对外 API、回调通知、Webhook、消息订阅等入口位于信任边界之上，需要校验来源真实性、签名、时间戳与重放防护。
• 前后端分离与云原生架构：网关、容器、服务网格、消息队列、对象存储、密钥管理等组件增加了攻击面，建模有助于厘清各层的安全责任。
• 物联网与终端侧系统：设备、移动端与后台之间的通信容易受到中间人攻击、固件篡改与凭证硬编码的威胁，适合在硬件与固件设计阶段就开展建模。

六、相关概念辨析

威胁建模与若干相邻的安全活动容易混淆。明确它们之间的区别与联系，有助于合理规划安全工作。

威胁建模 vs. 渗透测试

• 威胁建模是面向设计的结构化分析，产出风险清单与缓解方案，目的是”在缺陷被利用之前发现它”；
• 渗透测试是对已运行系统开展的模拟攻击，验证特定漏洞是否真实可利用；
• 两者互补：建模指导渗透测试的重点，渗透测试验证建模结论是否准确。

威胁建模 vs. 代码审计（含静态代码分析）

• 代码审计聚焦代码实现层面的缺陷，例如注入、硬编码密钥、不安全的加解密方式；
• 威胁建模聚焦系统结构与业务流程层面的风险；
• 二者结合，才能兼顾”单点缺陷”与”整体设计”。

威胁建模 vs. 漏洞扫描

• 漏洞扫描依赖特征库，批量发现已知组件漏洞与配置问题，自动化程度高；
• 但难以识别业务逻辑漏洞，也容易遗漏自行开发代码中的缺陷。

威胁建模 vs. 风险评估与合规审计

• 风险评估是更广泛的管理活动，覆盖资产、威胁、脆弱性与控制措施；
• 威胁建模可视为风险评估在软件系统层面的具体化；
• 合规审计则侧重检查是否满足法规与标准要求，建模产出常作为审计证据。

威胁建模 vs. 隐私影响评估

• 隐私影响评估关注个人数据的收集、使用、存储与共享是否合法、正当、必要，侧重合规与用户权益；
• 威胁建模关注数据被攻击者获取或滥用的技术风险；
• 对处理大量个人数据的系统，两者通常并行开展、相互引用。

七、使用注意事项

1. 坚持攻击者视角。 建模最常见的误区，是用开发者视角”自证安全”。开发者往往认为”内部系统没人会乱来””前端已经做了限制”，而攻击者恰恰会从最不设防的地方入手。所有关键校验都应放在服务端，并假设客户端输入完全不可信。

2. 范围要有重点。 优先覆盖核心业务链路与敏感数据流。范围过大会导致建模停留在表面，范围过小则会遗漏关键路径。

3. 结论必须可执行。 每条威胁都应落实到责任人、具体措施与验证方式，并纳入研发任务跟踪。只列风险、不给方案的建模，价值有限。

4. 控制要分层设计。 纵深防御原则要求在同一风险点上部署多重控制。例如，支付回调既校验签名，也核对金额与订单归属，还通过定时对账发现异常。

5. 防止”文档化陷阱”。 威胁模型如果一次写完便束之高阁，就会迅速与真实系统脱节。建议随架构变更同步更新，并定期复评残余风险。

6. 轻量流程优先于形式。 小团队可以采用”四问框架”加一张数据流图的方式快速建模，避免被复杂的表格与流程拖累。

7. 引入多方视角。 除了安全人员，业务方最了解资金与业务流程，运维人员最了解部署环境与访问通道，测试人员最擅长构造异常输入。多方参与才能覆盖单视角的盲区。

8. 关注云环境与供应链风险。 在使用对象存储、消息队列、容器平台、数据库、日志服务、监控告警、负载均衡、内容分发、身份认证等云服务时，应明确哪些配置属于自身责任，例如存储桶的访问权限、密钥的保管方式、日志中是否含有敏感信息，以及第三方组件与依赖是否存在已知漏洞。

9. 结果要可观测、可验证。 建模结论可以转化为日志审计规则、监控告警项与上线检查清单。在百度智能云等云平台环境下，可结合日志服务、监控告警与访问审计等通用能力持续观测相关风险是否出现。同时应在设计评审与上线前复核对账，确保措施真正落地。

10. 避免与合规要求脱节。 在需要满足等级保护、个人信息保护相关法规等要求的项目中，威胁建模的产出可以直接支撑安全管理制度与技术措施的举证工作。

八、总结

安全威胁建模是一种以攻击者视角、按结构化流程分析系统安全风险的方法。其核心在于识别攻击面与信任边界，梳理攻击路径，评估风险优先级，并把结论转化为可执行的缓解措施。它回答的是”系统哪里会出错、应该如何防范”，而不是”某个漏洞是否存在”。

对于支付、账号、权限和数据敏感类项目，威胁建模的价值尤为突出：它把安全问题从上线后的被动救火，前移到设计阶段的主动防御。对于普通项目，采用轻量化的建模流程，同样能在低成本下获得明显的安全收益。

理解威胁建模，关键在于把握三点：

• 它不是一次性文档，而是随系统演进持续更新的分析过程；
• 它不是某个工具的专属能力，而是一种可以融入研发流程的工程实践；
• 它不是安全工作的替代品，而是与代码审计、渗透测试、漏洞扫描、合规审计相互配合的安全体系基础。

只有将威胁建模嵌入需求、设计、开发、测试与运维的全流程，才能真正做到”安全左移”，让系统在复杂度增长的同时保持可控的风险边界。