攻击路径建模：从初始访问到数据窃取
做过云安全评估的朋友都知道，光看单个漏洞没啥用。攻击者不会只卡在一个点上。他们总是找一条链，从一个入口摸到你最值钱的数据。所以这一章，我想跟你聊聊怎么把这个链条画出来，怎么从初始访问一直建模到数据被拿走的那一刻。
记不记得我前两年做某金融云的项目？客户说“我们EC2打了补丁，S3桶也设置了ACL，应该没问题”。结果我顺着一个暴露在公网的API网关一路往里走，发现它竟然能直接调一个Lambda函数，而这个函数又有权限读写RDS里的客户隐私表。这一路下来用了不到10个步骤。当时我就想——如果没有攻击路径建模，你可能以为云上固若金汤，实际上敌人已经走到保险柜门口了。所以这一节的内容，非常关键。
攻击路径的构成要素
一条完整的攻击路径，说白了就是一系列动作。我习惯把它拆成五个核心阶段：
- 初始访问——攻击者怎么进来的？可能是一个泄露的访问密钥、一个未打补丁的Web应用、一个被钓鱼的IAM用户。
- 权限提升——进来之后，怎么从普通权限爬到更高的角色？比如利用IAM配置错误拿到管理员权限，或者利用容器逃逸拿到宿主机控制权。
- 横向移动——拿到一个点后，怎么跳到其他资源？通过VPC对等连接、跨账号信任关系、或者被劫持的Service Account。
- 数据收集与暂存——找到目标后，把数据从数据库、S3桶、云盘等位置聚拢到一处，准备打包。
- 数据窃取——最后一步，把数据传输出去。可能通过外网出站策略过于宽松的NAT网关，或者直接上传到外部对象存储。
这五个阶段不是必须按顺序一个一个来，有时候会跳过或并行。但你画路径图的时候，至少要把它们都考虑进去。
攻击路径建模方法
用什么工具来建模？我个人常用的是攻击图（Attack Graph）加上MITRE ATT&CK云矩阵的映射。攻击图能直观地画出“如果A条件成立，就能B；B又可以导致C”。而MITRE ATT&CK可以帮你识别每一步对应哪个具体技术（TTP）。
举个例子，你得先回答这几个问题：
- 初始访问：T1078（有效账号）、T1190（利用公开应用漏洞）还是T1525（受损的云服务客户凭证）？
- 权限提升：T1098（账号操作）、T1548（滥用提升权限机制）？
- 横向移动：T1021（远程服务）、T1550（使用替代认证材料）？
- 数据窃取：T1530（从云存储对象窃取数据）、T1048（通过替代协议外传）？
嗯，这套映射你得在建模之前就列好。否则图画到一半发现少了某个威胁的上下文，就很尴尬。
我的一个小技巧： 先画一个最简单的单链路径（比如公网API ⇒ Lambda ⇒ RDS ⇒ 外传），再一点点增加分支和条件。别一上来就想把整个云环境全画上，那样你只会得到一团乱麻。
另外，威胁建模的框架里，STRIDE也很有用。只是STRIDE更偏软件设计层面，而云环境的攻击路径建模更需要结合网络拓扑和IAM权限。我建议你把两种方法混着用——用STRIDE找风险点，用攻击图串路径，再用MITRE ATT&CK给每个节点打标签。
典型路径实例：从公开S3桶到全账号沦陷
说一个我实际画过的路径，你感受一下。
| 阶段 | 动作 | 条件 | MITRE ATT&CK ID |
|---|---|---|---|
| 初始访问 | 攻击者扫描到一个公开可读的S3桶，从中下载了包含的配置文件 | S3桶配置为公开读取，且存有敏感文件 | T1530（从云存储获取数据） |
| 权限提升 | 用调用AssumeRole，切换到高权限角色 | 该密钥附加的IAM用户有sts:AssumeRole到AdminRole的权限 | T1538（AssumeRole滥用） |
| 横向移动 | 使用AdminRole在EC2实例上安装后门，并利用VPC对等连接跳转到生产环境 | 安全组规则允许SSH从跳板机到生产实例 | T1021（远程服务） |
| 数据收集 | 在生产环境的RDS实例上执行SELECT * FROM credit_cards | AdminRole有rds:DescribeDBInstances和连接数据库的权限 | T1552.005（云机密库） |
| 数据窃取 | 用S3 API将导出的数据分片上传到攻击者控制的另一个AWS账户 | 目标桶的S3策略允许跨账户写入 | T1048（通过替代协议外传） |
你看，一个公开S3桶就引出了五步链。你可能会说“我们的S3桶不会公开吧？”但我曾经过看到很多组织只是在IAM策略里加了“Public”一词，结果S3桶的ACL却变成了Anyone——别问我是怎么知道的。
避坑： 千万不要只画“能成功”的路径。失败的路径也很重要——比如某些权限检查会阻断攻击，你要把这些检查点也画出来。这样你才能知道在哪里加固最有效。
可视化攻击路径
下面这张图是我个人最常用的攻击路径模型骨架。它展示了从一个外部入口到内部数据资产的典型链条。每个节点代表一个具体资源或动作，箭头表示“可以利用”。
画完之后，你就有了一张一目了然的攻击路径图。不过我建议你在图上再加上条件标签，比如“需要sts:AssumeRole”、“需要EC2安全组入口”。这样别人拿到你画的图，不用问也能看懂。
建模时常见的坑
- 只画正向，不画反向。 攻击路径也可以从数据资产倒推到外部入口。我会两种都画，交叉验证。
- 忘记信任边界。 比如AWS Organizations里多个账号之间的信任、VPC对等连接、外网暴露面——这些都是横向移动的桥梁。
- 忽略数据在途和静止的区别。 攻击者可能在传输过程中截获（比如未加密的Kinesis流），也可能直接读S3桶。建模时要把数据状态标出来。
我曾经在一个客户的攻击路径建模中漏掉了KMS密钥权限——实际上某个Lambda函数可以调用kms:Decrypt，而RDS的存储加密恰好用了同一个CMK。这意味着只要盗取了Lambda的环境变量，就能解密整个数据库。还好我在最后审核时补上了这个分支，否则报告的结论会差很多。
嗯，攻击路径建模不是一次性的活。你每次云环境变更（新服务上线、权限调整、网络拓扑变动）都应该重新走一遍。我自己的习惯是每次大版本发布前跑一次自动化攻击路径分析工具，然后人工核查。这样没坏处。你看明白了吗？