AWS IAMポリシーの評価ロジック

AWSのAPIリクエストが成功するかどうかは、単独のポリシーにAllowが書かれているかだけでは決まりません。AWSはリクエストのプリンシパル、アクション、対象リソース、条件、アカウント境界などを踏まえ、そのリクエストに適用されるポリシーを評価します。

最初に押さえる原則は二つです。明示的な許可がなければ、リクエストはデフォルトで拒否されること、そして適用されるポリシーに一つでも該当する明示的Denyがあれば、Allowより優先して拒否されることです。さらに、アイデンティティベース／リソースベースの権限付与と、権限の上限を定めるポリシーとでは役割が異なります。

まず、リクエストに適用されるポリシーを特定する

評価の出発点は、IAMポリシーを種類順に機械的に並べることではありません。どのポリシーがそのリクエストに適用されるかを決めることです。少なくとも次の項目を確認します。

確認対象	見る内容
プリンシパル	IAMユーザー、IAMロール、ロールセッション、AWSサービスなど、実際に要求を発行した主体
アクション	呼び出したAPIに対応するIAMアクション
リソース	対象のAWSリソースと、そのARNの範囲
条件	リージョン、タグ、送信元、ネットワーク経路など、Conditionやサービスが参照するリクエストコンテキスト
アカウント境界	主体とリソースが同じAWSアカウントにあるか、別アカウントにまたがるか
適用される制御	アイデンティティベース／リソースベースポリシー、権限境界、セッションポリシー、SCP、RCP、VPCエンドポイントポリシーなど

同じアクション名でも、対象リソースや条件が一致しなければ該当するAllowにはなりません。また、サービスによってリソースベースポリシーや各種ポリシー種別への対応状況は異なります。存在しない種類のポリシーを前提にせず、そのサービス・リソース・要求の組み合わせに実際に適用される制御を調べます。

デフォルト拒否と明示的拒否

暗黙的な拒否は初期状態

AWSアカウントのルートユーザーなどの例外を除き、リクエストは初期状態で**暗黙的に拒否（implicit deny）**されています。該当するAllowが見つからないまま評価が終われば、最終結果は拒否です。

暗黙的拒否は「どこかに拒否のDeny文が書かれている」ことを意味しません。単に許可を成立させるAllowがない状態です。そのため、あるポリシーに許可がないというだけで、別の有効な許可経路まで必ず打ち消すとは限りません。適用される許可経路と上限を合わせて考えます。

明示的なDenyはAllowに優先する

ポリシーにEffect: "Deny"があり、対象アクション・リソース・条件がリクエストと一致すると、**明示的拒否（explicit deny）**になります。アイデンティティベースポリシーにAllowがあっても、別の適用ポリシーが同じリクエストを明示的に拒否していれば、要求全体は拒否されます。

適用されるポリシーのどこかに該当する明示的Denyがある
  → 拒否

該当する明示的Denyがない
  → 必要な許可経路でAllowが成立し、適用される上限も満たすかを確認
    → 成立すれば許可され得る
    → 成立しなければ暗黙的拒否

Denyを含むポリシーが存在するだけで、すべての要求が拒否されるわけでもありません。そのDeny文のアクション、リソース、条件に今回の要求が該当するかを照合します。反対に、明示的Denyが見つかった場合は、ほかのポリシーに許可を追加しても、その拒否を相殺できません。

権限を与えるポリシーと、上限を定めるポリシー

リクエストを許可するポリシーの代表は、アイデンティティベースポリシーとリソースベースポリシーです。前者はIAMユーザーやロールなどのアイデンティティに付け、後者は対応するリソースに付けます。これらによる許可があっても、次のような制限が要求に適用される場合は、その上限も満たさなければなりません。

ポリシー	適用対象・働き	許可がない場合
アイデンティティベースポリシー	IAMユーザー、グループ、ロールなどの主体に操作を許可する	このポリシーによる許可経路は成立しない。ただし、同一アカウントでリソースベースポリシーによる別の許可経路が成立することがある
リソースベースポリシー	対応するリソースに対して、Principalなどで対象主体を指定してアクセスを許可する	このポリシーによる許可経路は成立しない。クロスアカウントでは、通常この側の許可も必要
権限境界（permissions boundary）	IAMユーザーまたはロールのアイデンティティベース権限に設定する上限	通常のアイデンティティベース権限として、境界で許可されない要求は通らない。境界自体は権限を付与しない
セッションポリシー	STSなどで取得する一時セッションに付け、セッションで使える権限をさらに限定する	セッションポリシーが適用される通常の権限経路では、そのセッションに要求を許可しない
サービスコントロールポリシー（SCP）	AWS Organizationsのルート、OU、アカウントに設定し、対象メンバーアカウントのIAM主体が利用できる権限の上限を制御する	適用階層のポリシーで要求に必要な許可が成立しなければ、メンバーアカウントの主体はその操作を行えない
リソースコントロールポリシー（RCP）	AWS Organizationsで対象リソース側に適用される権限上限	対応サービス・リソースでRCPが適用され、要求を許可する条件が満たされないと拒否され得る
VPCエンドポイントポリシー	指定したVPCエンドポイントを通る要求に対する追加の制御	そのエンドポイント経由の要求が許可されない。IAMの許可を置き換えるものではない

