2、威胁建模入门：威胁建模的目的、STRIDE模型详解、数据流图绘制方法
2.1 我们为什么要做威胁建模？
说实话，我见过太多团队一上来就写代码，等系统上线了才发现安全漏洞。那时候再修，成本高得吓人。
威胁建模，说白了就是在设计阶段，提前把可能出问题的地方找出来。我个人习惯把它叫做「安全领域的预演」——你想想看，盖楼之前都要做结构计算，做安全设计也是一样的道理。
它的核心目的就三个：
- 提前发现威胁——别等被人攻击了才后悔
- 指导安全决策——哪些风险要优先处理，哪些可以接受
- 降低修复成本——设计阶段改一行文档，比上线后改一百行代码划算得多
我在项目中遇到过一件事：一个支付系统上线前，我们做了威胁建模，发现了一个「中间人攻击」的路径。当时改起来只花了半天。如果上线后被利用，那后果...嗯，你懂的。
核心观点：威胁建模不是「做不做」的问题，而是「什么时候做」的问题。越早做，收益越大。
2.2 STRIDE模型详解
STRIDE 是微软提出的一套威胁分类方法。我刚开始学的时候觉得它有点抽象，后来用多了才发现——它其实把你能想到的攻击方式都覆盖了。
STRIDE 是六个单词的首字母缩写：
| 字母 | 含义 | 通俗解释 | 举个例子 |
|---|---|---|---|
| S | Spoofing（假冒） | 冒充别人身份 | 伪造用户登录、伪造服务器证书 |
| T | Tampering（篡改） | 数据被改了 | 中间人修改请求参数、数据库被注入 |
| R | Repudiation（抵赖） | 做了事不认账 | 用户说「我没下过这个订单」 |
| I | Information Disclosure（信息泄露） | 不该看的被看到了 | 密码明文存储、日志泄露敏感信息 |
| D | Denial of Service（拒绝服务） | 系统瘫了 | DDoS攻击、资源耗尽 |
| E | Elevation of Privilege（权限提升） | 普通用户干管理员的事 | 越权访问、SQL注入提权 |
这里有个小技巧：每次做威胁建模时，你就拿这六个维度挨个过一遍。我自己的习惯是拿张纸，画个表格，每个维度下面写「可能出问题的地方」。这样做完，基本不会漏掉什么。
我的经验：STRIDE 最容易被忽略的是「R（抵赖）」和「E（权限提升）」。很多团队只关注防攻击，忘了审计和权限控制。我曾经在一个项目中，就是因为没考虑「抵赖」场景，结果用户投诉时拿不出任何证据——那叫一个被动。
2.3 数据流图绘制方法
数据流图（DFD）是威胁建模的「地图」。没有它，你根本不知道数据从哪来、到哪去、经过谁的手。
画 DFD 其实不复杂，记住四个基本元素就行：
- 外部实体（矩形）——用户、第三方系统等
- 处理过程（圆形或圆角矩形）——你的服务、模块
- 数据存储（两条横线）——数据库、缓存、文件
- 数据流（箭头）——数据流动的方向
举个例子，一个简单的登录系统：
用户（外部实体） → 输入账号密码 → 登录服务（处理过程） → 查询 → 用户数据库（数据存储）
↓
返回结果 → 用户收到登录成功/失败画的时候要注意几点：
- 先画大图——别一上来就扣细节，先搞清楚整体流程
- 标注信任边界——用虚线框出「可信区域」和「不可信区域」
- 别漏了数据存储——很多人只画流程，忘了数据库和缓存
避坑指南：我曾经犯过一个错误——画 DFD 时只画了正常流程，没画异常路径。结果威胁建模时漏掉了一个「密码重置」场景下的攻击面。后来被安全团队打回来重做，白白浪费了两天时间。所以记住：正常流程和异常流程都要画。
2.4 把 STRIDE 和 DFD 结合起来
有了 DFD，你就可以对着每个元素问 STRIDE 问题了。我一般会这样操作：
- 拿到 DFD，标出所有「外部实体」和「数据流」
- 对每个数据流，问「这个数据会不会被篡改？」（Tampering）
- 对每个外部实体，问「这个身份能不能被伪造？」（Spoofing）
- 对每个数据存储，问「数据会不会泄露？」（Information Disclosure）
- 对每个处理过程，问「能不能让这个服务挂掉？」（Denial of Service）
- 最后检查有没有「权限提升」和「抵赖」的风险
这样做一遍，基本上能覆盖 90% 以上的常见威胁。剩下的 10% 嘛...嗯，那就得靠经验了。
总结一下：威胁建模不是一次性的工作。系统每次迭代，DFD 都要更新，STRIDE 也要重新过一遍。我见过最好的团队，把威胁建模做成了「每次设计评审的必选项」——这才是真正把安全落到了实处。
好了，这一章的内容就到这里。下一章我们会聊聊「如何给威胁定优先级」，到时候我会分享一个我踩过的坑——那个坑让我明白，不是所有威胁都需要立刻修复的。