3、威胁建模与风险评估：STRIDE模型、DREAD模型、风险矩阵、威胁建模工具与实践
说到安全，很多人第一反应是「装个防火墙」、「上个WAF」。但说实话，这些都是在问题发生后才去堵漏。真正靠谱的做法，是在系统设计阶段就把安全考虑进去。这就是威胁建模要做的事。
我个人习惯把威胁建模比作「给房子做安全检查」。你不可能等房子盖好了，才发现地基有裂缝。同样，你也不该等系统上线了，才发现认证机制有漏洞。今天我们就聊聊怎么系统性地做这件事。
3.1 STRIDE模型：六类威胁，一个框架
STRIDE是微软提出来的威胁分类模型。我最早接触它是在2015年，当时给一个金融系统做安全评审。说实话，一开始觉得这玩意儿太理论了，后来用顺手了才发现——真香。
STRIDE是六个单词的首字母缩写：
| 威胁类型 | 英文 | 中文解释 | 举个栗子 |
|---|---|---|---|
| S | Spoofing | 身份欺骗 | 攻击者伪造管理员身份登录 |
| T | Tampering | 数据篡改 | 修改数据库中的订单金额 |
| R | Repudiation | 否认抵赖 | 用户说「我没下过这个单」 |
| I | Information Disclosure | 信息泄露 | 日志里打印了用户密码 |
| D | Denial of Service | 拒绝服务 | 刷接口把服务器打挂了 |
| E | Elevation of Privilege | 权限提升 | 普通用户拿到了管理员权限 |
你可能会问：「这六个分类够用吗？」我的经验是，90%的安全问题都能归到这六类里。剩下的10%，要么是组合攻击，要么是业务逻辑漏洞。
3.2 DREAD模型：给威胁打个分
STRIDE帮我们找到了威胁，但问题来了——这么多威胁，先修哪个？这时候就需要DREAD模型出场了。
DREAD也是一个缩写，用来给每个威胁打分：
- D - Damage Potential（潜在损害）：如果这个漏洞被利用，损失有多大？
- R - Reproducibility（可复现性）：攻击者能稳定复现吗？
- E - Exploitability（可利用性）：攻击难度高不高？
- A - Affected Users（受影响用户）：会影响到多少人？
- D - Discoverability（可发现性）：攻击者容易发现这个漏洞吗？
每个维度打1-10分，最后算总分。分数越高，优先级越高。
举个例子，我之前评估过一个API接口的未授权访问问题：
| 维度 | 评分 | 理由 |
|---|---|---|
| Damage | 9 | 能查到所有用户数据 |
| Reproducibility | 10 | 每次请求都能复现 |
| Exploitability | 8 | 只需要一个curl命令 |
| Affected Users | 10 | 所有注册用户 |
| Discoverability | 7 | 稍微扫一下就能发现 |
| 总分 | 44 | 必须立即修复 |
3.3 风险矩阵：可视化你的风险
打分之后，怎么直观地展示风险？风险矩阵是个好工具。
说白了，风险矩阵就是一个二维表格：横轴是「可能性」，纵轴是「影响程度」。把每个威胁放到对应的格子里，一目了然。
| 影响 \ 可能性 | 低 | 中 | 高 |
|---|---|---|---|
| 高 | 中风险 | 高风险 | 高风险 |
| 中 | 低风险 | 中风险 | 高风险 |
| 低 | 低风险 | 低风险 | 中风险 |
我一般这样用：
- 高风险（红色）：必须立即修复，不能上线
- 中风险（黄色）：列入迭代计划，尽快修复
- 低风险（绿色）：记录在案，有空再修
你想想看，如果没有这个矩阵，你拿什么跟老板说「这个必须修」？有了矩阵，你就能指着红色区域说：「老板，这里不修，出事概率很大。」
3.4 威胁建模工具与实践
理论说完了，来点实际的。我这些年用过不少工具，挑几个好用的说说。
3.4.1 微软 Threat Modeling Tool
这是微软官方出的免费工具。优点是：
- 自带STRIDE模板
- 支持拖拽式画数据流图
- 自动生成威胁报告
缺点嘛，就是只能在Windows上跑。我用Mac，每次都得开虚拟机，有点烦。
3.4.2 OWASP Threat Dragon
这个我比较推荐。开源、跨平台、支持Web版。画图、建模、导出报告一条龙。
安装很简单：
# 用Docker跑
docker pull owasp/threat-dragon
docker run -d -p 3000:3000 owasp/threat-dragon3.4.3 实践流程
不管用什么工具，流程都差不多。我总结了一个四步法：
- 画图：画出系统的数据流图，标出所有组件、数据存储、信任边界
- 识别：用STRIDE模型，逐个组件分析威胁
- 评估：用DREAD打分，放到风险矩阵里
- 缓解：针对高风险项，制定缓解措施
3.5 一个完整的例子
最后，我们拿一个简单的「用户登录」功能来练练手。
场景： 用户输入用户名密码，后端验证后返回Token。
数据流图简化版：
用户浏览器 → [HTTPS] → 登录API → [查询] → 数据库
↓
返回Token威胁分析（STRIDE）：
- Spoofing：攻击者伪造合法用户身份 → 缓解：加验证码、多因素认证
- Tampering：中间人篡改请求数据 → 缓解：强制HTTPS
- Information Disclosure：密码明文存储 → 缓解：bcrypt哈希存储
- Denial of Service：暴力破解 → 缓解：限流、锁定策略
风险评估（DREAD）：
拿「密码明文存储」来说：
- Damage: 10（所有用户密码泄露）
- Reproducibility: 10（每次都能查到）
- Exploitability: 5（需要数据库权限）
- Affected Users: 10（所有用户）
- Discoverability: 8（数据库泄露后很容易发现）
- 总分：43 → 高风险
你看，这么一分析，优先级就出来了。先修密码存储，再搞限流，最后加验证码。有条不紊。
好了，威胁建模这块就聊到这儿。记住一句话：安全不是加功能，而是设计出来的。下次做系统设计时，别忘了拿出STRIDE过一遍。相信我，你会感谢自己的。