権限境界、セッションポリシー、SCP、RCP、VPCエンドポイントポリシーは、それ自体が一般的な操作権限を新たに付与するものではありません。適用される権限付与ポリシーの許可に加え、要求が該当する制限を満たす必要があります。たとえば、SCPにAllowがあっても、それだけを根拠にIAMロールがAWS APIを実行できるわけではありません。

SCPはOrganizationsの階層（組織ルート、OU、アカウント）にアタッチします。適用される階層全体を通じて要求が許可される必要があります。SCPはメンバーアカウント内のIAMユーザー／ロールの権限上限を制御しますが、管理アカウントの主体やサービスリンクロールには適用されません。実際の適用範囲はOrganizationsの仕様と例外も確認してください。

同一アカウント内のリクエスト

同一AWSアカウント内でIAMユーザーまたはロールがリソースにアクセスする場合、アイデンティティベースポリシーとリソースベースポリシーによる許可は、基本的に**和集合（OR）**として扱われます。該当するAllowがどちらかにあり、適用される明示的拒否や上限制御に抵触しなければ、要求は許可され得ます。したがって、同じアカウント内のロールからリソースを利用するすべてのケースで、リソースポリシーが必須になるわけではありません。

この基本形では、権限境界はアイデンティティベースポリシーによる許可の上限を定めます。通常のアイデンティティベース権限については、アイデンティティの許可と境界の許可の共通部分が基本的な上限です。SCPやRCPが適用される場合も、その要求に適用される組織上の制御を満たします。

ただし、リソースベースポリシーの許可先として記述されたプリンシパルの種類は重要です。たとえば、リソースポリシーがIAMロール自体を許可する場合と、ロールを引き受けて得たロールセッションを直接許可する場合では、権限境界やセッションポリシーによる暗黙的拒否の扱いが異なることがあります。ロールセッションへ直接付与された許可が、アイデンティティポリシー・権限境界・セッションポリシーの暗黙的拒否では制限されないケースがあります。一方、適用される明示的Denyは依然として優先します。

このため、「同一アカウントならどの許可も単純なOR」「境界があるならどの認可経路も常に境界とのAND」と一般化するのは不正確です。実際のプリンシパルがIAMロールかロールセッションか、リソースポリシーがどのARNを許可しているかを確かめます。IAMユーザー、フェデレーティッドユーザーセッション、ロールセッションでも直接許可の評価上の違いがあります。

クロスアカウントのリクエスト

要求を行うプリンシパルのアカウントと、アクセス対象リソースを所有するアカウントが異なる場合は、クロスアカウントアクセスです。要求元側だけ、またはリソース所有側だけの許可では成立しません。

1. 要求元アカウント側では、要求を発行するIAMユーザー／ロールなどのアイデンティティベースポリシーが、アクションと対象リソースへのアクセスを許可する。
2. リソース所有アカウント側では、バケットポリシーなど対象リソースのリソースベースポリシーが、要求元のプリンシパルを許可する。
3. それぞれのアカウント側で要求に適用される上限制御・条件を確認する。どちらの評価であっても、該当する明示的Denyがあれば要求は拒否される。

言い換えると、クロスアカウントでは、要求元側とリソース所有側の両方の評価がAllowとなる必要があります。AWS OrganizationsのSCP/RCP、権限境界、セッションポリシーなど、要求に適用される制限があれば、それらも満たします。

例：集計タスクから別アカウントのイベントバスへ送信

アプリケーション用アカウントのECSタスクが、運用記録用の別アカウントにあるAmazon EventBridgeイベントバスへイベントを送る構成を考えます。要求を実行するのはECSタスクに割り当てたタスクロールです。

• タスクロールに付けるアイデンティティベースポリシーで、送信先イベントバスARNに対するevents:PutEventsを許可する。
• 送信先アカウントでは、イベントバスのリソースベースポリシーで、そのタスクロールをプリンシパルとしてevents:PutEventsを許可する。
• 要求を明示的に拒否するポリシーがなく、適用される組織ポリシー・権限境界などの上限と条件も満たす。

三つの観点を確認してはじめて、クロスアカウントの許可が成立し得ます。送信元ロールに許可があってもイベントバス側の許可が欠ければ失敗し、イベントバスが許可していてもロール側の許可がなければ成立しません。

EC2インスタンスとロールの許可を混同しない

EC2上のアプリケーションがAWS APIを呼び出す場合、インスタンスプロファイルを通じてIAMロールをインスタンスに関連付けます。アプリケーションはそのロールの一時認証情報を利用します。AWSサービスの操作を許可するのは、ロールに付けたアイデンティティベースポリシーです。インスタンスプロファイルそのものやEC2インスタンスのリソースポリシーが、その操作を許可するわけではありません。

