保护一个你没有构建的云环境

你刚刚被交付了一个已经放任自流三年的云账户的钥匙。没有人留下文档。IAM 有 40 个角色，权限设置了通配符，有些 S3 存储桶没人记得创建过，上一个理解网络拓扑的人在 2022 年离开了公司。这比大多数职位发布所承认的要常见得多，而且头一个月为之后的一切定下了基调。

在动手前先掌握清单

抵制住立即开始锁定的冲动。你首先需要一张地图。跨所有地区运行 aws resourcegroupstaggingapi get-resources，不只是 us-east-1——团队喜欢在 ap-southeast-2 里旋转测试资源然后忘记它们。配合已启用的 AWS Config，或者如果还没启用就现在启用。在 Azure 上，az resource list --output table 导入电子表格作为初步检查就行。在 GCP 上，Cloud Asset Inventory 的 gcloud asset search-all-resources 给你同样的视图。

交叉参考账单。任何花费金钱的东西都应该出现在你的资源清单中；清单中任何最近没有活动的东西都是归档的候选项。这里的差异通常就是可怕的东西隐藏的地方——有公网 IP 的孤立 EC2 实例、未加密的被遗忘 RDS 快照、指向虚无的负载均衡器。

像调查犯罪现场一样审计 IAM

拉出每一条 IAM 策略，找 "Action": "*" 结合 "Resource": "*" 的组合。这种组合除了少数几个应急管理员角色外不应该存在，即使那些也应该有 MFA 强制和 CloudTrail 告警连接。使用 IAM Access Analyzer 找授予外部账户访问权限的角色——这能捕获有意的跨账户信任关系和某人针对错误账户 ID 测试 Terraform 模块时出现的错误。

用 aws iam generate-credential-report 检查 90 天以上未动过的访问密钥。继承的环境几乎总是有长期活跃的密钥附加到服务账户，有时硬编码在 Lambda 环境变量或 Jenkins 作业中。轮换它们，但分阶段进行——杀死一个夜间批量作业依赖的密钥在凌晨 2 点就是你在第一周被唤醒的原因。

在攻击者发现前找出公开暴露

跨你的 VPC 运行网络可达性检查。在 80/443 之外的任何端口上配置了 0.0.0.0/0 的安全组需要理由，而不是假设。ScoutSuite 或 Prowler 这样的工具会在几分钟内遍历整个账户并按严重程度排序后吐出报告——从那开始而不是从头构建自己的检查清单。

S3 存储桶需要特别关注，因为它们是继承环境的经典地雷。同时检查存储桶策略和账户级别的