評估邏輯 - Amazon Simple Notification Service
明確拒絕和預設拒絕的相互作用

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

評估邏輯

評估時間的目標是決定是否應該允許或拒絕授予的請求。評估邏輯遵循幾個基本規則：

  • 根據預設，所有使用您的資源的請求來自任何人，但是您被拒絕

  • 所有允許覆寫任何預設拒絕

  • 明確拒絕覆寫任何允許

  • 評估政策的順序並不重要

以下流程圖和討論更詳細說明如何做出決定。

說明 AWS 用來判斷存取資源請求是否應允許或拒絕的決策程序。其開頭為預設拒絕、檢查適用政策中是否有任何明確拒絕，然後尋找任何允許指示，最後，如果找不到允許，則依預設會拒絕請求。
1

決定以預設拒絕開始。
2

然後強制執行程式碼會評估所有適用於請求的政策 (根據資源、委託人、動作和條件)。

強制執行程式碼評估政策的順序並不重要。
3

在所有那些政策中，強制執行程式碼會尋找適用於請求的明確拒絕。

如果找到即使一個，強制執行程式碼也會傳回「拒絕」的決定，然後完成程序 (這是明確拒絕；如需詳細資訊，請參閱 明確拒絕)。
4

如果找不到明確拒絕，強制執行程式碼會尋找適用於請求的任何「允許」指示。

如果找到即使一個，強制執行程式碼也會傳回「允許」的決定，然後完成程序 (服務繼續處理請求)。
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 日） 限制存取的兩個案例。在案例 1 中，政策的組合會導致允許覆寫預設拒絕，從而允許請求。在案例 2 中，一個政策的明確拒絕會覆寫另一個政策的允許，導致請求遭到拒絕。

在情況 1 中，政策 A1 如本節之前所述傳回預設拒絕。政策 B 因為政策 (按照定義) 允許 2010 年 6 月 1 日進來的請求而傳回允許。政策 B 的允許會覆寫政策 A1 的預設拒絕，請求因此而被允許。

在情況 2 中，政策 A2 如本節之前所述傳回明確拒絕。一樣，政策 B 傳回允許。政策 A2 的明確拒絕會覆寫政策 B 的允許，請求因此而被拒絕。