AWS海外版 AWS IAM Role 赋予了权限依然报 Unauthorized？显式拒绝（Explicit Deny）排查

AWS IAM Role 赋予了权限依然报 Unauthorized？先别只盯着角色策略

很多人在排查 AWS IAM Role 的 Unauthorized 时，第一反应是“是不是少加了一条权限”。实际在企业环境里，更常见的情况是：权限看起来已经放开，但某个地方存在显式拒绝（Explicit Deny），或者账号状态、组织策略、资源策略把请求拦下了。只要有一处 Deny 生效，Allow 再多也没用。

如果你是在做海外业务部署、跨账号访问、CI/CD 自动化、S3/KMS/EC2 调用，这类问题尤其容易出现。下面按最省时间的方式排查，不绕概念，直接给结论和处理顺序。

先判断：这次到底是“权限没给够”，还是“被拒绝了”

先看报错属于哪一类，能少走很多弯路。

• 如果是 AccessDenied、is not authorized to perform、explicit deny，优先按显式拒绝排查。
• 如果是账号级别的付款失败、验证未完成、风控审核中、服务禁用，先处理账号状态，再看权限。
• 如果是创建资源失败、配额耗尽、区域不允许，更像资源限制或组织限制，不一定是 IAM Role 本身的问题。

经验上，很多团队把“账号被限制”误判成“角色没权限”。尤其是新开国际站账号、企业认证未完成、支付方式异常时，控制台和 API 的失败表现很像，但根因完全不同。

AWS IAM Role 显式拒绝（Explicit Deny）排查顺序

排查时不要只盯着角色上那几条 Allow，按下面顺序看，效率更高。

1. AWS海外版 确认当前是谁在调用：先用 aws sts get-caller-identity 看实际身份，避免拿错了 role、session、或临时凭证。
2. 检查角色自身策略：角色的附加策略、inline policy 里有没有 Deny、NotAction、NotResource 之类的隐蔽拒绝。
3. 看权限边界（Permission Boundary）：很多企业会给 role 限定边界，边界里只要没放行，实际效果就是被卡住。
4. 看会话策略（Session Policy）：如果是通过 AssumeRole、SSO、自动化平台临时扮演角色，会话策略可能比你想象得更严。
5. 看组织级 SCP：AWS Organizations 下，SCP 经常是“明明角色有权限，却还是不行”的根因。
6. 看资源策略：S3 bucket policy、KMS key policy、Secrets Manager policy、SQS policy、SNS policy、ECR policy 都可能单独拒绝。
7. 看 VPC Endpoint Policy：如果流量走了 PrivateLink 或 VPC Endpoint，endpoint policy 也会拦。
8. 看条件限制：aws:RequestedRegion、aws:SourceIp、aws:PrincipalArn、aws:MultiFactorAuthPresent、标签条件，都会让允许变成拒绝。

判断原则很简单：只要某一层出现显式 Deny，后面的 Allow 全部失效。所以不要只看“角色有没有权限”，要看“整条调用链有没有任何一层拒绝”。

最常见的几种场景，通常不是同一个问题

容易被忽略的 Explicit Deny 来源

• 用了 Allow，但上层还有 Deny：很多人只搜“有没有放行”，没去搜整个策略栈里的 Deny。
• 默认版本不是当前版本：管理策略更新了，但生效的不是你以为的那个版本。
• 条件写得过严：例如只允许某个源 IP、某个 VPC Endpoint、某个 Region，换个出口就失败。
• KMS 单独限制：S3 本身允许了，但对象加密用的 KMS key 不放行，实际还是失败。
• 资源策略和身份策略不一致：角色上放了权限，但 bucket policy、queue policy、secret policy 不认这个主体。
• 把 Trust Policy 和 Permission Policy 混在一起看：能不能被扮演，是信任关系问题；扮演后能不能干活，是权限问题。两者不是一回事。

账号认证、支付风控、资源限制也会把问题“伪装成” Unauthorized

AWS海外版 如果你是在做 AWS 国际站账号开通、企业认证、统一采购、充值续费或付款方式更换，账号状态本身也要先排干净。很多企业排查 IAM Role 时，最后发现不是 role 出问题，而是账号侧状态不稳定。

