IAM ポリシーを付けたのに、コマンドを打つと AccessDenied が返ってくる。Allow を書いたはずなのに通らない。逆に、何も書いていないのにバケットが読めてしまう。IAM を学び始めた人が最初に詰まるのは、ポリシーの書き方よりも「結局、許可されるのか拒否されるのか」の決まり方です。
ポリシーの評価は、1回のリクエストごとに、関係するポリシーを全部集めて判定する作業です。判定の規則は3つしかなく、順番も決まっています。この記事では、その3つの規則と、ポリシーの2つの置き場所（人の側・リソースの側）がどう重なるかを、門のたとえで整理します。最後に、その規則を前提に最小権限をどう作るかを扱います。
この記事の結論
- IAM の既定は拒否で、どのポリシーにも Allow が無い操作は、Deny が無くても通りません（暗黙の拒否）。
- どこかのポリシーに当てはまる Deny が1つでもあれば、ほかにいくつ Allow があっても拒否されます（明示的な拒否が優先）。
- 同じアカウントの中では、人に付けるポリシーとリソースに付けるポリシーのどちらかに Allow があれば許可されます。
- 別アカウントからの操作は、呼ぶ側と呼ばれる側の両方のアカウントで許可されていないと通りません。
- SCP や権限境界は許可を与えず上限だけを決めるので、最小権限は「必要な Allow だけを書き、上限で外枠を引く」形で作ります。
IAM ポリシーの評価とは何か
AWS への操作は、すべて API のリクエストです。コンソールのボタンも CLI のコマンドも、裏では「誰が（プリンシパル）・どの操作を（アクション）・どのリソースに」というリクエストになって AWS に届きます。AWS はそのたびに、そのリクエストに関係するポリシーを集めて、許可か拒否かを決めます。これがポリシーの評価です。
評価に集められるポリシーは、大きく次の種類があります。
| 種類 | どこに付けるか | 役割 |
|---|---|---|
| アイデンティティベースのポリシー | IAM ユーザー・グループ・ロール | その人・ロールに「何をしてよいか」を許可する |
| リソースベースのポリシー | S3 バケット・KMS キー・SQS キューなど | そのリソースを「誰が使ってよいか」を許可する |
| SCP（サービスコントロールポリシー） | AWS Organizations のアカウント・組織単位 | アカウント全体で許可できる範囲の上限を決める |
| 権限境界（permissions boundary） | IAM ユーザー・ロール | その人・ロールに許可できる範囲の上限を決める |
| セッションポリシー | ロールを引き受けるときの一時的なセッション | そのセッションだけ範囲を絞る |
未経験のうちは、上の2つ（アイデンティティベースとリソースベース）を押さえれば、日常で出会う AccessDenied の大半は説明できます。下の3つは「許可を与えるもの」ではなく「上限を引くもの」とだけ覚えておけば、後の章で迷いません。
READ ALSO — 学習中向け・段1 入口
IAM とは何か｜ユーザー・ロール・ポリシーを「誰が・何に・何をしてよいか」で読み解く
許可と拒否はどの順で決まるのか
評価の規則は3つです。IAM ユーザーガイドの「ポリシーの評価論理」に書かれている内容を、未経験の人が読める形に直すと次のようになります。
規則1: 何も書かれていなければ拒否（暗黙の拒否）
IAM の出発点は「すべての操作を拒否」です。ルートユーザー以外のプリンシパルは、明示的に許可されない限り何もできません。Allow が1つも当たらなかったリクエストは、Deny が書かれていなくても拒否されます。これを暗黙の拒否と呼びます。
「禁止と書いていないのに、なぜ通らないのか」という疑問の答えがこれです。IAM は「書いていないことはしてよい」ではなく「書いたことだけしてよい」の仕組みです。
規則2: 当てはまる Allow があれば、許可の候補になる
ポリシーの中に、リクエストのアクションとリソース（と条件）に当てはまる Allow があれば、暗黙の拒否は上書きされます。ただし、この時点ではまだ「候補」です。
規則3: 当てはまる Deny が1つでもあれば、拒否で確定（明示的な拒否）
関係するポリシーのどれか1つに、当てはまる Deny があれば、ほかにいくつ Allow があっても拒否されます。明示的な拒否は、明示的な許可より強い。これが IAM の評価でいちばん大事な規則です。
WHICH REQUESTS PASS5つのリクエスト
Deny が1つでも当たれば止まり、Allow が無ければ黙って止まる
IAM の評価（既定は拒否）
- Allow人のポリシーに Allow 通る同じアカウントのユーザー
- Allowバケットポリシーに Allow 通る同じアカウント。人の側は空
- DenyAllow と Deny の両方 止まるどこかに Deny が1つ
- None何も書かれていない 止まる暗黙の拒否
- Cross別アカウントで片側だけ Allow 止まる両側の許可が要る
3つを1本の順番に並べると、「Deny が当たるか → Allow が当たるか → どちらも無ければ拒否」です。先に Deny を探し、見つかればそこで終わる、と覚えておけば、Allow と Deny が混ざったポリシーも読めます。
この規則が便利なのは、「どうしても止めたいもの」を Deny で書いておけば、あとから誰かが広い Allow を足しても止まり続けることです。逆に言えば、Deny は強すぎるので、広く書くと必要な操作まで止めてしまいます。Deny は「止める理由がはっきりしている狭い範囲」に使います。
CHECK 1ここまでの確認
ある操作について、どのポリシーにも Allow も Deny も書かれていないとき、結果はどうなる?
答えと解説
答え: 2. 何も許可されていないので拒否される（暗黙の拒否）
IAM の出発点は「すべて拒否」です。Allow が1つも当たらなければ、Deny が無くても通りません。「許可と拒否はどの順で決まるのか」の1つ目の規則を読み直してください。
アイデンティティベースとリソースベースは何が違うのか
同じ「S3 のオブジェクトを読んでよい」という許可でも、書く場所が2つあります。人（ユーザー・ロール）の側に書くのがアイデンティティベースのポリシー、バケットの側に書くのがリソースベースのポリシー（S3 ならバケットポリシー）です。
| 観点 | アイデンティティベース | リソースベース |
|---|---|---|
| 付ける場所 | IAM ユーザー・グループ・ロール | S3 バケット・KMS キー・SQS キューなど、対応しているリソース |
| 答える問い | この人は何をしてよいか | このリソースは誰に使わせてよいか |
| Principal（誰が）の書き方 | 書かない（付けた相手が主語） | 書く（どのアカウント・ロール・サービスか） |
| 別アカウントへの許可 | 単独ではできない | 相手のアカウントやロールを Principal に書ける |
| 向いている場面 | 人やアプリの役割ごとに権限を持たせる | リソースを共有する、リソース側で入口を絞る |
IDENTITY VS RESOURCEポリシーの置き場所
人の側は「何をしてよいか」、リソースの側は「誰に使わせるか」
アイデンティティベース
ユーザー・グループ・ロールに付ける
- この人は何をしてよいか付けた相手が主語
- Principal を書かない誰かは付け先で決まる
- 役割ごとに権限を持たせる最初はここから書く
リソースベース
バケット・キー・キューに付ける
- 誰に使わせてよいかリソースが主語
- Principal を書くアカウント・ロール・サービス
- 共有と入口の絞り込みに使う別アカウントへの許可も書ける
同じアカウントの中では「どちらかに Allow があれば通る」
同じアカウントの中のリクエストでは、アイデンティティベースとリソースベースの Allow は足し算で扱われます。人の側に Allow があれば通り、バケットの側に Allow があっても通ります。両方に書く必要はありません。ただし、どちらかに Deny があれば規則3で止まります。
このため、「ユーザーのポリシーには何も書いていないのに、バケットが読めてしまう」ことが起きます。原因は、バケットポリシーがそのユーザー（やアカウント全体）を許可していることです。権限を調べるときは、人の側だけでなく、リソースの側のポリシーも見る必要があります。
なお、KMS のキーポリシーや、ロールの「誰がこのロールを引き受けてよいか」を書く信頼ポリシーのように、リソース側の許可が無いと人の側の Allow だけでは使えないものもあります。「足し算」は多くのサービスでの基本形で、例外はサービスごとのドキュメントに書かれています。
別アカウントからの操作は「両側の許可」が要る
アカウント A のロールが、アカウント B のバケットを読む場合は、評価が2回行われます。A の側で「このロールは B のバケットを読んでよいか」（アイデンティティベース）、B の側で「A のこのロールに読ませてよいか」（リソースベース）です。両方が許可したときだけ通ります。片側だけ書いて「許可したのに通らない」は、別アカウントの操作でよく起きる詰まり方です。
別アカウントのリソースを使わせる方法には、リソースベースのポリシーで相手を許可するほかに、相手に自分のアカウントのロールを引き受けてもらう方法（AssumeRole）もあります。どちらを選ぶかは設計の話なので、ここでは「アカウントをまたぐと両側の許可が要る」とだけ押さえておけば十分です。
CHECK 2ここまでの確認
同じアカウントの中で、ユーザーのポリシーには何も書かれておらず、S3 バケットのバケットポリシーがそのユーザーに読み取りを Allow している。読み取りはどうなる?
答えと解説
答え: 2. どちらか一方の Allow で足りるので許可される
同じアカウントの中では、アイデンティティベースとリソースベースの Allow は足し算（和）で扱われます。別アカウントからの操作なら、両側の許可が要ります。「アイデンティティベースとリソースベースは何が違うのか」を読み直してください。
最小権限はどう作るのか
評価の規則が分かると、最小権限（仕事に必要な権限だけを与える）の作り方も見えてきます。IAM のセキュリティのベストプラクティスは、最小権限を一度で完成させるのではなく、広めに始めて使われている分に絞り込む進め方を勧めています。
TOWARD LEAST PRIVILEGE最小権限の作り方
一度で完成させず、使われた分に絞り込む
-
AWS 管理ポリシーで始める
広めに作られているので、慣れたら置き換える
-
Action と Resource を絞る
* を避け、バケット名やプレフィックスまで書く
-
使われた記録から絞り込む
Access Analyzer が CloudTrail からひな形を作る
-
天井は SCP と権限境界で引く
上限を決めるだけで、許可は与えない
1. 必要な Allow だけを書く
暗黙の拒否があるので、最小権限の基本は「Allow を足しすぎない」ことです。Action に * を書かず、Resource もバケット名やプレフィックスまで絞ります。AWS 管理ポリシーは始めやすい一方で、多くの場面に使えるよう広めに作られているので、慣れたら自分の用途に合わせたポリシー（カスタマー管理ポリシー）に置き換えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-reports/monthly/*"
}
]
}
これは「example-reports バケットの monthly/ の下にあるオブジェクトを読む」だけを許可する例です。一覧の取得（ListBucket）も書き込みもできません。必要になったら、その操作だけを足します。
2. 使われた記録から絞り込む
最初から必要な操作を全部言い当てるのは難しいので、IAM Access Analyzer には、CloudTrail に残った実際の操作の記録から、使われた操作だけを並べたポリシーのひな形を作る機能があります。IAM には、サービスごとに最後に使われた時期を見る機能もあり、使われていない権限を外す手がかりになります。
3. 上限は「天井」として引く
SCP と権限境界は、許可を与えず上限だけを決めます。実際に通るのは「アイデンティティベースの Allow」と「天井」の重なった部分だけです。権限境界だけを付けたロールは、Allow が無いので何もできません。上限の仕組みは、開発者に自分でロールを作らせつつ、自分より強いロールは作らせない、といった場面で使います。
IAM ポリシーでやってはいけない3つ
- Action と Resource の両方に
*を書いた Allow を、日常の作業のユーザーやアプリのロールに付ける - 通らないからといって、原因を調べずに AdministratorAccess を付けて済ませる
- 別アカウントに共有したリソースを、どこに共有したかの記録を残さずに放置する（IAM Access Analyzer で外部と共有されたリソースを洗い出せる）
CHECK 3ここまでの確認
権限境界（permissions boundary）だけを付けて、アイデンティティベースのポリシーを何も付けなかったロールは、何ができる?
答えと解説
答え: 2. 何もできない。境界は上限を決めるだけで、許可を与えない
権限境界と SCP は「ここまでしか許可できない」という天井です。実際に許可するのはアイデンティティベースのポリシーで、天井と許可の重なった部分だけが通ります。「最小権限はどう作るのか」の上限の説明を読み直してください。
まとめ
- IAM の評価は「当てはまる Deny があるか → 当てはまる Allow があるか → どちらも無ければ拒否」の順で決まります。
- 同じアカウントの中では、人の側とリソースの側のどちらかに Allow があれば通ります。別アカウントからは両側の許可が要ります。
- SCP と権限境界は許可を与えない天井です。最小権限は、必要な Allow だけを書き、使われた記録で絞り込み、天井で外枠を引いて作ります。
AccessDenied が返ったときは、「暗黙の拒否か明示的な拒否か」「どの種類のポリシーで止まったか」の2つを先に確かめると、探す場所が決まります。次は、アカウント全体に天井を引く SCP を、マルチアカウント設計の中で読むと、この記事の「上限」の話がつながります。
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
参照ソース
- ポリシーの評価論理（IAM ユーザーガイド） — 暗黙の拒否・明示的な拒否の優先・評価に集められるポリシーの種類の根拠（2026年9月時点の記載）
- 1つのアカウント内のリクエストのポリシー評価（IAM ユーザーガイド） — 同じアカウントではアイデンティティベースとリソースベースの許可が和になることの根拠（2026年9月時点）
- クロスアカウントのポリシー評価論理（IAM ユーザーガイド） — 別アカウントからのリクエストは両方のアカウントで許可が要ることの根拠（2026年9月時点）
- アイデンティティベースのポリシーとリソースベースのポリシー（IAM ユーザーガイド） — 2種類のポリシーの付け先と Principal の違いの根拠（2026年9月時点）
- IAM エンティティのアクセス許可の境界（IAM ユーザーガイド） — 権限境界は許可を与えず上限を決めることの根拠（2026年9月時点）
- IAM でのセキュリティのベストプラクティス（IAM ユーザーガイド） — 最小権限の進め方（管理ポリシーから始めて絞る・使われていない権限を外す）の根拠（2026年9月時点）
- IAM Access Analyzer のポリシー生成（IAM ユーザーガイド） — CloudTrail の記録から使われた操作のポリシーを作る機能の根拠（2026年9月時点）
