威胁建模：你到底在防谁
不做威胁建模的安全工作是在拜神——四类攻击者的动机与手法截然不同，防住脚本小子的措施对定向攻击毫无意义。用一张表把「防谁、护什么、丢了多疼」问清楚。
威胁建模：你到底在防谁
先问一个问题：你的网站被打了，最坏的结果是什么？
如果答不上来，后面所有的加固都是在凭感觉花钱。有人给个人博客上了 WAF 高级版，却把数据库密码明文写在 GitHub 公开仓库里——防线的强度不重要，最薄的那一环才重要，而找出最薄的那一环，靠的就是威胁建模。
四类攻击者，四种打法
把「攻击者」当成一个笼统概念是最大的误区。他们的动机、耐心、能力天差地别：
| 类型 | 动机 | 典型手法 | 对你的实际威胁 |
|---|---|---|---|
| 自动化扫描器 | 广撒网，不针对你 | 扫全网 IP，试已知 CVE、默认口令、.git 泄露、.env 泄露 | 占实际攻击量的 95% 以上，也最好防 |
| 脚本小子 | 炫技、挂黑页 | 用现成工具跑一遍，看哪个洞能进 | 主要打没打补丁的老系统 |
| 牟利型 | 挖矿、勒索、卖数据、薅羊毛 | 找能变现的：接口刷量、数据库脱库、服务器算力 | 有电商/会员/积分的站要重点防 |
| 定向攻击 | 特定目标，有预算有耐心 | 社工、供应链、0day、长期潜伏 | 个人站基本遇不上；真遇上了，单靠技术措施挡不住 |
这张表最重要的一行是第一行。 绝大多数「被黑」不是有人盯上了你，而是你的服务器恰好出现在某个扫描器的 IP 段里，恰好开着一个有已知漏洞的服务。
这带来一个非常实际的结论：
把 80% 的精力花在挡住自动化扫描上，投入产出比最高。 具体就是三件事：及时打补丁、不要有默认口令、不要泄露不该公开的文件。这三件事做到位，你已经躲过了绝大多数真实攻击。
反过来，如果这三件没做，买再贵的 WAF 也只是给一栋没锁门的房子装了监控。
三个问题，问清楚就够了
正式的威胁建模有 STRIDE、PASTA 一堆方法论。对一个网站来说，回答清楚三个问题就足以指导行动：
一、护什么（资产）
把你系统里「丢了会疼」的东西列出来，按疼的程度排序：
| 资产 | 例子 | 丢了会怎样 |
|---|---|---|
| 用户凭据 | 密码哈希、会话 token、OAuth refresh token | 最严重：会被拿去撞库，波及用户在别处的账号 |
| 个人信息 | 手机号、身份证、地址、订单 | 法律责任（个人信息保护法），且不可撤销 |
| 业务数据 | 订单、内容、配置 | 直接业务损失 |
| 算力与带宽 | 服务器、CDN 流量 | 被挖矿、被当跳板；账单可能是数量级的 |
| 域名与声誉 | 域名本身、搜索排名 | 被挂马后搜索引擎标红，恢复要数周 |
很多人漏掉最后两项。 一台被挖矿的云服务器，一个月能烧掉远超你预算的钱；一个被挂了黑帽 SEO 的博客，搜索流量清零。
二、从哪进（入口）
把所有「外部输入能到达的地方」列出来。不只是表单——凡是攻击者能控制内容的，都是入口：
- HTTP 请求的每个部分：URL 路径、query、Header（含
Host、User-Agent、Referer）、Cookie、body - 文件上传
- 第三方回调（支付、OAuth、Webhook）
- 你依赖的一切：npm 包、Docker 基础镜像、CDN 上的第三方脚本
- 运维通道：SSH、云控制台、CI/CD、域名注册商后台
最后一项是最容易被整体遗忘的。 你把网站加固到牙齿，但域名注册商账号用的是复用密码、没开二次验证——攻击者直接改 DNS 把域名解析到自己的服务器，你所有的 Nginx 配置、WAF 规则、后端校验一行都不会被执行。
下一部分第一篇专门讲这件事，它排在最前面不是偶然。
三、丢了多疼（影响）
同样是「泄露一张表」，泄露文章列表和泄露用户手机号，严重性差几个数量级。用这个粗略的分级排优先级：
- P0 · 不可挽回：明文密码、身份证、支付信息泄露；服务器被完全控制。
- P1 · 严重但可控：会话劫持、越权读取他人数据、内容被篡改。
- P2 · 有损失但能恢复：短时 DoS、资源被薅。
- P3 · 主要是难看：版本号泄露、目录列表打开。
修复顺序按 P 级走，不按修复难度走。 一个花两天修的 P0，优先级高于十个花十分钟修的 P3——虽然后者做起来更有成就感。
一个真实的例子：给个人博客建模
拿本站这类静态博客做示范，结论可能和你想的不一样：
| 项 | 结论 |
|---|---|
| 主要攻击者 | 自动化扫描器（几乎唯一） |
| 核心资产 | 域名（最值钱）、服务器算力、搜索排名 |
| 用户数据 | 几乎没有——纯静态站，没有登录、没有数据库 |
| 最高风险 | 域名被劫持；服务器被当矿机；CI/CD 凭据泄露导致投毒 |
| 最不值得投入 | SQL 注入防护（没有数据库）、复杂的 WAF 规则 |
注意最后一行。 一个纯静态站去研究 SQL 注入防护是浪费时间；但很多安全清单会把它列在第一条，因为那些清单不是为你写的。
反过来，这类站真正的高风险在供应链：CI/CD 里的一个 token 泄露，攻击者就能直接改构建产物，往每个页面里插一段脚本。这比任何 XSS 都严重，因为它绕过了所有前端防御。后面有一整章讲密钥管理。
小结
- 95% 以上的攻击来自不针对你的自动化扫描，打补丁 + 无默认口令 + 不泄露文件能挡住大部分。
- 建模只需回答三问：护什么、从哪进、丢了多疼。
- 入口清单必须包含运维通道（注册商、CI/CD、云控制台），它们常被整体遗忘。
- 按影响分级排优先级，不要按修复难度。
下一章把「从哪进」这个问题铺开——跟着一次请求，看它一路经过多少个可以被做手脚的地方。👉 一次请求的旅程