OPA 的設計模型 - AWS 方案指引
在 APIs 上使用具有 PEPs的集中式 PDP在 APIs 上使用分散式 PDP 搭配 PEPs 使用分散式 PDP 做為程式庫

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

OPA 的設計模型

在 APIs 上使用具有 PEPs的集中式 PDP

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

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

  • 授權邏輯與應用程式無關。

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

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

具有集中式 PDP 的 OPA 設計模型

應用程式流程 （在圖表中以藍色編號的標註表示）：

  1. 具有 JWT 的已驗證使用者會向 Amazon CloudFront 產生 HTTP 請求。

  2. CloudFront 會將請求轉送至設定為 CloudFront 原始伺服器的 Amazon API Gateway。

  3. 呼叫 API Gateway 自訂授權方來驗證 JWT。

  4. Microservices 會回應請求。

授權和 API 存取控制流程 （在圖表中以紅色編號的標註表示）：

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

  2. 授權服務 (PDP) 會取得請求資料並查詢 OPA 代理程式 REST API，而該 API 會以附屬身分執行。請求資料可做為查詢的輸入。

  3. OPA 會根據查詢指定的相關政策來評估輸入。如有需要，系統會匯入資料以做出授權決策。

  4. OPA 會將決策傳回給授權服務。

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

在此架構中，PEPs 會在 Amazon CloudFront 和 Amazon API Gateway 的服務端點，以及每個微服務請求授權決策。授權決策是由授權服務 (PDP) 搭配 OPA 附屬項目做出。您可以將此授權服務做為容器或傳統伺服器執行個體來操作。OPA 附屬項目會在本機公開其 RESTful API，因此 API 只能由授權服務存取。授權服務公開了可供 PEPs 使用的獨立 API。讓授權服務做為 PEPs 和 OPA 之間的媒介，允許在 PEPs 和 OPA 之間插入可能需要的任何轉換邏輯，例如，當來自 PEP 的授權請求不符合 OPA 預期的查詢輸入時。

您也可以將此架構與自訂政策引擎搭配使用。不過，從 OPA 獲得的任何優勢都必須取代為自訂政策引擎提供的邏輯。

API 上具有 PEPs APIs集中式 PDP 提供簡單的選項，可建立 APIs的強大授權系統。它易於實作，也提供easy-to-use可重複界面，用於對 APIs、微服務、後端前端 (BFF) 層或其他應用程式元件進行授權決策。不過，這種方法可能會在您的應用程式中產生過多延遲，因為授權決策需要呼叫單獨的 API。如果網路延遲有問題，您可能會考慮分散式 PDP。

在 APIs 上使用分散式 PDP 搭配 PEPs

API 模型上具有政策強制執行點 PEPs) APIs分散式政策決策點 (PDP) 遵循產業最佳實務，為 API 存取控制和授權建立有效的系統。如同 API 模型上具有 PEPs 的集中式 PDP，此方法支援下列關鍵原則： APIs

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

  • 授權邏輯與應用程式無關。

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

您可能想知道為何在分佈 PDP 時，存取控制決策會集中化。雖然 PDP 可能存在於應用程式中的多個位置，但必須使用相同的授權邏輯來做出存取控制決策。所有 PDPs都會提供相同的存取控制決策，並指定相同的輸入。所有 APIs PEPs，以向 PDP 提出授權請求。下圖顯示如何在假設的多租戶 SaaS 應用程式中實作此分散式模型。

在此方法中，PDPs會在應用程式中的多個位置實作。對於具有可執行 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. Microservices 會回應請求。

授權和 API 存取控制流程 （在圖表中以紅色編號的標註表示）：

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

  2. 授權服務 (PDP) 會取得請求資料並查詢 OPA 代理程式 REST API，而該 API 會以附屬身分執行。請求資料做為查詢的輸入。

  3. OPA 會根據查詢指定的相關政策來評估輸入。如有需要，系統會匯入資料以做出授權決策。

  4. OPA 會將決策傳回給授權服務。

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

在此架構中，PEPs 會在 CloudFront 和 API Gateway 的服務端點，以及每個微服務請求授權決策。微服務的授權決策是由授權服務 (PDP) 所決定，該服務可做為應用程式元件的附屬服務。此模型適用於在容器或 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上執行的微服務 （或服務）。API Gateway 和 CloudFront 等服務的授權決策仍需要聯絡外部授權服務。無論如何，授權服務都會公開可供 PEPs 使用的 API。讓授權服務做為 PEPs 和 OPA 之間的媒介，允許在 PEPs 和 OPA 之間插入可能需要的任何轉換邏輯，例如，當來自 PEP 的授權請求不符合 OPA 預期的查詢輸入時。

您也可以將此架構與自訂政策引擎搭配使用。不過，從 OPA 獲得的任何優勢都必須取代為自訂政策引擎提供的邏輯。

API 上具有 PEPs APIs分散式 PDP 提供為 APIs建立強大授權系統的選項。它易於實作，並提供easy-to-use可重複界面，用於對 APIs、微服務、後端前端 (BFF) 層或其他應用程式元件進行授權決策。此方法也具有減少您在集中式 PDP 模型中可能遇到延遲的優勢。

使用分散式 PDP 做為程式庫

您也可以向 PDP 請求授權決策，該 PDP 以程式庫或套件的形式提供，以在應用程式中使用。OPA 可以用作 Go 第三方程式庫。對於其他程式設計語言，採用此模型通常表示您必須建立自訂政策引擎。