威胁建模入门：STRIDE模型详解、数据流图绘制方法、识别信任边界
威胁建模这件事，说白了就是在系统还没写一行代码之前，先把自己想象成攻击者，到处找茬。我见过太多团队，上线前一天才做安全测试，结果发现架构级漏洞，改都改不动。所以，咱们得把安全左移——移到设计阶段。
这一章，我会带你走完威胁建模的三个核心动作：画图、找威胁、划边界。工具就是STRIDE模型和数据流图（DFD）。
2.1 STRIDE模型：六类威胁，一个不漏
STRIDE是微软提出来的威胁分类法。每个字母代表一类威胁。为什么要分类？因为不同威胁的缓解措施完全不同。你想想看，防篡改和防信息泄露，用的技术能一样吗？
| 威胁类型 | 英文 | 核心问题 | 典型例子 |
|---|---|---|---|
| S 欺骗 | Spoofing | 攻击者能否冒充他人身份？ | 伪造JWT Token、盗用Session |
| T 篡改 | Tampering | 数据或代码能否被非法修改？ | SQL注入修改数据库、中间人改请求体 |
| R 抵赖 | Repudiation | 用户能否否认做过某操作？ | 无审计日志、日志被删 |
| I 信息泄露 | Information Disclosure | 敏感数据能否被未授权访问？ | API返回明文密码、日志打印身份证号 |
| D 拒绝服务 | Denial of Service | 系统资源能否被耗尽？ | CC攻击、未限流的文件上传 |
| E 权限提升 | Elevation of Privilege | 普通用户能否获得管理员权限？ | 水平越权、垂直越权 |
我的小技巧： 每次做威胁建模，我都拿STRIDE当检查清单，对着数据流图一个一个过。别凭感觉想，要对着图看。漏掉一个，可能就是上线后的一个漏洞。
2.2 数据流图（DFD）：把系统画出来，威胁才看得见
数据流图是威胁建模的“地图”。没有地图，你连敌人在哪都不知道。我个人习惯用分层DFD，从上下文图开始，逐步细化到内部流程。
2.2.1 DFD的四个基本元素
- 外部实体（矩形）：用户、第三方系统、定时任务。这些是数据的起点或终点。
- 过程（圆形/圆角矩形）：处理数据的逻辑单元，比如登录服务、支付模块。
- 数据存储（两条平行线）：数据库、缓存、文件系统。
- 数据流（箭头）：数据在元素之间的流动方向。
嗯，这里要注意：数据流必须标注内容。别只画个箭头写个“数据”，要写清楚是“用户凭证”、“订单信息”还是“日志记录”。
2.2.2 绘制步骤
- 画上下文图：把整个系统画成一个过程，外面画外部实体。这一步看清系统边界。
- 分解核心过程：把系统内部拆成子过程。比如“订单服务”拆成“创建订单”、“支付处理”、“库存扣减”。
- 标注数据流：每一条线上写清楚传输的数据内容。
- 标记信任边界：用虚线框出不同信任等级的区域。
避坑指南： 我曾经在一个项目中，团队画DFD只画了外部实体和过程，完全没画数据存储。结果威胁建模时，所有人都忽略了数据库的篡改风险。后来上线第一天就被拖库了。所以，数据存储必须画出来，哪怕你觉得它“不重要”。
2.3 识别信任边界：安全的分界线
信任边界，就是不同安全等级区域之间的分界线。数据跨过这条线，风险就变了。比如，从浏览器到Web服务器，从Web服务器到数据库服务器，每跨一次，就要重新验证。
常见的信任边界有：
- 用户端 ↔ 服务端：用户输入不可信，必须校验。
- 内网 ↔ 外网：外网流量默认不可信。
- 应用层 ↔ 数据层：应用层不能直接信任数据库返回的数据。
- 微服务之间：服务间调用需要认证和鉴权。
注意： 信任边界不是物理防火墙，而是逻辑上的安全假设。你画DFD时，用虚线框出每个信任域，然后在虚线穿过的地方，就是你要重点做安全控制的地方。
2.4 实战：一个登录系统的威胁建模
咱们拿一个最简单的登录系统来练手。系统包含：浏览器、登录API、用户数据库、Redis Session存储。
2.4.1 数据流图（DFD）
下面这张SVG图，展示了登录系统的数据流和信任边界。你看，数据从浏览器出发，穿过信任边界进入服务端，再流向数据库和Redis。
2.4.2 用STRIDE逐条过威胁
图有了，咱们拿STRIDE清单对着过一遍。我习惯用表格记录，方便后续评审。
| 数据流/元素 | STRIDE威胁 | 风险描述 | 缓解措施 |
|---|---|---|---|
| 浏览器 → 登录API | Spoofing | 攻击者伪造请求，冒充合法用户 | 使用HTTPS + 防CSRF Token |
| 登录API → 用户数据库 | Tampering | SQL注入篡改查询语句 | 参数化查询 / ORM |
| 登录API → Redis | Tampering | Session数据被篡改 | Session签名 / HMAC |
| 登录API → 浏览器 | Information Disclosure | Token泄露或Cookie未设置Secure/HttpOnly | 设置Cookie安全属性 + Token短有效期 |
| 登录API | Denial of Service | 暴力破解导致API过载 | 限流 + 验证码 + 账户锁定 |
| 用户数据库 | Elevation of Privilege | 数据库账户权限过高，可执行危险操作 | 最小权限原则，只给SELECT/INSERT |
我的经验： 别试图一次把所有威胁都找全。第一轮先找最明显的，比如跨信任边界的数据流。第二轮再深入。我一般会做三轮：第一轮画图+找边界，第二轮STRIDE逐条过，第三轮评审+补充。三轮下来，基本能覆盖90%的威胁。
2.5 本章小结
威胁建模不是一次性的工作。系统迭代一次，DFD就要更新一次，STRIDE就要再过一遍。你想想看，架构都变了，威胁面能不变吗？
记住三个核心动作：画数据流图、用STRIDE找威胁、标信任边界。这三步走扎实了，后面的安全设计才有根基。