また、リソース側の許可が必要な構成では、対象リソースのポリシーで呼び出し元プリンシパルを許可します。ロールの権限ポリシーは「ロールが何をできるか」、リソースポリシーは「そのリソースがどの主体からの要求を受け入れるか」を表す別々の設定です。同一アカウントかクロスアカウントか、サービスがリソースポリシーをサポートするかによって必要な組み合わせは異なります。

ポリシー評価でよくある誤解

評価順をすべての要求に共通する一本の列だと考える

評価の概念図では、明示的拒否、組織上の上限、権限を与える許可を段階的に示せます。しかし、すべてのAWS要求が同じポリシーを同じ固定順序で通る、という意味ではありません。AWSは適用対象となるポリシーをリクエストコンテキストに基づいて評価し、同一アカウント／クロスアカウント、プリンシパル種別、サービスの仕様により評価関係が異なります。

図のフローは「該当する明示的拒否がないか」「必要な上限を満たすか」「その要求に必要な許可経路が成立するか」を整理する学習用の判定枠組みです。特定のポリシー種別が必ずすべての要求に存在することや、固定順に処理されることを表してはいません。

「ポリシーにAllowがある」ことと「要求が許可される」ことを同一視する

Allowのアクション・リソース・条件が要求と一致しなければ、そのステートメントは許可になりません。さらに、明示的Denyがあれば拒否されます。権限境界・SCP・セッションポリシーなどが要求を制限していれば、権限付与側にAllowがあっても不足です。

一方で、暗黙的拒否と明示的拒否は同じではありません。たとえば、あるポリシーにAllowが見つからないことは、そのポリシーによる許可が成立しないことを意味しますが、同一アカウントで別の許可経路が成立するかどうかはプリンシパルとリソースポリシーの評価に依存します。

SCPや権限境界を許可ポリシーとして使う

SCPや権限境界は、許可可能な範囲を制限するガードレールです。そこにAllowがあるだけで、ユーザーやロールへAPI権限が追加されるわけではありません。必要なアイデンティティベース／リソースベースの許可と、適用されるすべての上限の両方がそろっているかを見ます。

AccessDeniedを調べるチェックリスト

許可をやみくもに追加する前に、次の順で要求の事実関係を追跡します。

1. 実際のプリンシパルを確認する：IAMユーザー、ロール、ロールセッション、AWSサービスのどれが要求を発行したかを特定する。
2. アクションとリソースを照合する：APIに対応するIAMアクション、対象ARN、リージョンなどに誤りがないかを確認する。
3. 条件を確認する：ポリシーのConditionで参照する値が要求コンテキストと一致しているかを調べる。
4. 適用される明示的Denyを探す：アイデンティティ、リソース、権限境界、セッション、Organizations、エンドポイントなど、要求に関係するポリシーを調べる。
5. 許可経路を確認する：同一アカウントなら適用されるアイデンティティ／リソースベース許可、クロスアカウントなら両アカウント側の許可が成立しているかを見る。
6. 各上限の適用有無を確認する：権限境界、セッションポリシー、SCP、RCP、VPCエンドポイントポリシーなどに要求を妨げる制限がないか調べる。
7. プリンシパルの直接指定を再確認する：リソースポリシーがロール自体かロールセッションかなど、どのプリンシパルを許可しているかを確認する。

ポリシーのJSONを読むときは、EffectだけでなくAction、Resource、Principal（リソースポリシーの場合）、Condition、アタッチ先を一組として評価します。どの一つが原因かを特定してから修正すれば、不要に広い許可を追加せず、意図した権限だけを成立させやすくなります。

DVA試験での判断ポイント

• 明示的Denyは、適用対象のAllowに優先する。明示的拒否がなければ自動的に許可されるわけではなく、必要なAllowがなければ暗黙的拒否となる。
• Allowの有無は、アクション・リソース・条件・プリンシパルが実際の要求に一致するかと合わせて判断する。
• 同一アカウントでは、アイデンティティベースとリソースベースの許可は基本的に和集合。ただし、権限上限や直接許可されたプリンシパル種別による評価上の違いを無視しない。
• クロスアカウントでは、要求元アカウントのアイデンティティベース許可と、リソース所有アカウント側のリソースベース許可をそろえる。
• 権限境界・セッションポリシー・SCPは権限を付与しない。許可ポリシーと、適用される上限の双方を確認する。
• EC2アプリケーションにはインスタンスプロファイルでロールを関連付ける。AWS APIの許可はロールのポリシーで判断する。
• 評価順序を一律の固定リストとして暗記するのではなく、要求のプリンシパル、アカウント境界、許可経路、上限を特定する。
• ロールセッションなどへのリソースポリシーによる直接許可は、暗黙的拒否との関係に例外があり得る。明示的拒否が優先される原則とは分けて理解する。

公式ドキュメント

• IAM ポリシー評価ロジック
• AWSのアクセス許可判定ロジック
• 同一アカウント内のリクエストに対するIAMポリシー評価
• クロスアカウントのポリシー評価ロジック
• AWS Organizations のサービスコントロールポリシー（SCP）