🏢 オフィスビルのセキュリティで例えると超わかりやすい！
IAMの権限評価 = オフィスビルのセキュリティチェック
あなたがビルに入ろうとすると、複数のチェックポイントを通過する必要があります。
「入館証持ってる？」「この階に行く許可ある？」「今日は入れる日？」...
そして
操作経路
は「どの入口から入るか」の違い。
正面玄関（コンソール）
と
社員専用入口（API/CLI）
では
必要なチェック項目が微妙に違うんです！🚪
⚖️ 権限評価モデル - 3つの決定ルール
🏢
オフィスビルのセキュリティチェックで考えよう
あなたは社員で、オフィスビルの「機密資料室」に入りたいとします。
IAMの権限評価は、以下の3段階で決まります：
1️⃣ 「入るな」リスト（明示的拒否） に名前があれば → 即アウト！
2️⃣ リストになければ、 「入ってOK」リスト（明示的許可） を確認
3️⃣ どちらにも名前がなければ → デフォルトで拒否 （安全第一！）
💡 ポイント：「ダメ」と言われたら、どんな「OK」があっても入れない！
IAMの権限評価は、以下の3段階で決まります：
1️⃣ 「入るな」リスト（明示的拒否） に名前があれば → 即アウト！
2️⃣ リストになければ、 「入ってOK」リスト（明示的許可） を確認
3️⃣ どちらにも名前がなければ → デフォルトで拒否 （安全第一！）
💡 ポイント：「ダメ」と言われたら、どんな「OK」があっても入れない！
明示的拒否
(Explicit Deny)
(Explicit Deny)
ポリシーで「Deny」と明記されている。
「この人は絶対入れない」 と
ブラックリストに載っている状態。
他にどんな許可があっても
絶対に上書きできない！
「この人は絶対入れない」 と
ブラックリストに載っている状態。
他にどんな許可があっても
絶対に上書きできない！
👑 最優先（絶対）
明示的許可
(Explicit Allow)
(Explicit Allow)
ポリシーで「Allow」と明記されている。
「この人は入ってOK」 と
許可リストに載っている状態。
明示的拒否がなければ
アクセス許可される
「この人は入ってOK」 と
許可リストに載っている状態。
明示的拒否がなければ
アクセス許可される
🥈 2番目に確認
暗黙的拒否
(Implicit Deny)
(Implicit Deny)
どこにも書かれていない状態。
「リストに名前がない」 ので
デフォルトで入れない。
AWSは 「許可されていなければ拒否」 が基本原則
「リストに名前がない」 ので
デフォルトで入れない。
AWSは 「許可されていなければ拒否」 が基本原則
🔰 デフォルト動作
📋 権限評価の完全フロー
1
🚫
明示的拒否をチェック
まず最初に「Deny」が書かれているポリシーがないか確認。
SCP、アイデンティティポリシー、リソースポリシー、Permission Boundary... どこかに「Deny」があれば即終了！
SCP、アイデンティティポリシー、リソースポリシー、Permission Boundary... どこかに「Deny」があれば即終了！
🏢 例：「田中さんは機密室への入室を禁止する」と書かれていたら、他に何が書いてあっても入れない
Denyあり → 即拒否！🚫
2
🏛️
SCP（組織ポリシー）をチェック
AWS Organizationsの
サービスコントロールポリシー
を確認。
「このアカウント全体でこの操作を許可するか？」を決める組織のルール。
「このアカウント全体でこの操作を許可するか？」を決める組織のルール。
🏢 例：「このフロア全体で、夜間の入室は禁止」という全社ルール
Allowあり → 次へ進む ➡️
3
👤
アイデンティティポリシーをチェック
IAMユーザー/ロール/グループに付与された
ユーザーベースのポリシー
を確認。
「この人は何ができるか？」を定義したもの。
「この人は何ができるか？」を定義したもの。
🏢 例：「田中さんの社員証には、会議室A〜Cへの入室権限がある」
Allowあり → 次へ進む ➡️
4
📦
リソースポリシーをチェック
S3バケットポリシーやKMSキーポリシーなど、
リソース側に設定されたポリシー
を確認。
「このリソースに誰がアクセスできるか？」を定義。
「このリソースに誰がアクセスできるか？」を定義。
🏢 例：「機密資料室のドアには、セキュリティ部門のみ入室可能」と書いてある
Allowあり → 次へ進む ➡️
5
🔒
Permission Boundaryをチェック
IAMユーザー/ロールに設定された
権限の上限
を確認。
「この人ができる最大範囲はここまで」という天井を設定。
「この人ができる最大範囲はここまで」という天井を設定。
🏢 例：「田中さんは開発部所属なので、どんな許可があっても人事エリアには入れない」
すべてOK → アクセス許可！✅
🚪 操作経路の違い - コンソール vs API/CLI
🏢
オフィスビルの「入口」で考えよう
同じオフィスビルでも、入口によって体験が違います：
🚪 正面玄関（コンソール）
→ 受付があり、案内板があり、エレベーターまで誘導してくれる
→ 便利だけど、受付を通過するための「追加の確認」が必要なことも
🔑 社員専用入口（API/CLI）
→ 社員証をピッとかざして直接入室
→ シンプルで速いけど、どこに何があるか自分で把握している必要がある
🚪 正面玄関（コンソール）
→ 受付があり、案内板があり、エレベーターまで誘導してくれる
→ 便利だけど、受付を通過するための「追加の確認」が必要なことも
🔑 社員専用入口（API/CLI）
→ 社員証をピッとかざして直接入室
→ シンプルで速いけど、どこに何があるか自分で把握している必要がある
AWS Management Console
Webブラウザからの操作
🔍
裏で複数のAPIを呼び出す
画面を開くだけで、一覧表示のために
つまり 表示するだけで追加の権限が必要 になることがある。
List*
や
Describe*
APIが自動で呼ばれる。
つまり 表示するだけで追加の権限が必要 になることがある。
📋
一覧表示の権限が必要
例：S3コンソールでバケット一覧を見るには
バケット操作はできても一覧が見えない ケースも。
s3:ListAllMyBuckets
権限が必要。
バケット操作はできても一覧が見えない ケースも。
👀
視覚的に分かりやすい
GUIで操作できるため、初心者に優しい。
エラーメッセージも分かりやすく表示される。
ただし 権限エラーが分かりにくい こともある。
エラーメッセージも分かりやすく表示される。
ただし 権限エラーが分かりにくい こともある。
⚠️
注意点
「アクセス拒否」と表示されても、
実は 一覧表示の権限が足りないだけ のことがある。
直接URLでアクセスすると動くことも！
実は 一覧表示の権限が足りないだけ のことがある。
直接URLでアクセスすると動くことも！
API / CLI
プログラムからの直接操作
🎯
必要なAPIだけを呼び出す
コマンドを実行すると、そのAPIだけが呼ばれる。
余計な権限は不要 で、最小権限の原則を守りやすい。
余計な権限は不要 で、最小権限の原則を守りやすい。
🔧
一覧なしでも操作可能
例：
ファイルダウンロードが可能。
バケット一覧が見えなくても直接操作できる 。
s3:GetObject
権限だけで
ファイルダウンロードが可能。
バケット一覧が見えなくても直接操作できる 。
📊
詳細なエラー情報
どのAPIでどんなエラーが出たか明確に分かる。
トラブルシューティングがしやすい。
トラブルシューティングがしやすい。
--debug
オプションで詳細表示も可能。
🚀
自動化に最適
スクリプトやCI/CDパイプラインで利用。
必要最小限の権限 で自動処理を実行できる。
セキュリティ的にも望ましい。
必要最小限の権限 で自動処理を実行できる。
セキュリティ的にも望ましい。
📊 コンソール vs API/CLI 詳細比較
| 項目 | 🖥️ コンソール | ⌨️ API/CLI |
|---|---|---|
| 操作方法 | ブラウザでGUI操作 | コマンドやコードで実行 |
| 必要な権限 | 操作権限 + 表示権限（List/Describe） | 操作権限のみでOK |
| 権限エラーの分かりやすさ | ⚠️ 原因が分かりにくいことがある | ✅ 詳細なエラー情報 |
| 最小権限の原則 | ⚠️ 追加権限が必要になりがち | ✅ 守りやすい |
| 学習コスト | ✅ 直感的で低い | ⚠️ コマンド習得が必要 |
| 自動化 | ❌ 困難 | ✅ 最適 |
| 監査ログの明確さ | ⚠️ 複数APIが混在 | ✅ 明確 |
| 向いている用途 | 探索・確認・学習 | 本番運用・自動化・セキュリティ重視 |
💡 よくある「あれ？」を解決！実例集
コンソールで「アクセス拒否」なのにCLIでは動く！
📋 シナリオ
S3バケットにファイルをアップロードしたい。
CLIでは
コンソールでは「アクセスが拒否されました」と表示される。
CLIでは
aws s3 cp
が成功するのに、
コンソールでは「アクセスが拒否されました」と表示される。
✅ 原因と解決策
原因：
コンソールはバケット一覧を表示するために
「アクセス拒否」と表示されてしまう。
解決策：
①
② または直接URLでバケットにアクセス
s3:ListBucket
権限がない
コンソールはバケット一覧を表示するために
s3:ListBucket
を呼ぶが、その権限がないと
「アクセス拒否」と表示されてしまう。
解決策：
①
s3:ListBucket
権限を追加
② または直接URLでバケットにアクセス
「Allow」があるのに拒否される！
📋 シナリオ
IAMポリシーで
操作しようとすると「AccessDenied」エラーが出る。
"Effect": "Allow"
を設定したのに、
操作しようとすると「AccessDenied」エラーが出る。
✅ 確認ポイント
① 明示的拒否がないか？
SCP、Permission Boundary、他のポリシーに「Deny」がないか確認
② リソースポリシーは？
S3バケットポリシーやKMSキーポリシーで拒否されていないか
③ 条件（Condition）は？
IPアドレス制限やMFA必須などの条件を満たしているか
④ リソースARNは正しいか？
ワイルドカード（*）の位置や形式を確認
SCP、Permission Boundary、他のポリシーに「Deny」がないか確認
② リソースポリシーは？
S3バケットポリシーやKMSキーポリシーで拒否されていないか
③ 条件（Condition）は？
IPアドレス制限やMFA必須などの条件を満たしているか
④ リソースARNは正しいか？
ワイルドカード（*）の位置や形式を確認
クロスアカウントアクセスが動かない！
📋 シナリオ
アカウントAからアカウントBのS3バケットにアクセスしたい。
アカウントAのIAMポリシーで許可したのに動かない。
アカウントAのIAMポリシーで許可したのに動かない。
✅ 原因と解決策
クロスアカウントアクセスは「両方の許可」が必要！
① アカウントA側： IAMポリシーでAllow
② アカウントB側： バケットポリシーでAllow
どちらか一方だけでは動きません！
両方のアカウントで許可を設定する必要があります。
① アカウントA側： IAMポリシーでAllow
② アカウントB側： バケットポリシーでAllow
どちらか一方だけでは動きません！
両方のアカウントで許可を設定する必要があります。
さっきまで動いてたのに急に動かない！
📋 シナリオ
昨日まで普通に使えていたのに、
今日になって急に「AccessDenied」になった。
今日になって急に「AccessDenied」になった。
✅ 確認ポイント
① SCPの変更
Organizations管理者がSCPを更新していないか
② Permission Boundaryの変更
上限設定が変更されていないか
③ 条件付きポリシーの期限
日時条件やセッション期限が切れていないか
④ リソースポリシーの変更
S3バケットポリシー等が変更されていないか
Organizations管理者がSCPを更新していないか
② Permission Boundaryの変更
上限設定が変更されていないか
③ 条件付きポリシーの期限
日時条件やセッション期限が切れていないか
④ リソースポリシーの変更
S3バケットポリシー等が変更されていないか
⚠️
よくある間違い - これだけは避けよう！
❌ 間違い1：「コンソールで動くからCLIでも動くはず」
→ 逆は成り立ちますが、コンソールには追加権限が必要なことがある
❌ 間違い2：「Allowを追加すればDenyを上書きできる」
→ 明示的拒否（Deny）は絶対に上書きできません！
❌ 間違い3：「権限エラー = IAMポリシーの問題」
→ SCP、Permission Boundary、リソースポリシーも確認が必要
❌ 間違い4：「管理者なら何でもできる」
→ SCPやPermission Boundaryで制限されている可能性あり
→ 逆は成り立ちますが、コンソールには追加権限が必要なことがある
❌ 間違い2：「Allowを追加すればDenyを上書きできる」
→ 明示的拒否（Deny）は絶対に上書きできません！
❌ 間違い3：「権限エラー = IAMポリシーの問題」
→ SCP、Permission Boundary、リソースポリシーも確認が必要
❌ 間違い4：「管理者なら何でもできる」
→ SCPやPermission Boundaryで制限されている可能性あり
💡
権限トラブルシューティングの黄金ルール
1. IAM Policy Simulatorを使う：
AWSコンソールの「IAM Policy Simulator」で権限をテストできる。本番環境を触る前に確認！
2. CloudTrailでAPIコールを確認：
どのAPIが呼ばれて、どこで失敗したかを確認。コンソール操作も全てAPIコールとして記録される。
3. 最小権限から始める：
まずCLIで必要な操作ができるか確認 → 動いたらコンソール用の権限を追加検討
4. 「誰が」「何を」「どこで」を明確に：
Principal（誰）、Action（何）、Resource（どこ）を常に意識してポリシーを書く
5. 評価順序を覚える：
明示的拒否 → SCP → アイデンティティポリシー → リソースポリシー → Permission Boundary
この順序で「どこで止まったか」を追跡する
AWSコンソールの「IAM Policy Simulator」で権限をテストできる。本番環境を触る前に確認！
2. CloudTrailでAPIコールを確認：
どのAPIが呼ばれて、どこで失敗したかを確認。コンソール操作も全てAPIコールとして記録される。
3. 最小権限から始める：
まずCLIで必要な操作ができるか確認 → 動いたらコンソール用の権限を追加検討
4. 「誰が」「何を」「どこで」を明確に：
Principal（誰）、Action（何）、Resource（どこ）を常に意識してポリシーを書く
5. 評価順序を覚える：
明示的拒否 → SCP → アイデンティティポリシー → リソースポリシー → Permission Boundary
この順序で「どこで止まったか」を追跡する
❓ よくある質問
🙋
Q. コンソールとCLIで同じIAMユーザーを使っているのに、権限が違うのはなぜ？
A.
コンソールは画面を表示するために追加のAPIを呼び出します。
例えば、EC2コンソールを開くだけで
CLIで特定の操作だけ許可している場合、コンソールでは「一覧が見えない」という形で権限不足が現れます。
例えば、EC2コンソールを開くだけで
ec2:DescribeInstances
が呼ばれます。
CLIで特定の操作だけ許可している場合、コンソールでは「一覧が見えない」という形で権限不足が現れます。
🙋
Q. 明示的拒否（Deny）と暗黙的拒否の違いは何ですか？
A.
明示的拒否
：ポリシーに「Deny」と書かれている。
絶対に上書きできない
。
暗黙的拒否 ：どこにも書かれていない状態。 Allowを追加すれば許可される 。
つまり「何も書いてない = 拒否」がデフォルトですが、「Denyと書いてある = 永久に拒否」です。
暗黙的拒否 ：どこにも書かれていない状態。 Allowを追加すれば許可される 。
つまり「何も書いてない = 拒否」がデフォルトですが、「Denyと書いてある = 永久に拒否」です。
🙋
Q. Permission Boundaryとは何ですか？SCPとの違いは？
A.
どちらも「権限の上限」を設定するものですが、適用範囲が違います：
SCP ：Organizations全体・OU・アカウント単位で適用
Permission Boundary ：個別のIAMユーザー・ロール単位で適用
SCPは「会社全体のルール」、Permission Boundaryは「個人への制限」と考えると分かりやすいです。
SCP ：Organizations全体・OU・アカウント単位で適用
Permission Boundary ：個別のIAMユーザー・ロール単位で適用
SCPは「会社全体のルール」、Permission Boundaryは「個人への制限」と考えると分かりやすいです。
🙋
Q. 権限エラーのデバッグで最初にすべきことは？
A.
まず以下を確認してください：
① IAM Policy Simulator でポリシーをテスト
② CloudTrail で失敗したAPIコールを確認（errorCodeとerrorMessageをチェック）
③ CLI --debug オプションで詳細なエラー情報を取得
これで「どのAPIで」「どんな理由で」失敗したかが分かります。
① IAM Policy Simulator でポリシーをテスト
② CloudTrail で失敗したAPIコールを確認（errorCodeとerrorMessageをチェック）
③ CLI --debug オプションで詳細なエラー情報を取得
これで「どのAPIで」「どんな理由で」失敗したかが分かります。
🎓 まとめ
🏢 オフィスビルのセキュリティ = IAM権限評価
複数のチェックポイントを通過して初めてアクセスできる
一つでも「拒否」があれば入れない仕組みです
🚫
明示的拒否
「Deny」は絶対
どんなAllowも
上書き不可
✅
明示的許可
「Allow」があり
Denyがなければ
アクセス可能
🔒
暗黙的拒否
何も書いてない
= デフォルトで
アクセス拒否
🖥️
コンソール
操作権限 ＋表示権限 が必要
List/Describeも忘れずに！
⌨️
API/CLI
必要な権限だけ でOK
最小権限の原則を守りやすい
🎯
権限エラーが出たら...
① まずCLIで試す（コンソール特有の問題か確認）
② IAM Policy Simulatorでテスト
③ CloudTrailでAPIエラーを確認
④ SCP・Permission Boundary・リソースポリシーも忘れずに！🔍