AWS成品号 跨账号访问 AWS 资源失败？STS AssumeRole 与信任策略（Trust Policy）避坑
AWS成品号 跨账号访问 AWS 资源失败时，很多人第一反应是改 Trust Policy，但实际常见是账号状态、Caller 权限、SCP、KMS 或资源策略一起卡住。下面按排障顺序说清楚，帮你判断是账号问题、策略问题，还是业务架构本身不适合这样做。
跨账号访问 AWS 资源失败时，先判断卡在哪一层
AssumeRole 能不能成功，取决于四层：发起方身份策略、目标角色信任策略、组织级控制、资源侧策略。只改其中一层，很多时候不会生效。
- 能否发起 AssumeRole：发起账号的用户或角色是否允许 sts:AssumeRole。
- 目标角色是否接受：Trust Policy 里的 Principal、Condition 是否匹配。
- 扮演后能否继续访问资源：S3、ECR、KMS、Secrets Manager 这些常常还有各自的资源策略。
- 是否被更高层拦截：AWS Organizations 的 SCP、权限边界、显式 Deny。
先排除账号层面的阻断：购买、认证、支付、风控
如果你们是新开 AWS 国际账号、通过代理/代开户注册，或者账号刚从其他团队交接过来，先别急着改策略。账号状态异常时，权限配置看起来都对，实际还是会失败。
- 账号归属不清：主邮箱、手机号、账单联系人不在公司可控范围内，后续支持工单、额度申请、组织管理都会受影响。
- AWS成品号 企业信息未补全：公司资料、税务信息、付款资料不完整，常见于新账号初期开通后几天内被反复校验。
- 支付方式异常：信用卡扣款失败、账单逾期、支付审核未通过时，部分创建资源、扩容、开通新服务会受限。
- 风控审核中：短时间开了太多资源、频繁切换登录地点、多人共用同一账号，容易触发额外验证。
- AWS成品号 资源额度太低：新账号默认配额小，跨账号排障时容易误以为是权限失败，实际是实例、EIP、NAT、KMS 配额没过。
经验上，先确认账单、实名认证/企业认证、账号归属和风控状态，再看 Trust Policy，能少走很多弯路。
STS AssumeRole 与 Trust Policy 的高频坑
1. Principal 写错了
最常见的是把用户 ARN、角色 ARN、账号 ID 混着写。目标角色的信任策略里，Principal 必须和实际发起方一致；如果你们是中间跳板角色、自动化账号或第三方代维，填错一层就会拒绝。
2. Condition 过严
- ExternalId 没传，或者传值和策略不一致，常见于第三方访问。
- aws:PrincipalArn、aws:PrincipalOrgID、aws:SourceIp 写得太死，换个角色路径或出口 IP 就失败。
- 要求 MFA，但自动化任务没带 MFA。
3. 只改了信任策略，没改发起方权限
发起方账号里还要允许 sts:AssumeRole。很多人只在目标角色上放行，结果调用方根本没有去扮演的权限。
4. 角色能扮演，但资源仍拒绝
这是第二层常见误区。假设你用扮演后的角色访问 S3、KMS、ECR、Secrets Manager，目标资源可能还有自己的 bucket policy、key policy 或 repository policy。尤其是 KMS，经常只改 IAM 不改 key policy，结果依然报 AccessDenied。
5. SCP 和权限边界在暗中拦截
如果账号在 Organizations 里，SCP 一旦禁了 sts:AssumeRole、iam:PassRole、kms:Decrypt 等动作，单独看 IAM 文档都会误判。权限边界也一样，表面允许，实际被边界裁掉。
场景分析：不同业务场景，排查顺序不一样
| 业务场景 | 最容易出问题的点 | 优先检查什么 |
|---|---|---|
| 多账号开发/生产隔离 | 目标角色只放了某个账号，没覆盖 CI/CD 角色 | Trust Policy、发起方 IAM、SCP |
| 临时给外部供应商开通访问 | ExternalId、SourceIp、会话时长限制 | 信任策略条件、会话有效期、审计日志 |
| 迁移数据或做运维代管 | S3/KMS/Secrets 资源策略没放行 | 资源策略、KMS key policy、跨区访问路径 |
| 统一账单下的多团队账号 | 账号之间权限边界过重 | 组织结构、SCP、角色命名和最小权限 |
| 新采购账号准备上线 | 支付、风控、额度都没稳定下来 | 账单状态、企业资料、服务配额、预算告警 |
实际排障建议：按这个顺序看，效率最高
- 确认账号状态正常：账单未欠费、支付方式可用、企业信息完整、没有风控冻结。
- 确认是谁在扮演谁：把发起方 ARN、目标角色 ARN、账号 ID 写清楚，别凭感觉核对。
- 看调用方是否有 sts:AssumeRole 权限，目标角色是否允许该 Principal。
- 把 Condition 先收窄到最少，排除 ExternalId、IP、MFA、OrgID 这些附加条件。
- 如果 AssumeRole 成功但资源访问失败，转去查资源策略和 KMS key policy。
- 最后再看 SCP、权限边界、会话标签、最大会话时长和区域限制。
常见错误与修正思路
| 现象 | 常见误判 | 更可能的原因 | 处理方式 |
|---|---|---|---|
| AssumeRole 直接 AccessDenied | 以为是资源没授权 | Trust Policy 或调用方 IAM 缺权限 | 先对照 Principal 和 sts:AssumeRole |
| 能切换角色，但 S3 仍拒绝 | 以为角色已经生效 | Bucket policy 或 KMS key policy 拒绝 | 检查资源侧策略，不只看 IAM |
| 某些机器能用，某些机器不行 | 以为是随机故障 | SourceIp、MFA、Session Tag 条件不一致 | 对比登录环境和会话参数 |
| 刚开通账号就各种失败 | 以为 AWS 本身不稳定 | 支付审核、风控、默认配额、资料不完整 | 先补齐账号和账单状态 |
成本控制与权限设计，最好一起做
跨账号访问不是越方便越好。很多企业后面出问题，不是技术不会配，而是权限过宽、账单不可控、账号没人管。
- 开发、测试、生产分账号，避免一个角色横扫全部环境。
- 给临时访问设置短会话，不要长期共享高权限角色。
- 用预算告警、标签和成本中心区分团队费用，减少“谁开了资源说不清”。
- 新账号先小范围验证，再放开批量创建，避免被资源额度和风控同时卡住。
- 如果是代理开户注册或账号交接，先把主账号、付款人、联系人、审计责任固定下来。
FAQ
Q1：是不是只要改 Trust Policy 就能解决跨账号访问？
通常不是。要同时看发起方 IAM、目标角色信任策略、资源策略、SCP 和 KMS key policy。很多失败其实不在 Trust Policy 本身。
Q2：新账号为什么总是先失败？
新账号常见问题不是权限，而是支付方式、企业资料、风控审核和默认配额没准备好。先把账号状态稳定下来，再做跨账号授权。
Q3：第三方代维访问最容易漏什么？
最容易漏 ExternalId、MFA 条件、IP 白名单，以及只放了 IAM 没放资源策略。做外部访问时，这四项要一起核对。
Q4：怎么判断是权限问题还是账号问题？
先看 CloudTrail 里的 AssumeRole 事件，再看账号是否有欠费、风控、企业信息未完成、额度不足。若 AssumeRole 成功但后续操作失败，通常是资源侧策略。
如果你现在是在做 AWS 账号采购、企业认证、支付方式配置，或者已经进入跨账号部署阶段，建议先把账号治理和权限模型一起梳理，再上生产。单独修一条策略，往往只是在掩盖下一次失败。
