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

# 實作 PEP
<a name="pep"></a>

政策強制執行點 (PEP) 負責接收傳送至政策決策點 (PDP) 以供評估的授權請求。PEP 可以位於應用程式中的任何位置，其中資料和資源必須受到保護，或套用授權邏輯。與 PDPs 相比PEPs 相對簡單。PEP 僅負責請求和評估授權決策，不需要任何授權邏輯。與 PDPs不同，PEPs 無法集中在 SaaS 應用程式中。這是因為需要在整個應用程式及其存取點中實作授權和存取控制。PEPs可以套用至 APIs、微服務、後端前端 (BFF) 層，或應用程式中需要或需要存取控制的任何點。讓 PEPs 在應用程式中普及，可確保在多個點時經常獨立驗證授權。   

若要實作 PEP，第一個步驟是判斷應用程式中應執行存取控制的位置。在決定應將哪些 PEPs 整合到您的應用程式中時，請考慮此原則： 

*如果應用程式公開 API，則該 API 應具備授權和存取控制。*

這是因為在微服務導向或服務導向架構中，APIs可做為不同應用程式函數之間的分隔符號。將存取控制作為應用程式函數之間的邏輯*檢查點*是合理的。**我們強烈建議您納入 PEPs做為存取 SaaS 應用程式中每個 API 的先決條件。**您也可以在應用程式中的其他時間點整合授權。在單體應用程式中，可能需要將 PEPs整合到應用程式本身的邏輯中。沒有應該包含 PEPs 的單一位置，但請考慮使用 API 原則做為起點。

## 請求授權決策
<a name="request-decision"></a>

PEP 必須向 PDP 請求授權決策。請求可以採用多種形式。請求授權決策最簡單且最容易存取的方法，是將授權請求或查詢傳送至 PDP (OPA 或驗證許可） 公開的 RESTful API。如果您使用的是 Verified Permissions，您也可以使用 AWS SDK 來擷取授權決策，以呼叫 **IsAuthorized** 方法。此模式中 PEP 的唯一函數是轉送授權請求或查詢所需的資訊。這可以像將 API 收到的請求轉送為 PDP 輸入一樣簡單。還有其他建立 PEPs 的方法。例如，您可以將 OPA PDP 在本機與以 Go 程式設計語言撰寫的應用程式整合為程式庫，而不是使用 API。

## 評估授權決策
<a name="evaluate-decision"></a>

PEPs 需要包含邏輯來評估授權決策的結果。當 PDPs公開為 APIs時，授權決策可能採用 JSON 格式，並由 API 呼叫傳回。PEP 必須評估此 JSON 程式碼，以判斷所採取的動作是否已獲得授權。例如，如果 PDP 旨在提供布林值*允許**或拒絕*授權決策，則 PEP 可能只檢查此值，然後傳回 HTTP 狀態碼 200 表示*允許*，傳回 HTTP 狀態碼 403 表示*拒絕*。這種將 PEP 整合為存取 API 的先決條件的模式，是在 SaaS 應用程式中實作存取控制的輕鬆實作和高效模式。在更複雜的案例中，PEP 可能負責評估 PDP 傳回的任意 JSON 程式碼。必須寫入 PEP，以包含解釋 PDP 傳回的授權決策所需的任何邏輯。由於 PEP 可能在您應用程式中的許多不同位置實作，我們建議您將 PEP 程式碼封裝為可重複使用的程式庫或您選擇的程式設計語言成品。如此一來，您的 PEP 就可以輕鬆地在應用程式中的任何時間點整合，只需最少的重新作業。