威胁建模基础：概念、STRIDE模型与流程
威胁建模，说白了就是在攻击者动手之前，先替他们想好怎么搞破坏。我经常跟团队讲一句话：“如果你不知道敌人会从哪里来，你就没法真正守住门。” 这不是什么高深理论，而是安全工作的基本功。
这一章，我们就把威胁建模的底子打扎实。我会从概念讲起，然后深入STRIDE模型——这是微软提出的一套经典框架，最后带你走一遍完整的威胁建模流程。嗯，这里面的坑，我踩过不少，都会一一告诉你。
1. 威胁建模到底是什么？
先别急着背定义。我换个说法：威胁建模 = 系统化的“找茬”过程。
你设计一个系统，画好架构图，写清楚数据流。然后你坐下来，问自己几个问题：
- 谁会攻击我？
- 他们想拿到什么？
- 他们能从哪里下手？
- 如果得手了，后果有多严重？
把这些问题的答案整理成文档，就是威胁模型。它不是一个静态的表格，而是一份活的、持续更新的安全地图。
核心要点：威胁建模不是一次性的安全评审，而是贯穿整个软件开发生命周期的持续活动。从需求阶段开始，到设计、开发、测试、部署，每个阶段都应该有对应的威胁建模输出。
我记得有一次，团队做了一个内部管理系统，功能很简单，就是员工请假审批。大家觉得没什么安全风险，就没做威胁建模。结果上线后，有人通过修改HTTP请求参数，直接把自己从“普通员工”改成了“CEO审批人”。嗯，那场面……后来我们花了三天时间紧急修复，还补了安全审计。从那以后，我再也不敢跳过威胁建模了。
2. STRIDE模型详解
STRIDE是微软提出的一种威胁分类方法。它把安全威胁分成六类，每个字母代表一类：
| 字母 | 威胁类型 | 通俗解释 | 违反的安全属性 |
|---|---|---|---|
| S | Spoofing（假冒） | 冒充别人身份，比如伪造登录 | 认证 |
| T | Tampering（篡改） | 修改数据或代码，比如改数据库记录 | 完整性 |
| R | Repudiation（抵赖） | 做了坏事不承认，比如删日志 | 不可否认性 |
| I | Information Disclosure（信息泄露） | 不该看的数据被看到了 | 机密性 |
| D | Denial of Service（拒绝服务） | 让系统不可用，比如DDoS | 可用性 |
| E | Elevation of Privilege（权限提升） | 普通用户拿到管理员权限 | 授权 |
你可能会问：“这六类够用吗？” 说实话，大部分场景下是够的。STRIDE的厉害之处在于，它把安全属性（认证、完整性、机密性等）和具体的威胁类型对应起来了。你分析一个功能时，只要对着这六类逐一排查，基本不会漏掉大的风险点。
我的习惯：每次做威胁建模，我都会在墙上贴一张STRIDE分类表。每分析一个数据流，就对着表问一遍：“这个流会不会被假冒？会不会被篡改？会不会导致信息泄露？” 这样不容易遗漏。
3. 威胁建模的标准流程
流程不复杂，但每一步都有讲究。我把它总结成五个步骤：
- 界定范围 —— 明确你要分析的系统边界、功能模块、数据资产。
- 分解系统 —— 画出架构图、数据流图（DFD），标出信任边界。
- 识别威胁 —— 用STRIDE或其他模型，对每个数据流和节点进行威胁分析。
- 评估风险 —— 对识别出的威胁进行优先级排序，决定哪些要修、哪些可以接受。
- 制定缓解措施 —— 针对高风险威胁，设计具体的防护方案。
下面这张图，就是整个流程的概览。我建议你把它打印出来，贴在工位上。
4. 每个步骤的实战要点
4.1 界定范围
这一步最容易犯的错是范围太大或太小。太大，分析不完；太小，漏掉关键风险。我建议你从用户故事或功能模块入手，一次只分析一个功能点。比如“用户注册登录”作为一个单元，“订单支付”作为另一个单元。
我曾经踩过的坑：有一次，我试图在一个威胁建模会议里把整个电商平台都分析完。结果开了三个小时的会，只讨论了首页展示功能。后来我学乖了，每次只分析一个核心功能流，控制在1-2小时内完成。
4.2 分解系统
画数据流图（DFD）是核心。你需要标出：
- 外部实体（用户、第三方系统）
- 进程（服务、模块）
- 数据存储（数据库、缓存）
- 数据流（请求、响应）
- 信任边界（比如内网和外网的分界线）
信任边界特别重要。我见过很多团队画DFD时，把整个系统画成一个黑盒子，然后说“内部都是安全的”。这其实很危险。攻击者一旦突破边界，内部就完全暴露了。
4.3 识别威胁
对着DFD，用STRIDE逐项分析每个元素。我习惯用表格来记录：
| 数据流/节点 | STRIDE威胁 | 具体描述 | 影响 |
|---|---|---|---|
| 用户登录请求 | Spoofing | 攻击者伪造登录请求，冒充合法用户 | 高 |
| 数据库写入 | Tampering | 攻击者通过SQL注入篡改订单数据 | 高 |
| 日志记录 | Repudiation | 攻击者删除操作日志，无法追溯 | 中 |
| API响应 | Information Disclosure | API返回了用户手机号等敏感信息 | 高 |
| 文件上传 | Denial of Service | 攻击者上传超大文件耗尽磁盘空间 | 中 |
| 权限校验 | Elevation of Privilege | 普通用户通过修改请求参数提升权限 | 高 |
4.4 评估风险
不是所有威胁都要修。你需要根据可能性和影响程度来排序。我常用的方法是：
- 高可能性 + 高影响 → 必须立即修复
- 高可能性 + 低影响 → 尽快修复
- 低可能性 + 高影响 → 制定应急方案
- 低可能性 + 低影响 → 记录在案，暂不处理
我的经验：不要试图一次性解决所有威胁。优先处理那些“一旦发生就会让业务停摆”的风险。比如，用户数据泄露、支付系统被篡改，这些是红线，必须优先处理。
4.5 制定缓解措施
缓解措施要具体、可落地。比如：
- 针对Spoofing：强制使用OAuth 2.0 + MFA
- 针对Tampering：所有写操作加数字签名
- 针对Information Disclosure：API响应脱敏，日志不记录明文密码
- 针对Denial of Service：限流、熔断、资源配额
- 针对Elevation of Privilege：最小权限原则，服务间调用使用JWT
嗯，到这里，威胁建模的基础就讲完了。你可能会觉得内容有点多，但别急，后面几章我们会用真实案例来演练，到时候你会发现自己已经能熟练运用这些知识了。