IAMアイデンティティポリシー vs リソースベースポリシー — 評価と連携

2種類のポリシーの基本

AWSの認可には2種類のポリシーが存在する。

種類	誰に紐付く	Principalの記述
アイデンティティベースポリシー	IAMユーザー/ロール/グループ	不要（ポリシー所有者が主体）
リソースベースポリシー	AWSリソース（S3, KMS等）	必要（誰を許可するか明示）

リソースベースポリシーが使えるサービス（主要）

S3バケットポリシー / S3アクセスポイントポリシー
KMSキーポリシー
SQSキューポリシー
SNSトピックポリシー
Lambda関数ポリシー（リソースベース）
ECRリポジトリポリシー
Secretsmanagerシークレットポリシー
API Gatewayリソースポリシー
VPCエンドポイントポリシー
Glacier Vault Lock
EventBridgeリソースポリシー

注意: EC2インスタンス、ECS、DynamoDBテーブルにはリソースベースポリシーが存在しない。

同一アカウント内の評価ロジック

同一アカウント内:
IAMポリシー OR リソースポリシー のどちらかにAllowがあれば → アクセス許可
（明示的Denyがなければ）

例: IAMポリシーが s3:GetObject を許可しているが
    S3バケットポリシーがない場合 → アクセス許可

例: IAMポリシーがないが
    S3バケットポリシーが Principal:* で Allow している場合 → アクセス許可

// S3バケットポリシーで同一アカウントの全ユーザーに読み取り許可
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

クロスアカウントでの評価ロジック

クロスアカウント:
IAMポリシー AND リソースポリシー の両方にAllowが必要
（どちらか一方だけでは不十分）

この違いが試験で頻繁に出題される。

例外: KMSキーポリシー

KMSには特別なルールがある。KMSキーポリシーにはアカウントルートへのAllowが必須だ。キーポリシーにAllowがなければ、IAMポリシーだけではKMSキーを使えない。

// ❌ このキーポリシーではIAMポリシーでの制御が効かない
// （アカウントルートへのAllow記述がない場合）

// ✅ 正しいキーポリシー（アカウントルートへのAllow必須）
{
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    }
  ]
}
// → この記述があってはじめてIAMポリシーでKMSキーを制御できる

Lambda関数ポリシー（リソースベースポリシー）

Lambdaは両方のポリシーを持つ：

実行ロール（アイデンティティベース）: Lambdaが何にアクセスできるか
リソースベースポリシー: 誰がLambdaを呼び出せるか

# Lambda関数にS3からの呼び出し権限を付与（リソースベースポリシー）
aws lambda add-permission \
  --function-name my-function \
  --statement-id s3-trigger \
  --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::my-bucket \
  --source-account 123456789012

// 上記コマンドで生成されるLambdaリソースポリシー
{
  "Statement": [{
    "Sid": "s3-trigger",
    "Effect": "Allow",
    "Principal": {
      "Service": "s3.amazonaws.com"
    },
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:my-function",
    "Condition": {
      "ArnLike": {
        "AWS:SourceArn": "arn:aws:s3:::my-bucket"
      },
      "StringEquals": {
        "AWS:SourceAccount": "123456789012"
      }
    }
  }]
}

S3バケットポリシーの活用パターン

// パターン1: 特定のVPCエンドポイント以外からのアクセスを拒否
{
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::secure-bucket", "arn:aws:s3:::secure-bucket/*"],
    "Condition": {
      "StringNotEquals": {
        "aws:SourceVpce": "vpce-1234567890abcdef0"
      }
    }
  }]
}

// パターン2: HTTPSのみ許可（HTTP拒否）
{
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
    "Condition": {
      "Bool": {
        "aws:SecureTransport": "false"
      }
    }
  }]
}

試験頻出シナリオ

シナリオ	回答
同一アカウント、IAMポリシーのみAllow	アクセス可
同一アカウント、リソースポリシーのみAllow	アクセス可
クロスアカウント、一方のみAllow	アクセス不可
KMSキーポリシーにroot Allowなし	IAMポリシーあっても使えない
Lambdaにリソースポリシーなし	同一アカウントサービスからの呼び出しはIAMで制御

まとめ

同一アカウントはOR評価、クロスアカウントはAND評価
KMSだけは特殊でキーポリシーにroot Allow必須
Lambdaは「何ができるか（実行ロール）」と「誰が呼べるか（リソースポリシー）」の2本立て
DynamoDB/EC2にはリソースポリシーなし

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