威胁建模入门：STRIDE模型详解、攻击树分析、数据流图绘制与工具实践
威胁建模这件事，说白了就是在攻击者动手之前，先替他们想好怎么搞破坏。我早年做第一个互联网项目时，根本没这个概念——代码写完直接上线，结果被拖库了才追悔莫及。后来我养成了一个习惯：任何系统设计，第一版文档必须是威胁模型。
这一章，我们就把威胁建模的四块基石讲透：STRIDE模型、攻击树分析、数据流图（DFD），以及工具落地。你跟着走一遍，就能自己动手给系统做“安检”了。
1. STRIDE模型：微软的六维威胁分类法
STRIDE 是微软提出的威胁分类框架，每个字母代表一类威胁。我习惯把它当作“威胁检查清单”——对着系统逐项过，基本不会漏东西。
| 字母 | 威胁类型 | 通俗理解 | 典型例子 |
|---|---|---|---|
| S | Spoofing（假冒） | 冒充别人身份 | 伪造 JWT Token、盗用 Session |
| T | Tampering（篡改） | 数据被改 | 中间人改请求参数、篡改配置文件 |
| R | Repudiation（抵赖） | 做了不承认 | 用户说“我没下单”，但日志没记录 |
| I | Information Disclosure（信息泄露） | 不该看的被看到 | API 返回了密码哈希、日志打印了身份证号 |
| D | Denial of Service（拒绝服务） | 系统瘫了 | CC 攻击打满连接池、慢查询拖垮数据库 |
| E | Elevation of Privilege（权限提升） | 普通用户干管理员的事 | 水平越权访问他人订单、垂直越权调用后台接口 |
我的小技巧：每次评审架构时，我就在白板上画六个格子，分别写上 STRIDE。然后对着每个数据流问：“这个环节能不能假冒？能不能篡改？” 一轮下来，至少能发现 3-5 个隐患。
2. 攻击树分析：把攻击路径画成树
攻击树是布鲁斯·施奈尔提出的方法。它的核心思想很简单：攻击者的目标就是根节点，达成目标的各种路径就是子节点。
举个例子，假设攻击者的目标是“获取用户数据库中的密码”：
根节点：获取用户密码
├── OR 子节点1：SQL注入
│ ├── 发现注入点
│ └── 构造Payload
├── OR 子节点2：暴力破解后台
│ ├── 获取管理员账号
│ └── 绕过登录验证
└── OR 子节点3：从备份文件泄露
├── 找到备份服务器
└── 下载未加密的备份我曾在一次红蓝对抗中用过攻击树。蓝队防守方把系统加固得铁桶一般，但我们通过攻击树发现了一条“备份服务器未隔离”的路径——直接拿下。你看，树画得越细，盲区就越少。
关键点：攻击树中的“AND”和“OR”节点要分清。OR 表示任意一条路径都能达成目标；AND 表示所有子条件必须同时满足。画错了，分析结果就偏了。
3. 数据流图（DFD）：系统的“X光片”
DFD 是威胁建模的起点。没有 DFD，你连系统长什么样都说不清，更别提找威胁了。我见过不少团队直接跳过 DFD 开始“脑补”威胁，结果漏洞分析全是拍脑袋。
DFD 有四个基本元素：
- 外部实体（矩形）：用户、第三方系统
- 过程（圆形/圆角矩形）：业务逻辑、API 处理
- 数据存储（两条横线）：数据库、缓存、文件
- 数据流（箭头）：请求、响应、消息
下面是一个典型的 Web 登录系统 DFD：
我曾经踩过的坑：画 DFD 时漏掉了“第三方回调接口”这个外部实体。结果上线后，攻击者通过伪造回调通知直接修改了订单状态。所以，画 DFD 一定要把所有的外部交互点都列出来，一个都不能少。
4. 威胁建模工具实践
理论讲完了，咱们看看怎么落地。我推荐三款工具，按场景选：
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Microsoft Threat Modeling Tool | Windows 环境、传统架构 | 内置 STRIDE 模板、自动生成威胁列表 | 只支持 Windows、模板更新慢 |
| OWASP Threat Dragon | Web 应用、开源项目 | 跨平台、支持在线协作、集成 GitHub | 功能相对基础、大型模型卡顿 |
| IriusRisk | 企业级、复杂系统 | 自动化风险计算、与 CI/CD 集成 | 商业版收费、学习曲线陡 |
我个人习惯用 OWASP Threat Dragon。原因很简单：免费、跨平台、画 DFD 顺手。你可以在里面直接拖拽元素，然后给每个数据流打上 STRIDE 标签，系统会自动生成威胁清单。
上手步骤：
- 打开 Threat Dragon，新建一个模型
- 先画 DFD：外部实体 → 过程 → 数据存储 → 数据流
- 标记信任边界（用虚线框）
- 对每个数据流应用 STRIDE 分析
- 记录发现的威胁，分配风险等级和责任人
5. 实战案例：一个简单的支付系统威胁建模
咱们拿一个“用户下单支付”的场景走一遍完整流程。系统很简单：用户 → 支付服务 → 支付网关 → 数据库。
第一步：画 DFD
- 外部实体：用户、支付网关（第三方）
- 过程：支付服务
- 数据存储：订单数据库
- 数据流：下单请求、支付请求、回调通知、查询订单
第二步：STRIDE 分析
| 数据流 | S | T | R | I | D | E | 风险描述 |
|---|---|---|---|---|---|---|---|
| 用户 → 支付服务 | ✓ | ✓ | ✓ | ✓ | 伪造用户身份、篡改订单金额 | ||
| 支付服务 → 支付网关 | ✓ | ✓ | ✓ | ✓ | API 密钥泄露、请求被篡改 | ||
| 支付网关 → 支付服务（回调） | ✓ | ✓ | ✓ | 伪造回调通知、提升权限 | |||
| 支付服务 → 数据库 | ✓ | ✓ | ✓ | SQL 注入、数据泄露 |
第三步：制定缓解措施
- 用户 → 支付服务：强制 HTTPS、签名校验、限流
- 支付服务 → 支付网关：使用 HMAC 签名、API 密钥定期轮换
- 支付网关回调：验证回调 IP、校验签名、使用幂等键防止重复
- 支付服务 → 数据库：参数化查询、最小权限账户、加密存储
核心原则：威胁建模不是一次性的工作。每次架构变更、每次引入新依赖、每次版本迭代，都要重新过一遍。我团队的规定是：任何涉及数据流变更的需求，必须附带更新后的威胁模型才能进入开发。