• 实名认证/企业认证未完成：有些流程会卡在审核中，资源申请、付费开通、某些服务启用会受影响。
• 支付方式异常：信用卡拒付、账单失败、付款审核未过，可能导致账号进入受限状态。
• 风控审核中：新开账号、频繁切换主体、异地支付、短时间高频开资源，容易触发审核。
• AWS海外版 资源配额不足：EC2、EIP、NAT Gateway、VPC、KMS Key、S3 相关配额不够时，常见的是创建失败，不要误当成权限失败。
• 成本控制策略：企业为了控费会先在组织层做限制，结果测试环境和生产环境共用策略，导致你在开发时也被拦。

如果你是给海外业务做部署，建议先把账号底座处理好：企业认证、账单联系人、有效支付方式、区域选择、配额申请、风控审核材料，一次性确认。否则你会在 IAM、支付、配额、组织策略之间来回切，排查成本很高。

排查时最容易犯的几种错误

• 只看角色策略，不看 SCP、边界策略、资源策略。
• AWS海外版 只测试控制台，不测同一身份下的 CLI/API。
• 以为“有 Allow 就行”，忽略了别处的 Deny 优先级更高。
• 把 KMS、S3、Secrets Manager 这类资源级策略漏掉。
• 新账号还在风控或付款审核中，就直接开生产资源。
• 跨账号访问时，只配了信任关系，没配资源侧授权。
• 为了省钱把多个环境放在一个账号里，最后权限、账单、风控混在一起，定位更难。

什么情况下应该先处理账号，再处理权限

如果你遇到下面这些情况，建议先看账号状态，不要上来就改 IAM：

• 新开账号后一直创建不了资源，且同时伴随账单或验证提示。
• 支付方式刚改完，随后开始出现大量拒绝或服务限制。
• 企业认证、实名信息、税务信息未补齐。
• 账号刚被用于海外部署，随后触发风控审核。
• 同一套权限在测试账号可用，在生产账号不可用，而生产账号近期有付款或组织策略变动。

这种情况下，先确认账号可用、付款正常、审核通过，再查 role 才有效率。

实战排查建议：按这个顺序执行

1. 确认报错来源：控制台、CLI、SDK 还是自动化任务。
2. 确认实际身份：是不是你以为的那个 role/session。
3. 在 IAM Policy Simulator 里复现目标动作。
4. 全局搜 Deny：角色策略、边界、会话、SCP、资源策略、endpoint policy。
5. 核对条件：Region、IP、MFA、标签、时间窗口。
6. 检查资源依赖：S3 是否关联 KMS，是否存在 bucket policy 拒绝。
7. 回看最近变更：策略发布、组织策略、账号支付、认证状态、配额调整。

如果你只想最快定位，记住一句话：先确认是谁在调用，再找哪一层在拒绝，再看账号状态有没有被风控或限制。这个顺序基本能覆盖大多数 AWS IAM Role Unauthorized 问题。

FAQ

1. 已经给了 Allow，为什么还是报 Unauthorized？

因为 Allow 不是最终结果。只要任意一层存在显式 Deny，或者资源策略、SCP、边界策略、会话策略限制了动作，最终都会被拦。

2. CloudTrail 里只看到 AccessDenied，没看到 Deny，怎么办？

很多显式拒绝不会直接体现在你盯着的那一层策略里。继续查权限边界、SCP、资源策略和 KMS key policy，尤其是跨账号和加密场景。

3. AssumeRole 成功了，为什么后续操作还是失败？

通常是扮演成功但会话被限制了，或者目标资源侧还有单独策略。先查 session policy、permission boundary，再查资源 policy。

4. 新开的 AWS 国际账号，先做什么最稳？

先完成企业认证或实名信息、确认支付方式可用、检查是否在风控审核中，再申请所需配额。账号状态不稳时，权限排查会非常费时间。

5. 有没有一个最短路径能判断是不是 Explicit Deny？

有。先用同一身份做最小权限测试，再去 IAM Simulator 里跑同样动作；如果角色策略看起来放开了，就立刻查 SCP、边界、资源策略和 KMS。

如果你的场景是企业统一开通 AWS 账号、海外业务部署、跨账号资源访问，建议把“账号状态、支付可用性、组织策略、资源策略”一起看，而不是只盯着某一个 IAM Role。这样通常能更快决定是改权限、补认证，还是先处理账号侧限制。