📚 课程目录第2章威胁建模

威胁建模：STRIDE模型、数据流图（DFD）绘制、威胁识别与风险评估

威胁建模这件事，说白了就是在攻击者动手之前，先替他们想好怎么搞破坏。我做了这么多年安全，见过太多上线后才补漏洞的项目——那代价，啧啧，翻倍都是轻的。

这一章我们聚焦三个核心：STRIDE模型、数据流图（DFD）、以及威胁识别与风险评估。这三样东西串起来，就是一套完整的威胁建模流程。

你想想看，一个系统从设计到上线，中间有多少环节可能出问题？接口、存储、传输、认证……每个点都可能被利用。威胁建模就是把这些点提前找出来，在代码还没写之前就把坑填上。

我记得有一次，团队赶工期，跳过了威胁建模直接开干。结果上线第一天，用户A竟然能查到用户B的订单数据。原因？权限校验漏了一个接口。如果当时画了DFD，这个接口肯定会被标出来。

STRIDE是微软提出的威胁分类法，六个字母对应六类威胁。我习惯把它贴在显示器边上，每次做威胁建模都过一遍。

字母	威胁类型	核心问题	典型场景
S	Spoofing（假冒）	谁能假装成别人？	伪造JWT Token、盗用Session
T	Tampering（篡改）	数据能被非法修改吗？	中间人改请求参数、篡改配置文件
R	Repudiation（抵赖）	做了坏事能赖账吗？	缺少操作日志、日志可被删除
I	Information Disclosure（信息泄露）	敏感数据能被看到吗？	明文密码、API返回多余字段
D	Denial of Service（拒绝服务）	系统能被搞瘫痪吗？	无频率限制、死循环调用
E	Elevation of Privilege（权限提升）	普通用户能当管理员吗？	越权访问、SQL注入提权

我的习惯：每次评审设计文档，我都拿STRIDE当checklist逐条过。别嫌麻烦，漏掉一个可能就是一次安全事件。

DFD不是安全专属的工具，但用在威胁建模上特别好使。它把系统拆成几个基本元素：外部实体、过程、数据存储、数据流。画出来之后，威胁就藏不住了。

我见过有人直接对着代码做威胁建模，结果漏了一堆外部依赖。DFD强迫你把所有边界都画出来——第三方API、数据库、缓存、消息队列……一个都不能少。

注意：DFD只画数据流，不画控制流。我曾经看到有人把if-else都画进去，那就不叫DFD了，叫流程图。DFD关注的是“数据去了哪里”，不是“程序怎么执行”。

下面是一个用户登录场景的DFD。我故意简化了，但核心结构都在。

    关键点：注意那条虚线——信任边界。用户在外面，登录服务和数据库在里面。跨过这条边界的每个数据流，都是潜在的威胁面。

DFD画好了，STRIDE模型也记住了，接下来就是把两者结合起来。我习惯对DFD里的每个元素，逐个问STRIDE的六个问题。

举个例子，上面那个登录场景：

避坑指南：我曾经在一个支付系统里，只关注了“用户->支付服务”这条流，忽略了“支付服务->银行网关”这条外部流。结果银行网关的证书校验没做，差点出事。记住：每一条跨信任边界的数据流，都要过一遍STRIDE。

识别出威胁之后，下一步是评估风险。不是每个威胁都值得花大价钱去修。我常用的方法是DREAD模型，给每个威胁打分。

总分 = (D + R + E + A + D) / 5。我一般这样定优先级：

别掉进完美主义陷阱：我见过一个团队，花了两周去修一个评分只有2分的威胁——某个内部管理接口需要内网+特定IP才能访问，他们非要加双因子认证。有这个时间，不如去修那个评分9分的SQL注入。记住：安全是风险管理，不是消除所有风险。

最后，我把整个流程串起来。你照着这个步骤走，基本不会漏。

嗯，这套流程我用了快十年，从Web应用到嵌入式系统，基本都能覆盖。你刚开始做的时候可能会觉得慢，但熟练之后，一个中等规模系统的威胁建模，半天就能搞定。