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

# 評価論理
<a name="sns-access-policy-language-evaluation-logic"></a>

評価時の目標は、特定のリクエスト付与を許可するか拒否するかを判断することです。評価論理は、以下の複数の基本ルールに従っています。
+ デフォルトでは、リソースの使用許可を求めるリクエストについては、リクエスタが自分自身である場合を除いて、拒否を適用する
+ 許可はすべてのデフォルトで拒否に優先する
+ 明示的拒否はすべての許可に優先する
+ ポリシー評価の順序は重要ではない

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

![リソースへのアクセスリクエストを許可または拒否するかどうかを決定する AWS ために で使用される意思決定プロセスを示します。デフォルトの拒否で始まり、適用可能なポリシーによる明示的な拒否がないかを確認し、次に許可の指示を探して、最終的に許可が見つからない場合は、リクエストはデフォルトで拒否されます。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/AccessPolicyLanguage_Evaluation_Flow.gif)



|  |  | 
| --- |--- |
| 1 | 決定はデフォルトで拒否から始まります。 | 
| 2 |  次に、エンフォースメントコードは、リクエストに適用可能なポリシーすべてを、リソース、プリンシパル、アクション、および条件に基づいて評価します。<br />エンフォースメントコードによるポリシー評価の順序は重要ではありません。 | 
| 3 |  前述のすべてのポリシーにおいて、リクエストに適応する明示的拒否のインストラクションがエンフォースメントコードによって検索されます。<br />仮に 1 つでも見つかった場合、エンフォースメントコードは「拒否」の決定を返し、プロセスを終了します (これは明示的拒否となります。詳細については、「[明示的拒否](sns-access-policy-language-key-concepts.md#Define_HardDeny)」を参照してください)。 | 
| 4 | 明示的拒否が見つからなかった場合、リクエストに適応する「許可」のインストラクションがエンフォースメントコードによって検索されます。<br />仮に 1 つでも見つかった場合、エンフォースメントコードは「許可」の決定を返し、プロセスは完了します (サービスはリクエストのプロセスを継続します)。 | 
| 5 | 許可が見つからなかった場合、最終決定は｢拒否｣となります (明示的拒否または許可が見つからない場合、*デフォルトで拒否*として見なされるためです (詳細については、「[デフォルトで拒否](sns-access-policy-language-key-concepts.md#Define_SoftDeny)」を参照してください)。 | 

## 明示的拒否とデフォルトで拒否の相互作用
<a name="denials"></a>

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

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

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

![南極から来ていないリクエストに許可を与えるポリシー (ポリシー A1) を示します。これは「許可」を適用するためには、リクエストは南極から発信されていてはならないという条件を示しています。条件が満たされない場合、デフォルトのアクションはリクエストを拒否することです。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/AccessPolicyLanguage_Allow_Override_1.gif)


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

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

![南極からのリクエストを明示的に拒否するポリシー (ポリシー A2) を示します。条件が満たされた場合 (リクエストが南極から発信された場合）にポリシーによって明示的な拒否が行われることを示しています。つまり、これらの状況ではリクエストは常に拒否されます。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/AccessPolicyLanguage_Allow_Override_2.gif)


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

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

![リクエストの送信元 (南極) とリクエスト日 (2010 年 6 月 1 日) に基づいて、ポリシーによってアクセスが制限される 2 つのシナリオを比較します。シナリオ 1 では、ポリシーの組み合わせにより、デフォルトの拒否が許可によって上書きされ、リクエストは許可されます。シナリオ 2 では、あるポリシーによる明示的な拒否によって別のポリシーによる許可が上書きされ、結果としてリクエストは拒否されます。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/AccessPolicyLanguage_Allow_Override.gif)


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

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