AWS IAMポリシーとS3バケットポリシーの違い

IAMポリシーとS3バケットポリシーの違いのまとめ

	適用場所	管理主体	優先度
IAMポリシー	IAMユーザー/グループ/ロールに設定	ユーザー側（誰が何をできるか）	デフォルト拒否。IAMポリシーにAllowがないと不可
S3バケットポリシー	S3バケット（リソース側）に設定	リソース側（このバケットに誰がアクセスできるか）	リソースポリシーでDenyがあればIAMのAllowより優先して拒否される

IAMポリシーとは

ユーザー / グループ / ロールに「どんな操作が許されるか」を定義するルール集です。
形式は JSON ドキュメントで記述されます。

IAMポリシーの構成

Version	ポリシー言語のバージョン。通常 "2012-10-17" を使用します。
Statement	実際のルールの定義。1つ以上の文（ステートメント）を持つことができます。

Statement(ステートメント)の中身

Effect	Allow または Deny（許可か拒否か）
Action	許可/拒否する操作（例: "s3:PutObject", "ec2:StartInstances"）
Resource	操作対象のリソース（ARNで指定）
Condition	特定の条件下でのみ適用する場合の制約（例: IPアドレス、時刻、MFA認証など）

IAMポリシーの例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

効果 (Effect) → 許可

操作 (Action) → s3:GetObject（S3のオブジェクト取得）

対象 (Resource) → example-bucket 配下のすべてのオブジェクト

仕様

デフォルト拒否: 何も許可されていない状態からスタート

明示的な許可が必要: Allowがないと操作不可

明示的な拒否が最優先: どんなAllowがあっても、Denyがあれば拒否される

S3バケットポリシーとは

S3バケットに直接追加するするポリシーです。

JSON形式で記述し、誰（Principal）がバケットやオブジェクトに対して、どの操作（Action）を、どの条件でできるかを制御します。

クロスアカウントアクセスや匿名アクセス（インターネット公開）を許可したいときによく使います。

S3バケットポリシーの例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ExampleStatement01",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-bucket/*"],
      "Condition": {
        "IpAddress": {"aws:SourceIp": "203.0.113.25/32"}
      }
    }
  ]
}

Version: ポリシー言語のバージョン（通常 "2012-10-17"）

Statement: ルールのかたまり

Effect: Allow または Deny

Principal: 許可対象（ユーザー、ロール、アカウント、*=全員）

Action: 実行可能な操作（例: "s3:GetObject", "s3:PutObject"）

Resource: バケットやオブジェクトをARNで指定

Condition: 条件（例: IP制限、TLS必須、特定VPCエンドポイントなど）

評価方法

上から順に評価するわけではありません。
すべてのステートメントを評価します。Denyがあれば拒否されます。

DenyとNotの組み合わせ

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

NotIpAddressを使って、許可したい範囲以外はすべて拒否する例です。

注意点

DenyはAllowより優先されるため、一度マッチすると絶対に拒否されます。

Not系は強力すぎる指定になりやすいです。

Deny + Not を使う場合は「すべてのユーザーがアクセスできなくなる」状況を作り、IAM管理者自身も閉め出される可能性があるので注意が必要です。

ベストプラクティス

Allowを基本にして必要最小限で許可します（最小権限の原則）。

Deny+Notは「例外を拒否する」「特定条件外を締め出す」など明確なセキュリティ制約が必要な場合のみ使用します。