IAMポリシーで許可したのにアクセスできない？権限エラーを解消する方法

はじめに
1. AWSポリシーの評価の基本原則
2. トラブル事例と解説
まとめ

はじめに

AWSを利用していると、「ポリシーでAllowを設定したのにアクセスが拒否される」といったトラブルに直面することはありませんか？

特に初心者にとって、AWSのポリシーがどのように評価されるのか理解するのは難しいのではないでしょうか？

本記事では、AWSのIAMポリシーにおけるAllowとDenyの優先順位について詳しく解説し、混乱を招きやすいトラブル事例を取り上げて、その原因と解決策を分かりやすく説明します。

1. AWSポリシーの評価の基本原則

AWS IAMのポリシー評価は、以下の基本原則に基づいて行われます。

明示的なDenyが最優先される
どのポリシーにおいても、明示的にDenyが記述されている場合、それが優先されます。
明示的なAllowが次に評価される
Denyが記述されていない場合、明示的なAllowが適用されます。
デフォルトはすべてDeny
IAMポリシーで許可されていない操作はすべて拒否されます。

これを踏まえると、「Allowを設定したのにアクセスできない」原因は主に以下の4つに分類できます。

事例1: IAMポリシー内でAllowとDenyが混在している
事例2: 明示的なDenyが存在する
事例3: 条件付きAllowが満たされていない
事例4: SCP（Service Control Policy）が原因

2. トラブル事例と解説

事例1: IAMポリシー内でAllowとDenyが混在している

状況: EC2インスタンスの操作を許可するIAMポリシーを設定したが、一部のアクションが拒否される。

原因: IAMポリシー内で特定のアクションに対して明示的にDenyが設定されている。IAMポリシー内でAllowされている場合でも、Denyが優先されるため、アクセスが拒否される。

解決策:

1. IAMポリシーを確認し、Denyの条件を見直す。
1. 必要に応じて、Denyを削除または条件を調整する。

例: 以下のIAMポリシーでは、EC2インスタンスのStartInstancesとStopInstancesは許可されていますが、TerminateInstancesは明示的に拒否されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*"
    },
    {
      "Effect": "Deny",
      "Action": "ec2:TerminateInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*"
    }
  ]
}

この場合、TerminateInstancesアクションを実行しようとすると、Denyが優先されてアクセスが拒否されます。アクセスを許可する場合は、ポリシーからDenyステートメントを削除する必要があります。

事例2: 明示的なDenyが存在する

状況: S3バケットのアクセスを許可するポリシーをIAMユーザーに割り当てたが、アクセス権がないとエラーが発生する。

原因: IAMポリシーではAllowされているが、リソースポリシーで特定のアクションやIPアドレスに対してDenyが設定されている。

解決策:

1. 該当のS3バケットポリシーを確認する。
1. Denyの記述を削除するか、許可したい条件を調整する。

例: 以下のバケットポリシーが問題の原因となる可能性があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

事例3: 条件付きAllowが満たされていない

状況: EC2インスタンスに対する操作を許可したポリシーを割り当てたが、一部の操作が拒否される。

原因: Allowポリシーに条件(Condition)が設定されており、リクエストがその条件を満たしていない。

解決策:

1. IAMポリシーのConditionを確認する。
1. 条件を満たすためにリクエストを調整する。

例: 以下のIAMポリシーでは、特定のタグが付いたリソースにのみ操作が許可されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:StopInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "Development"
        }
      }
    }
  ]
}

リクエストの対象インスタンスにEnvironment=Developmentのタグが設定されていない場合、操作は拒否されます。

事例4: SCP（Service Control Policy）が原因

状況: AWS Organizationsを使用している場合に、特定のアクションが許可されていない。

原因: SCPによって管理アカウントが明示的にDenyを設定している。

解決策:

1. SCPを確認して、該当するアクションがAllowされていることを確認する。
1. 必要に応じて、SCPの変更をリクエストする。

例: 以下のSCPでは、iam:*の操作が明示的に拒否されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

この場合、IAMユーザーに許可を設定しても、SCPによりアクセスが拒否されます。

まとめ

AWSのポリシーは柔軟で強力ですが、複数のポリシーが絡み合うことで混乱が生じやすい側面もあります。

特に、AllowとDenyの優先順位に注意しながら、IAMポリシーやリソースポリシーを設計することが重要です。

本記事の事例と解説を参考に、トラブル時に迅速かつ的確に原因を特定できるようになりましょう！