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

2. 威胁建模基础

说到威胁建模，很多刚入行的朋友会觉得这东西有点虚。

说白了，它就是在系统设计阶段，我们主动去思考“谁会打我？从哪里打？怎么打？”的一系列结构化方法。我个人习惯把它当作一次“安全体检”，在系统还没盖起来之前，就先把可能漏水、漏电的地方标记出来。

大家可以把威胁建模理解成一种防患于未然的系统化思考过程。

它不是在攻击发生后的被动响应，而是一种主动的防御性设计。它的核心目标就是：在系统正式上线前，尽可能多地识别出潜在的安全风险，然后评估这些风险的严重程度，并最终决定用什么方式去处理它们。

我的个人理解： 威胁建模有点像给系统做一次“尽职调查”。你要搞明白，你的系统里哪些资产最值钱（比如用户数据、），哪些地方最容易出问题（比如输入框、文件上传点），那些坏蛋可能会用什么套路（比如SQL注入、越权访问）。想清楚了这些，你才知道该把钱和精力花在什么地方。

识别威胁来源，是建模的第一步。我在不同项目里摸爬滚打多年，发现常见的威胁来源，大致可以分为这么几类。

为什么要把威胁来源分这么清楚？因为不同的来源，你的对抗策略完全不同。对抗外部攻击者，你可能要升级WAF规则、做渗透测试。而应对内部威胁，可能更需要在权限控制、日志审计和员工安全意识培训上下功夫。你想想看，这能一样么？

这里我分享一个我个人实践下来比较顺手的五步模型。它不是什么教科书式的死流程，而是一个能帮你把思路理清的框架。

定义范围与目标： 先搞清楚你要分析什么。是整个系统？还是某一个微服务？是一次完整的功能迭代，还是一次安全性改造？边界不清，后面全是糊涂账。我刚开始做的时候，就吃过这个亏，上来就分析，结果分析到一半发现范围失控了。
分解系统： 把目标系统拆开来看。画数据流图（DFD）、列出组件清单、梳理用户角色和权限。这一步要像庖丁解牛一样，看清每一个组件、每一条数据流。
识别威胁： 针对分解出来的每个组件和数据流，利用威胁模型（比如STRIDE）去穷举可能的威胁。这一步，要用结构化的方法，避免脑洞大开、想到哪是哪。
分析风险： 识别出来的威胁有几十上百个，哪些要优先处理？通常我们结合DREAD模型或经验法，给每个威胁打分，排序出最需要关注的那几个高优先级威胁。
确定缓解措施： 针对排序后的威胁，设计对应的安全机制。可能是加waf规则、也可能是做输入校验、或者是升级认证协议。最后，形成一份可执行的“安全需求清单”。

  避坑指南： 我曾经在一个大型电商项目的威胁建模中，卡在“识别威胁”这一步整整一周。后来发现，是因为我们在分解系统时没有考虑第三方支付网关的交互细节。这提醒我，流程图（尤其是数据流图）画得不好，威胁建模就建了个寂寞。

模型这东西，没有最好的，只有最合适的。我个人的感受是，项目类型决定了你该用哪一套家伙事。

STRIDE（微软）： 最经典，也最接地气。它把威胁分为伪装、篡改、抵赖、信息披露、拒绝服务、权限提升六类。我建议新手可以先从它入手，因为它非常结构化，对照着数据流图看，一个节点一个节点过，不太容易遗漏。
PASTA（风险流程分析）： 这是一个更偏向风险管理的模型。它把技术、业务和法律角度都揉进来了。适合那种需要和老板、业务方、法务一起开会的场景。
攻击树（Attack Trees）： 特别适合分析单点或单一逻辑的安全问题。比如你想搞清楚实现一个“忘记密码”功能可能存在哪些攻击路径，画一棵攻击树，非常清楚。
LINDDUN（隐私建模）： 这个专注于隐私威胁，比如非关联性、可观察性等等。如果你的项目涉及大量个人数据（PII），比如医疗、金融系统，LINDDUN是必备工具。

嗯，这里要注意，模型只是工具。真正有价值的，是你带着模型去思考问题时的那个过程，而不是机械地套模板。

重要提醒： 威胁建模不是一次性的。系统在变，攻击手法也在进化。我建议把它嵌入到你的日常迭代流程中，比如每次大版本更新前，重新跑一遍流程。别想着建一次就一劳永逸，这个世界上不存在永不失效的威胁模型。

看完这些概念和流程，我们来画一张图，把本章的知识脉络串一下。它能帮你在脑海中建立起一个全局视图。

这张图概括了本章的核心逻辑。从左到右，是一个从“定义目标”到“输出缓解措施”的闭环流程；从下往上，表示这个过程不是一次性的，需要根据系统变化持续迭代。