简介：安全威胁建模是一种在系统设计、开发和上线过程中识别安全风险的方法。它通过梳理资产、数据流、攻击面、信任边界和潜在攻击者，分析系统可能遭受的威胁，并将风险转化为可执行的防护措施。本文将系统介绍安全威胁建模的定义、核心组成、工作流程、适用场景、常见误区及落地注意事项，帮助开发者和企业建立更完整的安全分析思路。
安全威胁建模，是指在软件系统或业务方案设计阶段，主动识别可能影响系统机密性、完整性和可用性的安全威胁，并根据风险等级制定防护、监控和应急措施的一套系统化方法。
简单来说，它要回答几个关键问题：
传统安全工作往往是在系统上线后，通过漏洞扫描、日志分析或安全测试发现问题。安全威胁建模则更强调“提前思考”。它不是单纯寻找代码错误，也不是某一种扫描工具，而是一种贯穿需求、设计、开发、测试、部署和运维阶段的风险分析方式。
从技术视角看，安全威胁建模关注系统结构和攻击路径；从业务视角看，它关注数据泄露、资金损失、权限滥用、服务中断等后果；从开发视角看，它帮助团队在写代码之前明确安全约束，减少后期返工。
随着系统架构不断复杂化，一个业务系统通常包含前端应用、后端服务、数据库、缓存、消息处理模块、文件存储、身份认证模块、管理后台以及多个外部依赖。组件越多，数据流转路径越长，潜在攻击面也越广。
如果只检查单个功能是否能够正常运行，很容易忽略系统层面的风险。例如：
这些问题通常不是单一函数能够解释的，而是由资产、身份、数据流、权限和部署环境共同形成。威胁建模的价值就在于把系统作为整体观察，提前发现组件之间的连接关系和隐含风险。
它主要带来以下收益：
在需求和架构阶段识别风险，通常比上线后修复问题成本更低。设计阶段可以直接调整接口边界、权限模型、数据存储方式和网络分区，避免后续大规模改造。
安全风险并非都需要立即处理。威胁建模能够结合资产价值、攻击可能性和影响范围，对风险进行分级，使团队优先解决高影响、高暴露、高可利用的问题。
威胁建模提供了一种共同语言。开发者可以从数据流和调用关系描述系统，安全人员可以从攻击路径和防护措施进行分析，产品和管理人员则可以从业务影响理解风险。
仅依赖经验检查，容易忽略非主流程、异常流程和跨服务调用。通过资产清单、数据流图、信任边界和攻击场景逐项分析，可以提高风险识别的完整性。
资产是系统中需要保护的对象，不仅包括数据库中的数据，也包括账号、密钥、令牌、业务状态、配置文件、日志、接口能力和计算资源等。
常见资产包括：
识别资产时不能只看“数据存在哪里”，还要考虑数据在传输、处理、缓存、导出和备份过程中是否仍然需要保护。
攻击面是攻击者可能与系统交互并尝试利用的入口集合。它既包括直接暴露在外部的接口，也包括权限配置、第三方依赖、运维入口和内部服务之间的调用关系。
典型攻击面包括：
攻击面不是固定不变的。系统新增接口、开放网络端口、接入新服务、增加管理功能，都会扩大攻击面。因此，威胁建模应当在重大架构变更后重新进行。
信任边界是指系统中安全假设发生变化的位置。跨越信任边界时，数据和请求通常需要重新认证、授权、校验或审计。
常见信任边界包括：
需要特别注意的是，“处于内网”不等于“天然可信”，“来自已登录用户”也不等于“可以访问所有资源”。现代系统往往包含多个服务和多个权限域，每个边界都应当明确验证身份、判断权限并限制数据范围。
数据流描述信息在系统中的产生、传输、处理、存储和销毁过程。分析数据流时，需要关注数据经过了哪些组件、由谁触发、以什么格式传递，以及是否发生信任级别变化。
例如，一个账户操作可能经过以下路径：
用户端-> 身份认证服务-> 业务接口-> 权限校验模块-> 交易处理模块-> 数据存储-> 日志与通知模块
每一个箭头都可能对应新的风险：传输过程中是否被篡改，服务之间是否验证调用身份，日志是否记录了敏感信息，异常处理是否泄露内部细节，重试机制是否造成重复操作等。
首先确定本次分析覆盖哪些内容，包括业务功能、服务组件、数据存储、外部依赖、用户角色和部署环境。范围过小，容易遗漏跨系统风险；范围过大，则可能导致分析失去重点。
可以先列出：
根据业务影响对资产进行分类，区分高敏感数据、核心业务状态、身份凭证和普通运行数据。对于每类资产，需要明确其机密性、完整性和可用性要求。
例如，身份凭证泄露主要影响机密性和账号安全；交易状态被篡改主要影响完整性；核心服务不可用则主要影响可用性。不同属性对应的防护策略并不相同。
将用户、服务、存储、外部系统和数据流表示出来，并标记不同信任区域。图示不必复杂，但必须能够说明：
威胁分析可以从多个维度展开：
风险不能只依据“是否存在攻击可能”判断，还需要综合考虑：
可以使用定性方式将风险分为高、中、低，也可以根据组织实际情况建立评分模型。关键不在于评分公式多复杂，而在于评分标准保持一致，能够支持研发排期和整改决策。
针对不同威胁，应选择与风险相匹配的控制措施，例如：
安全威胁建模尤其适合以下项目：
这类系统涉及账户、资金、订单和交易状态，既需要防止身份冒用，也要防止请求篡改、重复提交、流程绕过和权限滥用。
注册、登录、密码找回、会话管理、设备绑定和权限变更都属于高风险流程。威胁建模可以帮助识别凭证泄露、验证码滥用、会话固定和权限升级等问题。
当系统存在普通用户、审核人员、运营人员和管理员等多个角色时，仅靠页面隐藏按钮并不能实现安全控制。需要从接口、资源、数据范围和操作动作多个层面分析权限边界。
医疗、金融、企业内部资料及个人信息等数据，在采集、传输、处理、存储、导出和删除环节都可能产生风险。威胁建模能够帮助确定数据最小化、访问审计和生命周期管理要求。
服务数量增加后，内部调用、消息传递和配置共享会带来新的信任关系。威胁建模可以识别服务间过度信任、内部接口暴露和环境隔离不足等问题。
新增核心模块、开放新接口、迁移数据、改变认证方式或调整网络拓扑时，都建议重新开展威胁分析，避免旧有安全假设继续适用于新架构。
漏洞扫描主要发现已知技术弱点，例如配置错误、依赖缺陷或常见代码问题。威胁建模则从系统设计和攻击路径出发，分析“攻击者为什么能够接近资产、如何跨越边界以及成功后会造成什么影响”。
两者互相补充，不能相互替代。
渗透测试更接近真实攻击，通过模拟攻击验证系统是否存在可利用问题。威胁建模通常发生得更早，用于指导测试重点和防护设计。没有威胁建模，测试可能只覆盖常见入口，遗漏关键业务流程。
风险评估通常关注风险等级、业务影响和处置优先级；威胁建模更强调系统结构、攻击者路径、信任边界和具体威胁来源。实际工作中，两者通常结合使用。
首先，威胁建模不能只由安全人员单独完成。开发者了解代码和架构，产品人员了解业务规则，运维人员了解部署环境，数据负责人了解资产敏感性，多方参与才能形成完整结论。
其次，不要把威胁建模做成一次性文档。系统功能、接口和部署方式都会变化，安全模型也应随版本迭代更新。建议在需求评审、架构评审、重大变更和上线前分别检查关键风险。
再次，不能只关注外部攻击。内部误操作、过度授权、凭证泄露、配置错误和日志暴露同样可能造成严重后果。
最后，风险结论必须能够落地。每一项高风险问题都应明确责任人、整改措施、验证方式和完成时间。如果只记录“加强安全”“做好权限控制”等笼统建议，就很难形成有效闭环。
安全威胁建模是一种围绕资产、攻击面、信任边界、数据流和攻击路径开展的系统化安全分析方法。它的核心不是预测所有可能的攻击，而是用结构化方式识别最值得关注的风险，并在设计和开发阶段采取可验证的控制措施。
对于支付、账号、权限、敏感数据和复杂服务架构，威胁建模能够帮助团队从“功能是否可用”进一步走向“功能是否在正确的权限、边界和安全约束下运行”。它既不是单独的安全工具，也不是上线前的一次检查，而应当成为系统工程和研发流程中的持续实践。