4、攻击面分析：攻击向量识别、攻击树构建、攻击面缩减原则
攻击面分析，说白了就是回答一个问题：攻击者能从哪些地方打进来？
我见过不少团队，安全需求写得漂漂亮亮，一到落地就懵了。为什么？因为他们没搞清楚自己的系统到底暴露了多少入口。今天我们就来把这层窗户纸捅破。
4.1 攻击向量识别：找到所有入口
攻击向量，就是攻击者用来进入系统的路径。我习惯把它分成三类：
| 类别 | 典型例子 | 我踩过的坑 |
|---|---|---|
| 网络攻击向量 | 开放端口、未加密API、DNS劫持 | 有一次线上环境忘了关调试端口，被扫出来直接提权 |
| 应用攻击向量 | SQL注入、XSS、文件上传漏洞 | 文件上传没做类型校验，被人传了个webshell |
| 人为攻击向量 | 钓鱼邮件、弱口令、内部人员泄密 | 最头疼的其实是这个，技术手段防不住猪队友 |
我的习惯：每做一个新功能，先画一张「数据流图」，把外部输入点全部标红。这些红点就是攻击向量。
识别攻击向量时，我通常会问自己三个问题：
- 谁可以访问这个接口？——匿名用户？认证用户？管理员？
- 输入数据从哪里来？——用户表单？第三方回调？消息队列？
- 输出数据去了哪里？——数据库？缓存？下游系统？
嗯，这三个问题问完，80%的攻击向量就浮出水面了。
4.2 攻击树构建：把攻击路径可视化
攻击树，是一种树形结构。根节点是攻击者的最终目标，子节点是达成目标需要做的每一步。
我个人特别喜欢用攻击树来做威胁建模。为什么？因为它能把一个抽象的安全目标，拆成具体可执行的动作。你想想看，当你看到一棵完整的攻击树时，你就知道该在哪些节点上设防了。
下面是我为一个「用户登录模块」构建的攻击树示例：
构建攻击树的步骤：
- 确定攻击者的最终目标（根节点）
- 问自己：要达成这个目标，攻击者需要先做什么？
- 继续分解，直到每个叶子节点都是一个具体的、可被利用的弱点
- 给每个叶子节点打上「可利用性」和「影响程度」的标签
我曾经在一个支付系统的攻击树里，发现了一个「通过修改请求金额」的叶子节点。当时团队都觉得不可能，因为前端做了校验。但实际测试发现，后端根本没做二次校验。嗯，这就是攻击树的价值——让你看到那些「你以为没问题」的地方。
4.3 攻击面缩减原则：能关的门就别开着
攻击面缩减，不是让你把所有功能都砍掉。而是让你只暴露必须暴露的。
我总结了四个原则，每次做架构评审时都会过一遍：
| 原则 | 具体做法 | 我踩过的坑 |
|---|---|---|
| 最小暴露原则 | 只开放必要的端口、协议、接口 | 曾经有个服务开了22端口，结果被暴力破解 |
| 默认安全原则 | 默认配置就是最安全的配置 | Redis默认没密码，上线忘了改，数据被删了 |
| 纵深防御原则 | 不依赖单层防护，多层叠加 | WAF挡了SQL注入，但没挡文件上传，还是被搞了 |
| 最小权限原则 | 每个组件只给够用的权限 | 数据库连接用了root账号，结果SQL注入直接拖库 |
注意：攻击面缩减不是一次性的工作。每次版本迭代、每次配置变更，都可能引入新的攻击面。我建议把攻击面分析纳入CI/CD流程，每次构建都自动扫描一次。
实际操作中，我习惯用一张「攻击面清单」来跟踪：
- 网络层：开放端口、防火墙规则、VPN接入点
- 应用层：API端点、文件上传、第三方回调
- 数据层：数据库暴露、缓存服务、日志存储
- 运维层：SSH密钥、管理后台、监控接口
每发现一个攻击面，就问自己：这个接口真的需要对外暴露吗？如果答案是否定的，就关掉。如果是肯定的，就加上防护。
一个小技巧：用「攻击面热力图」来可视化。把攻击面按「暴露程度」和「影响程度」画成矩阵，优先处理右上角那些又容易打、打中了又疼的。
最后说一句：攻击面分析不是让你变得疑神疑鬼，而是让你心里有数。你知道哪里可能有风险，你就能提前布防。这比出了事再补救，成本低得多。