IAMポリシー評価ロジック完全解説 — 明示的Deny・SCP・バウンダリーの優先順位

なぜポリシー評価を正確に理解する必要があるか

AWSの認可判定は「単一のポリシーを見るだけ」では済まない。IAMポリシー・リソースポリシー・SCP・パーミッションバウンダリーが同時に評価され、最終的にAllow/Denyが決まる。この評価順序を誤解すると、意図しない権限付与や予期せぬアクセス拒否が本番環境で発生する。SAA・SCS両試験でも最頻出トピックの一つだ。

評価順序（上から順に適用）

1. 明示的Deny（Explicit Deny） ← 最優先。どのポリシーにあっても勝つ
2. Organizations SCP           ← Organizations使用時のみ。通過しなければ拒否
3. リソースベースポリシー       ← S3バケットポリシー、KMSキーポリシーなど
4. パーミッションバウンダリー   ← IAMエンティティの権限上限
5. セッションポリシー           ← AssumeRole時に渡す追加制限
6. アイデンティティベースポリシー ← IAMユーザー/ロールのポリシー
7. （デフォルト）暗黙的Deny     ← 上記いずれのAllowもなければ拒否

明示的Denyの絶対性

// たとえ下記のAllowがあっても、Denyが一つでもあれば拒否される
{
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}
// 結果: s3:DeleteObject は拒否、それ以外のs3:*は許可

NotAction を使ったDenyには注意が必要だ。

// 危険パターン: 指定アクション以外すべてDeny
{
  "Effect": "Deny",
  "NotAction": ["s3:GetObject"],
  "Resource": "*"
}
// → s3:GetObject 以外の全AWSアクションがDenyされる（意図より広い）

クロスアカウントは双方向Allowが必須

同一アカウント内では、IAMポリシーまたはリソースポリシーのどちらか一方のAllowで十分だ（Denyがなければ）。しかしクロスアカウントアクセスでは両方のAllowが必要になる。

アカウントA（アクセス元）のIAMポリシー:
  → アカウントBのS3バケットへのAllow が必要

アカウントB（リソース所有）のS3バケットポリシー:
  → アカウントAへのAllow が必要

どちらか一方が欠けるとアクセス不可

// アカウントB側のS3バケットポリシー（クロスアカウント許可の例）
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:role/AppRole"
    },
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

パーミッションバウンダリーの役割

パーミッションバウンダリーは「使える権限の上限（ceiling）」を定義する。許可を付与するものではなく、上限を設けるものだ。

有効な権限 = アイデンティティポリシー ∩ パーミッションバウンダリー

例:
- アイデンティティポリシー: s3:*, ec2:*
- バウンダリー:             s3:*, rds:*
- 有効な権限:               s3:* のみ（積集合）

用途の典型例は「開発者が自分でIAMロールを作れるが、そのロールに自分以上の権限を付与できないようにする」場合だ。

// バウンダリー付きロール作成ポリシー（管理者が開発者に付与）
{
  "Effect": "Allow",
  "Action": "iam:CreateRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/DevBoundary"
    }
  }
}

SCPのポイント

SCPは管理アカウント（Management Account）には適用されない
SCPのDenyはroot含む全プリンシパルに有効
SCPはAllow設定だけでは権限を付与できない（IAMポリシーも必要）
デフォルトSCP「FullAWSAccess」が存在し、削除すると全サービス拒否になる

// SCP: 東京・大阪リージョン以外への操作を禁止
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1", "ap-northeast-3"]
    }
  }
}

試験頻出シナリオ早見表

シナリオ	結果
明示的Deny + Allow	Deny
Allowなし（ポリシー未設定）	暗黙的Deny（拒否）
SCP Deny + IAM Allow	Deny
バウンダリー外のAction + IAM Allow	Deny
同一アカウント: リソースポリシーAllow、IAMポリシーなし	Allow
クロスアカウント: 一方のみAllow	Deny
管理アカウントにSCP Deny	SCPは無効（管理アカウントは対象外）

まとめ

明示的Denyは絶対で上書き不可
クロスアカウントは双方向Allow必須
パーミッションバウンダリーは上限設定（付与ではない）
SCPは管理アカウント自身には効かない
NotAction + Denyの組み合わせは意図より広い制限になりやすい

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感