評価論理 - Amazon Simple Notification Service

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

評価論理

評価時の目標は、特定のリクエスト付与を許可するか拒否するかを判断することです。評価論理は、以下の複数の基本ルールに従っています。

  • デフォルトでは、リソースの使用許可を求めるリクエストについては、リクエスタが自分自身である場合を除いて、拒否を適用する

  • 許可はすべてのデフォルトで拒否に優先する

  • 明示的拒否はすべての許可に優先する

  • ポリシー評価の順序は重要ではない

以下のフローチャートと考察では、決定方法についての詳細説明を紹介します。

リソースへのアクセスリクエストを許可または拒否するかどうかを決定する AWS ために が使用する意思決定プロセスを示します。デフォルトの拒否で始まり、該当するポリシーで明示的な拒否がないかを確認し、許可の指示を探し、許可が見つからない場合は、リクエストはデフォルトで拒否されます。
1

決定はデフォルトで拒否から始まります。

2

次に、エンフォースメントコードは、リクエストに適用可能なポリシーすべてを、リソース、プリンシパル、アクション、および条件に基づいて評価します。

エンフォースメントコードによるポリシー評価の順序は重要ではありません。

3

前述のすべてのポリシーにおいて、リクエストに適応する明示的拒否のインストラクションがエンフォースメントコードによって検索されます。

仮に 1 つでも見つかった場合、エンフォースメントコードは「拒否」の決定を返し、プロセスを終了します (これは明示的拒否となります。詳細については、「明示的拒否」を参照してください)。

4

明示的拒否が見つからなかった場合、リクエストに適応する「許可」のインストラクションがエンフォースメントコードによって検索されます。

仮に 1 つでも見つかった場合、エンフォースメントコードは「許可」の決定を返し、プロセスは完了します (サービスはリクエストのプロセスを継続します)。

5

許可が見つからなかった場合、最終決定は「拒否」となります (明示的拒否または許可が見つからない場合、デフォルトで拒否として見なされるためです (詳細については、「デフォルトで拒否」を参照してください)。

明示的拒否とデフォルトで拒否の相互作用

ポリシーがリクエストに直接適用されない場合の結果は、デフォルトで拒否となります。例えば、ユーザーが Amazon の使用をリクエストしたがSNS、トピックのポリシーがユーザーのポリシーを AWS アカウント まったく参照していない場合、そのポリシーはデフォルトの拒否になります。

ステートメントの条件が満たされていない場合においても、ポリシーの結果としてデフォルトで拒否となります。ステートメントのすべての条件が満たされている場合、ポリシーのエフェクトエレメントの値に基づいて、ポリシーの結果は許可または明示的拒否のどちらかとなります。条件が満たされていない際にポリシーが行為を特定していない場合、デフォルトの結果としてデフォルトで拒否となります。

例えば、南極大陸から来るリクエストを防ぐとします。その場合、南極大陸から来ていないリクエストにのみ許可を与えるポリシー (ポリシー A1 とする) を記述します。以下の図はポリシーについて解説しています。

南極大陸からのリクエストでない場合にリクエストを許可するポリシー (ポリシー A1) を示します。「許可」効果を適用するには、リクエストが南極から発信されてはならないという条件を示します。それ以外の場合、デフォルトのアクションはリクエストを拒否することです。

リクエストがアメリカから送られてきた場合、条件を満たしています (リクエストが南極大陸からのものでないため)。従って、そのリクエストは許可されます。しかし、リクエストが南極大陸から送られてきた場合、条件を満たしていないため、ポリシーの結果としてデフォルトで拒否となります。

以下の図のとおり、ポリシー (ポリシー A2 とする) を書き換えることにより、結果を明示的拒否に変えることができます。南極大陸から送られてきた場合、ポリシーによってリクエストが明示的に拒否されます。

南極からのリクエストを明示的に拒否するポリシー (ポリシー A2) を示します。これは、条件が満たされたとき (リクエストが南極大陸から発信されたとき)、ポリシーが明示的な拒否をもたらすことを示しています。つまり、これらの状況では、リクエストは常に拒否されます。

リクエストが南極大陸から送られてきた場合、条件を満たしているため、ポリシーの結果として明示的な拒否となります。

デフォルトで拒否と明示的拒否の区別は重要です。許可によってデフォルトで拒否は上書きできますが、明示的拒否は上書きできないためです。例えば、リクエストが 2010 年 6 月 1 日に到着すれば許可するという別のポリシーがあるとしましょう。このポリシーが、南極大陸からのアクセスを制限しているポリシーと併用されている場合、全体の結果にどのような影響を及ぼすでしょうか? 日付ベースのポリシー (ポリシー B とする) が前述のポリシー A1 および A2 と併用されている場合、全体の結果が比較されます。シナリオ 1 は、ポリシー A1 とポリシー B が併用されている場合、シナリオ 2 は、ポリシー A2 とポリシー B が併用されている場合です。以下の図と考察は、2010 年 6 月 1 日に南極大陸からリクエストが来た場合についての結果を示しています。

ポリシーがリクエストのオリジン (南極) とリクエスト日 (2010 年 6 月 1 日) に基づいてアクセスを制限する 2 つのシナリオを比較します。シナリオ 1 では、ポリシーを組み合わせると、デフォルトの拒否が許可によって上書きされ、リクエストが許可されます。シナリオ 2 では、あるポリシーからの明示的な拒否によって別のポリシーからの許可が上書きされ、リクエストが拒否されます。

このセクションの最初に説明したとおり、シナリオ 1 においては、ポリシー A1 はデフォルトで拒否を返します。2010 年 6 月 1 日に到着したリクエストは、当然のことながら許可されるため、ポリシー B は許可を返します。ポリシー B による許可は、ポリシー A1 のデフォルトで拒否に優先するため、結果としてリクエストは許可されます。

このセクションの最初に説明したとおり、シナリオ 2 においては、ポリシー A2 は明示的拒否を返します。再度、ポリシー B は許可を返します。ポリシー A2 による明示的拒否は、ポリシー B の許可に優先するため、結果としてリクエストは拒否されます。