適用於 OPA 的設計模型 - AWS 規定指引
在 API 上搭配 PEP 使用集中式 PDP在 API 上搭配 PEP 使用分散式 PDP使用分散式 PDP 作為物件庫

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

適用於 OPA 的設計模型

在 API 上搭配 PEP 使用集中式 PDP

在 API 模型上具有原則強制執行點 (PEP) 的集中式原則決策點 (PDP) 遵循業界最佳實務，為 API 存取控制和授權建立有效且易於維護的系統。這種方法支持幾個關鍵原則：

  • 授權和 API 存取控制會在應用程式中的多個點套用。

  • 授權邏輯獨立於應用程序。

  • 存取控制決策是集中的。

此模型使用集中式 PDP 來做出授權決策。PEP 會在所有 API 中實作，以向 PDP 發出授權要求。下圖顯示如何在假設的多租戶 SaaS 應用程式中實作此模型。

採用集中式 PDP 的 OPA 設計模型

應用程序流程（圖中帶有藍色編號說明）：

  1. 具有 JWT 的身份驗證用戶向 Amazon CloudFront 生成 HTTP 請求。

  2. CloudFront 將請求轉送至設定為 CloudFront來源的 Amazon API Gateway。

  3. 會呼叫 API Gateway 自訂授權程式以驗證 JWT。

  4. 微服務會回應要求。

授權與 API 存取控制流程 (圖中以紅色編號說明)：

  1. PEP 會呼叫授權服務並傳遞要求資料，包括任何 JWT。

  2. 授權服務 (PDP) 會取得要求資料，並查詢 OPA 代理程式 REST API，這是以附屬方式執行。請求數據作為查詢的輸入。

  3. OPA 會根據查詢指定的相關原則評估輸入。如有必要，會匯入資料以作出授權決定。

  4. OPA 將決定傳回授權服務。

  5. 授權決定會傳回給 PEP 並進行評估。

在此架構中，PEP 會在 Amazon CloudFront 和 Amazon API Gateway 的服務端點以及每個微服務請求授權決策。授權決定由具有 OPA 側車的授權服務 (PDP) 進行。您可以將此授權服務當做容器或傳統伺服器執行個體來操作。OPA 附屬程式會在本機公開其 RESTful API，因此只有授權服務才能存取 API。授權服務公開可供 PEP 使用的單獨 API。讓授權服務充當 PEP 和 OPA 之間的中介，允許在 PEP 和 OPA 之間插入任何可能必要的轉換邏輯 — 例如，當 PEP 的授權要求不符合 OPA 預期的查詢輸入時。

您也可以將此架構與自訂原則引擎搭配使用。但是，從 OPA 獲得的任何優勢都必須由自訂原則引擎提供的邏輯取代。

在 API 上使用 PEP 的集中式 PDP 提供了一個簡單的選項，可為 API 建立強大的授權系統。它很容易實作，也提供可重複的介面 easy-to-use，用於針對 API、微服務、前端後端 (BFF) 層或其他應用程式元件進行授權決策。但是，這種方法可能會在應用程序中造成太多延遲，因為授權決策需要調用單獨的 API。如果網路延遲有問題，您可能會考慮使用分散式 PDP。

在 API 上搭配 PEP 使用分散式 PDP

在 API 模型上具有原則強制執行點 (PEP) 的分散式原則決策點 (PDP) 遵循業界最佳實務，為 API 存取控制和授權建立有效的系統。與在 API 模型上使用 PEP 的集中式 PDP 一樣，此方法支援下列關鍵原則：

  • 授權和 API 存取控制會在應用程式中的多個點套用。

  • 授權邏輯獨立於應用程序。

  • 存取控制決策是集中的。

您可能會想知道為什麼在分佈 PDP 時集中存取控制決策。雖然 PDP 可能存在於應用程式中的多個位置，但它必須使用相同的授權邏輯來做出存取控制決策。所有 PDP 在給予相同輸入的情況下提供相同的訪問控制決策。PEP 會在所有 API 中實作，以向 PDP 發出授權要求。下圖顯示了如何在假設的多租戶 SaaS 應用程序中實現此分佈式模型。

在這種方法中，PDP 在應用程序中的多個地方實現。對於具有可執行 OPA 並支援 PDP 的內建運算功能的應用程式元件，例如具有側載的容器化服務或 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體，可將 PDP 決策直接整合到應用程式元件中，而無需對集中式 PDP 服務進行 RESTful API 呼叫。這有助於減少您在集中式 PDP 模型中可能遇到的延遲，因為並非每個應用程式元件都必須進行額外的 API 呼叫，以取得授權決策。不過，對於沒有可直接整合 PDP 的內建運算功能的應用程式元件 (例如 Amazon CloudFront 或 Amazon API Gateway 服務)，在此模型中仍然需要集中式 PDP。

下圖顯示了如何在假設的多租戶 SaaS 應用程序中實現集中式 PDP 和分散式 PDP 的組合。

具有分散式 PDP 的 OPA 設計模型

應用程序流程（圖中帶有藍色編號說明）：

  1. 具有 JWT 的身份驗證用戶向 Amazon CloudFront 生成 HTTP 請求。

  2. CloudFront 將請求轉送至設定為 CloudFront來源的 Amazon API Gateway。

  3. 會呼叫 API Gateway 自訂授權程式以驗證 JWT。

  4. 微服務會回應要求。

授權與 API 存取控制流程 (圖中以紅色編號說明)：

  1. PEP 會呼叫授權服務並傳遞要求資料，包括任何 JWT。

  2. 授權服務 (PDP) 會取得要求資料，並查詢 OPA 代理程式 REST API，這是以附屬方式執行。請求數據作為查詢的輸入。

  3. OPA 會根據查詢指定的相關原則評估輸入。如有必要，會匯入資料以作出授權決定。

  4. OPA 將決定傳回授權服務。

  5. 授權決定會傳回給 PEP 並進行評估。

在此架構中，PEP 會在服務端點 CloudFront 和 API Gateway 以及每個微服務要求授權決策。微服務的授權決定是由授權服務 (PDP) 做出的，該服務與應用程式元件一起運作。此模型適用於在容器或 Amazon 彈性運算雲端 (Amazon EC2) 執行個體上執行的微型服務 (或服務)。對於諸如 API Gateway 之類的服務的授權決策，仍然需要聯繫外部授權服務。 CloudFront 無論如何，授權服務都會公開可供 PEP 使用的 API。讓授權服務充當 PEP 和 OPA 之間的中介，允許在 PEP 和 OPA 之間插入任何可能需要的轉換邏輯 — 例如，當 PEP 的授權要求不符合 OPA 預期的查詢輸入時。

您也可以將此架構與自訂原則引擎搭配使用。但是，從 OPA 獲得的任何優勢都必須由自訂原則引擎提供的邏輯取代。

在 API 上使用 PEP 的分散式 PDP 可提供建立強大的 API 授權系統的選項。您可以輕鬆實作並提供可重複的介面 easy-to-use，以便針對 API、微服務、前端後端 (BFF) 層或其他應用程式元件進行授權決策。這種方法還具有減少您在集中式 PDP 模型中可能遇到的延遲的優點。

使用分散式 PDP 作為物件庫

您也可以從 PDP 中請求授權決策，該 PDP 可作為物件庫或封裝，以便在應用程式中使用。OPA 可以用作 Go 第三方庫。對於其他程式設計語言，採用此模型通常意味著您必須建立自訂原則引擎。