AWS服务IAM角色默认是否允许跨账户访问？安全配置问询

背景 #

AWS服务IAM角色（包括内置角色）通常采用无SourceAccount或SourceArn限制的信任策略，例如内置角色AWSServiceRoleForECS的策略如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ecs.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

AWS官方文档中提到，创建任务IAM角色时建议添加aws:SourceAccount或aws:SourceArn条件键，以防止“混淆代理”安全问题：

创建任务IAM角色时，建议在信任关系或角色关联的IAM策略中使用aws:SourceAccount或aws:SourceArn条件键进一步限定权限，以防止“混淆代理”安全问题。

但关于服务主体的跨账户访问限制，文档并未明确说明，以下是相关疑问的解答：

1. 若未限制SourceAccount或SourceArn，该角色是否真的默认允许任意AWS账户的服务扮演？ #

不会。AWS服务主体（如ecs.amazonaws.com）本身绑定了账户上下文——只有角色所在账户内的对应AWS服务，才能发起有效的AssumeRole请求并成功扮演该角色。其他账户的同名服务无法跨账户完成这一操作，因为AWS内部会验证请求的发起方账户是否与角色所属账户一致。

2. 限制这些值仅为“建议”，还是确保敏感角色不被获取ARN者滥用的必要要求？ #

属于安全最佳实践建议，而非强制必要要求。对于权限敏感的角色（例如能访问核心业务数据、执行高危操作的角色），添加SourceAccount/SourceArn约束能进一步缩小权限范围，降低“混淆代理”攻击的风险；但对于普通服务角色，默认的服务主体账户约束已经足够阻止跨账户滥用。

3. 若为必要要求，AWS为何提供允许其他账户扮演的内置角色？ #

内置角色的设计目标是开箱即用，快速启用AWS服务的基础功能。默认策略通过服务主体的账户关联机制已经保证了基本安全性，添加额外条件会增加配置复杂度，不符合简化用户操作的设计初衷。同时，AWS认为默认防护足以覆盖绝大多数常规安全场景，高级安全需求由用户自行通过添加条件键实现。

4. 若不是，是什么阻止其他AWS账户扮演这些角色？是否有相关文档说明？ #

核心阻止机制是AWS服务主体的账户关联验证：每个AWS服务的请求都会携带发起方的账户标识，IAM在处理AssumeRole请求时，会自动验证服务主体对应的请求是否来自角色所在的账户。AWS官方文档明确指出，服务主体仅允许当前账户内的服务操作对应角色，无需额外条件即可防范跨账户访问。

内容的提问来源于stack exchange，提问作者laserslasers