🪣🔐

S3バケットポリシー Principal要素

IAMグループとの重要な関係を図解で完全理解

🎯 最初に覚える最重要ポイント
S3バケットポリシーの Principal には
IAMグループを直接指定できません！
指定できるもの： IAMユーザー、IAMロール、AWSアカウント、AWSサービス、匿名ユーザー（*）
指定できないもの： IAMグループ ← これが最大の落とし穴！

🏢
たとえ話で理解する「Principalとグループの関係」

S3バケットポリシーを「オフィスビルのセキュリティゲート」に例えて説明します

🪣
S3バケット
= AWSのストレージ
📦 オフィスビル のようなもの。
重要な書類（データ）が保管されている場所。誰でも入れるわけではない。
📋
バケットポリシー
= アクセス許可ルール
🚨 セキュリティゲートのルール のようなもの。
「誰が」「何を」「どこで」できるかを決める公式ルール。
🎫
Principal要素
= 「誰に」許可するか
👤 入館許可リスト のようなもの。
ゲートに「この人は通していい」と登録される名前。
👥
IAMグループ
= ユーザーの集まり
🏷️ 部署ラベル のようなもの。
「営業部」「開発チーム」などの分類。
⚠️ ゲートは個人IDしか認識しない！

🔍 なぜIAMグループをPrincipalに指定できないのか？

📦 S3バケット（オフィスビル）
🚨 セキュリティゲート
（バケットポリシー）
✅ 山田太郎さん（IAMユーザー）
✅ システム管理者役（IAMロール）
✅ 取引先A社（AWSアカウント）
❌ 開発チーム（グループ名）
⚠️ ゲートの仕様
個人ID（ユーザー/ロール）のみ認識
部署名（グループ）は認識できない

「開発チーム」グループに所属するメンバーたち

👨‍💻
鈴木さん
入れない
👩‍💻
田中さん
入れない
🧑‍💻
佐藤さん
入れない

😢 グループ名で許可しても、メンバーは誰も入れない！

📝
Principal に指定できるもの・できないもの

👤
IAMユーザー
✅ 指定可能

個人のAWSアカウントユーザー。社員証を持った個人のようなもの。

"Principal": {
"AWS": "arn:aws:iam::123456789012:user/yamada"
}
🎭
IAMロール
✅ 指定可能

一時的に引き受けられる役割。「システム管理者」という腕章のようなもの。

"Principal": {
"AWS": "arn:aws:iam::123456789012:role/AdminRole"
}
🏢
AWSアカウント
✅ 指定可能

アカウント全体を許可。取引先企業全体に許可を出すようなもの。

"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
}
⚙️
AWSサービス
✅ 指定可能

CloudFrontやLambdaなど。ビル管理システムのようなもの。

"Principal": {
"Service": "cloudfront.amazonaws.com"
}
🌍
匿名ユーザー（*）
✅ 指定可能

誰でもアクセス可能に。一般公開の受付ロビーのようなもの。

"Principal": "*"
👥
IAMグループ
❌ 指定不可

バケットポリシーでは使えません！
グループはIAMポリシー内でのみ使用可能。

// ❌ これはエラーになる
"Principal": {
"AWS": "arn:aws:iam::123456789012:group/Developers"
}

🤔
なぜAWSはこの設計にしたのか？

👥
IAMグループ
→
🔄
メンバーは
変動する
→
📊
アクセス評価が
複雑に
✕

💡 AWSの設計思想

  • 1️⃣ シンプルさの追求： リソースポリシー（バケットポリシー）は「リソース側から見て誰がアクセスするか」を明確にする
  • 2️⃣ パフォーマンス： グループメンバーシップを毎回チェックするとアクセス評価が遅くなる
  • 3️⃣ 責任の分離： IAMポリシー（アイデンティティ側）とリソースポリシー（リソース側）の役割を分ける

💡
グループのメンバーにアクセスを許可する方法

1
🎭 IAMロールを使う（推奨）
グループメンバーが共通のロールを引き受ける（AssumeRole）設計に変更。バケットポリシーにはロールを指定。
// バケットポリシー
{
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/DevelopersRole"
},
"Action": "s3:GetObject",
"Effect": "Allow"
}
2
📋 IAMポリシーをグループに付与
バケットポリシーではなく、IAMグループに直接S3アクセス権限を持つポリシーをアタッチする。
// グループにアタッチするIAMポリシー
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
3
🏢 AWSアカウント全体を許可
同一アカウント内の場合、アカウントルートを許可し、IAM側で細かく制御する。
// バケットポリシー
{
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "s3:*",
"Effect": "Allow"
}

📊
バケットポリシー vs IAMポリシー 比較

項目 バケットポリシー IAMポリシー
付与先 S3バケット（リソース） ユーザー/グループ/ロール
IAMユーザー指定 ✅ ✅
IAMロール指定 ✅ ✅
IAMグループ指定 ❌ ✅
クロスアカウント ✅ 必須 ❌ 単独では不可
匿名アクセス ✅ ❌
管理場所 S3バケット IAMコンソール

⚠️
よくある間違いと正しい対処法

❌ 間違い：グループARNをPrincipalに指定
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:group/Developers" // ❌ エラー！
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}]
}
✅ 正解：ロールを使って許可
// ステップ1: バケットポリシーでロールを許可
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/DevelopersRole" // ✅ OK！
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}]
}

// ステップ2: グループにロール引き受け権限を付与（IAMポリシー）
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/DevelopersRole"
}

🏆
ベストプラクティス

🎭

グループアクセスにはロールを使う

複数ユーザーへの一括許可が必要な場合、共通のIAMロールを作成し、そのロールをPrincipalに指定します。メンバー変更時もロールの設定変更不要。

🔒

最小権限の原則を守る

Principalに「*」を使う場合は、Conditionで接続元IPやVPCエンドポイントを制限するなど、追加の制約を必ず設定しましょう。

📍

同一アカウント内はIAMポリシーを優先

同じAWSアカウント内のアクセス制御は、バケットポリシーよりIAMポリシー（グループ経由）の方が管理しやすいケースが多いです。

🌐

クロスアカウントはバケットポリシー必須

他のAWSアカウントからのアクセスを許可する場合は、バケットポリシーでのPrincipal指定が必要です。IAMポリシーだけでは不可。

📝 まとめ

🎫
Principal = 「誰に」
アクセスを許可/拒否する対象を指定する要素
❌
グループは指定不可
IAMグループはバケットポリシーのPrincipalには使えない
🎭
解決策はロール
グループメンバーに一括許可したいならIAMロールを活用
📋
IAMポリシーも選択肢
同一アカウント内ならグループにIAMポリシーをアタッチ

Created by SSuzuki1063

AWS SAP Learning Resources