精通AWS IAM：有效排查访问被拒绝错误

AWS IAM的AccessDenied错误意味着AWS评估了您的请求，但未找到有效的权限路径。最快的修复方法不是猜测更宽泛的策略，而是确定AWS评估的确切操作、资源、主体和条件上下文。

大多数IAM故障来自以下四种情况之一：没有匹配的Allow、显式的Deny、限制身份的权限边界或服务控制策略，或者与请求不匹配的条件。

从IAM评估逻辑开始

AWS从默认拒绝开始。只有当适用策略允许且没有适用策略拒绝时，请求才会被允许。

显式的Deny会覆盖所有Allow。该拒绝可能来自身份策略、资源策略、权限边界、会话策略、服务控制策略或其他适用策略类型。

对于同账户访问，身份策略和资源策略通常协同工作。对于跨账户访问，通常需要在双方都有权限：调用者的身份必须被允许发出请求，目标资源或目标账户必须信任或允许该调用者。

捕获确切的失败请求

在编辑策略之前，请捕获以下详细信息：

主体：用户、角色、代入角色会话或AWS服务主体。
操作：API操作，例如s3:GetObject或ec2:RunInstances。
资源：ARN或资源ID。
区域和账户。
条件：源IP、VPC端点、MFA、标签、加密上下文或请求的区域。

CloudTrail通常是最好的来源。在错误发生时间附近搜索失败事件，并检查eventName、userIdentity、resources、errorCode和errorMessage。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

CloudTrail不会完美详细地解释每个授权决策，但它通常会提供缺失的操作和真实主体。仅此一项就能捕获许多代入角色和会话名称混淆的问题。

使用模拟和访问分析工具

IAM策略模拟器可以在更改生产权限之前测试许多基于身份的策略问题。选择用户或角色，选择服务操作，尽可能提供资源ARN，并包含相关条件键。

对于较新的AWS账户和服务，还可以检查访问被拒绝消息本身。某些服务会返回编码的授权失败消息。如果您有权限，可以使用STS解码：

aws sts decode-authorization-message \
  --encoded-message '<encoded-message-from-error>'

解码后的消息可以显示哪个策略类型导致了拒绝。

IAM Access Analyzer对于资源策略和跨账户问题很有用。它可以帮助您发现意外的外部访问，并在部署前验证某些策略。

检查每个策略层

基于身份的策略附加到用户、组和角色。它们定义了身份可以做什么。

基于资源的策略附加到资源，例如S3存储桶、KMS密钥、SQS队列、Lambda函数和角色信任策略。它们定义了谁可以使用该资源或代入该角色。

权限边界为用户或角色设置了最大权限。它们本身不授予访问权限。有效权限是身份策略和边界的交集。

AWS Organizations中的服务控制策略为账户或组织单位设置了最大权限。SCP本身也不授予访问权限。即使IAM策略允许，它们也可以阻止某个操作。

会话策略和权限标签也可以减少代入角色会话的访问权限。如果角色在一个路径中正常工作，但在被CI作业代入时失败，请比较会话策略、会话标签和信任策略条件。

常见的AccessDenied模式

缺少依赖操作

某些AWS操作需要比明显操作更多的权限。例如，启动加密的EC2实例可能需要EC2权限以及密钥的KMS权限。CloudTrail和服务文档是依赖操作的最佳参考。

错误的资源ARN

S3存储桶级别和对象级别的ARN不同：

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

arn:aws:s3:::my-bucket覆盖存储桶。arn:aws:s3:::my-bucket/*覆盖存储桶中的对象。许多S3错误来自于授予一个而API调用需要另一个。

条件不匹配

条件必须与请求上下文完全匹配。仅允许通过一个VPC端点访问的策略将拒绝来自另一个端点、公共AWS端点或不同区域的请求（如果条件检查了该区域）。

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-data",
    "arn:aws:s3:::my-sensitive-data/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

该语句拒绝HTTP请求，并允许HTTPS请求继续通过策略评估的其余部分。它本身不授予访问权限。

KMS密钥策略漏洞

KMS是导致混乱访问错误的常见来源。IAM策略可能允许kms:Decrypt，但密钥策略也必须直接允许主体，或允许账户通过IAM策略委派访问权限。

检查密钥策略、授权、加密上下文条件以及使用该密钥的服务。

实用的故障排查流程

首先，重现或捕获失败的调用。从CloudTrail获取确切的API操作和主体。

接下来，在SCP、资源策略、权限边界和身份策略中搜索显式拒绝。显式拒绝可以节省时间，因为它们会覆盖所有其他内容。

然后确认存在匹配的允许，用于确切的操作和资源。包括依赖操作和相关资源，例如KMS密钥、传递给服务的IAM角色、网络接口或日志组。

最后，使用尽可能窄的策略更改进行测试。避免使用Action: "*"或Resource: "*"来修复未知的拒绝；这会隐藏问题并带来新的安全风险。

有用的习惯是将每个AccessDenied视为证据问题。一旦您知道主体、操作、资源和策略层，修复通常很小且清晰。