信任策略写宽一格，整个账号就成了别人的跳板

云上跨账号协作的标准做法是角色委托：业务账号不直接给对方密钥，而是声明"某个外部账号可以临时扮演某个角色"。设计初衷是收窄权限、缩短暴露窗口。但实际配置中，这条策略经常被写成"某个租户下的任何账号都可以扮演"，甚至干脆给到管理员权限。信任链一旦写宽，临时借用就变成了长期通行。

一、委托的本质是单向信任声明
信任策略由资源拥有方书写，内容是"谁、在什么条件下、可以扮演哪个角色"。它不校验请求者的业务意图，只校验身份与条件。这意味着策略里的每一个字段都是权限边界：Principal 写多宽，能进来的人就有多广；条件写不写，决定了是否任何人都能冒用；角色给多大，进来之后能干多少事。

很多配置只关注了第一项和第三项，把中间那项——条件——留空。这正是问题所在。

二、三种常见的写宽方式
第一种，Principal 写成整个租户或整个组织，而不是具体的账号 ID。对方组织内任何一个被攻破的账号，都能发起扮演请求。

第二种，不校验外部 ID（ExternalId）。这个字段存在的意义，就是区分"同一个第三方服务商的哪个客户"，缺失后攻击者只要猜到角色 ARN，就能用自己的账号发起请求，把受害者的资源当成自己的。

第三种，托管策略直接挂 Administrator。委托方图省事，被委托方也乐得方便，结果是任何一次凭证泄露都等价于主账号泄露。

三、混淆代理：信任被当成跳板
更隐蔽的利用方式叫混淆代理。攻击者并不直接持有你的信任，而是诱导持有信任的第三方服务去执行操作。比如某 SaaS 平台被授权访问你的对象存储，攻击者通过该平台的一个越权接口，让平台"代为"读取你的桶。平台的身份是合法的，请求路径也是合法的，异常只出现在业务语义上。

这类攻击绕过了身份校验，只能靠权限粒度和调用审计发现。所以委托角色不应该拥有"能读整个桶"这类粗粒度权限，而应限制到前缀、表或具体 API。

四、把信任收窄到可验证的范围
落地时按顺序做四件事：Principal 精确到账号 ID；强制校验 ExternalId 并在服务端比对；角色策略只授予本次协作真正需要的动作，能按资源前缀限制就限制；会话凭据设置分钟级有效期，并要求每次扮演都留下审计记录。

再加一条经常被忽略的：定期反查"谁还能扮演我"。委托关系会随项目结束而失效，但策略常常没人清理，半年后仍在生效的旧信任，就是没人看守的后门。

结语
跨账号委托不是安全负担，而是比分发长期密钥更好的方案——前提是策略写得足够窄。身份具体、条件可校验、权限最小、时效短、可审计，这五条把"临时借用"锁在了它该在的范围里。信任策略的宽度，本质上就是账号的暴露面宽度，写宽一格，代价可能是一整个账号。

标签：云安全、IAM、信任委托、最小权限