📚 课程目录第4章权限滥用的常见场景

4. 权限滥用的常见场景

权限滥用这词儿，说白了就是「拿着合法的钥匙，干了不该干的事」。我在实际审计工作中，见过的滥用案例五花八门，但归根结底都能归到四个场景里：特权升级、横向移动、数据泄露、未授权操作。你如果能把这几个场景的套路摸透，大部分权限风险都逃不过你的眼睛。

4.1 特权升级

特权升级是最典型的滥用方式。用户本来只有普通权限，却通过某种方式拿到了管理员级别的权限。我印象最深的一次，是一个开发人员利用 IAM 策略中的 iam:PassRole 加上通配符，把自己临时角色的权限提升到了管理员级别。

核心漏洞点：策略语句中滥用 *、条件表达式缺失、角色信任关系过于宽泛。

举个例子，假设你有一个 Lambda 执行角色，本来只允许它访问 DynamoDB。但如果你在信任策略里写了 "Principal": "*"，那任何人都可以把这个角色附加到自己的资源上。

我的排查经验：优先看 sts:AssumeRole 的源 IP 和 RoleSessionName。如果同一个角色被多个不同用户频繁切换，基本就是有猫腻。

4.2 横向移动

横向移动，很形象——攻击者拿到一个低权限账号后，像蜘蛛一样在系统里爬，寻找下一个跳板。我见过最经典的操作是：攻击者利用 EC2 实例元数据服务（IMDS）偷取临时凭证，然后用这个凭证去 AssumeRole 另一个更高权限的角色。

为什么能成功？很多团队会把 IAM 角色直接挂在 EC2 上，并且忘记限制 IMDS 的访问范围。攻击者只要在实例上执行 curl http://169.254.169.254/latest/meta-data/iam/security-credentials/，凭证就到手了。

避坑提醒：我曾经在审计中发现，某公司所有 EC2 都绑定了同一个管理角色，只要一台失陷，整个账号的钥匙都被人拿到了。所以，尽量用 IMDSv2，并且开启 hop limit 限制。

检测横向移动的关键在于时序和地域异常。比如，一个在北京的服务器突然在深夜尝试 AssumeRole 一个美国区域的角色，这就不正常。我会这样写查询规则：

-- 用 Athena 分析 CloudTrail
SELECT eventTime, userIdentity.arn, sourceIPAddress, 
       requestParameters.roleArn
FROM cloudtrail_logs
WHERE eventName = 'AssumeRole'
  AND userIdentity.type = 'AWSService'
  AND sourceIPAddress NOT LIKE '10.%'
ORDER BY eventTime;

4.3 数据泄露

数据泄露往往是前两个场景的最终目的。攻击者拿到特权或横向移动成功后，会疯狂拉数据。最常见的是批量读取 S3 对象、下载 RDS 快照，或者通过 API 导出日志。

我遇到过一个案子：某个 SaaS 应用的服务账号给了 s3:GetObject 和 s3:ListBucket 权限，但策略里忘了加 Condition 限制前缀。结果一个离职员工用这个 Key 遍历了一个公开桶，把几万条客户数据导出到了外部存储。

经验细节：不要只看 API 调用次数，要看数据量。同样的 GetObject 调用，平时 100KB 的请求突然变成 10MB，大概率有问题。我会在 CloudWatch 里设置 BytesTransferred 的异常阈值。

另外，注意 s3:PutObject 到外部账号的桶——这是最直接的泄露通路。建议对所有跨账号写入操作设置告警。

4.4 未授权操作

这个场景比较隐蔽。用户并没有提升权限，他只是执行了某个本应被禁止的操作，但因为这个操作没有被显式 Deny，或者因为策略评估逻辑的漏洞，他成功了。比如，你写了一条 Deny 策略拒绝删除特定资源，但用户通过其他 API 间接完成了删除（例如通过 CloudFormation 删栈）。

我犯过类似的错误。当时写了一个策略，允许用户管理 EC2 实例，但禁止 Terminate。结果我忘了把 ec2:TerminateInstances 加到 Deny 里，只 Deny 了 RunInstances。用户手动在控制台点了“终止”……嗯，那次事故让我学会了：Deny 必须覆盖所有可能导致相同效果的操作。

深层原理：IAM 策略评估遵循 Explicit Deny > Allow > Implicit Deny。如果没有写 Deny，且某个 Allow 匹配，那操作就被允许了。你需要考虑所有等效 API，比如 ec2:StopInstances 加 ec2:StartInstances 组合也能达到中断服务的效果。

检测未授权操作其实很难，因为它在日志里通常是 AccessDenied 或 Success——没错，成功跑通了。我的做法是：

记录所有 AccessDenied 事件，分析用户意图
对敏感 API（如 iam:UpdateAssumeRolePolicy）做白名单审计
定期用 IAM Access Analyzer 扫描未预期的外部访问

这四个场景并不是孤立的。很多时候，攻击者会先未授权操作（比如利用配置错误拿到凭证），然后特权升级获得管理员，接着横向移动到数据所在的账号，最后批量下载数据。所以，你需要的是一张能看清整个攻击链路的图。

这四个场景基本覆盖了我在实际工作中遇到的 90% 的权限滥用问题。下一部分我会讲如何把这些检测方法落地成具体的告警规则和自动化脚本。记住，别等到出事了再补救，平时多看看 CloudTrail 日志里的异常模式，能省很多事。