共用方式為

使用應用程式閘道和 API 管理 來保護 API

Azure API 管理
Azure 應用程式閘道

組織越來越多地採用 API 優先的設計方法，同時面臨著日益增長的 Web 應用程式威脅。 你需要一套全面的安全策略來保護 API，尤其是在暴露 AI 驅動的 API 並實施零信任架構原則時。 閘道路由模式透過保護網路流量，提供一種 API 安全方法。 網關限制流量源位置和流量質量，同時支持靈活的路由規則。 本文說明如何使用 Azure 應用程式閘道 和 Azure API 管理 來保護 API 存取。

Architecture

本文不會解決應用程式的基礎平臺，例如 App Service 環境、Azure SQL 受控實例和 Azure Kubernetes Service （AKS）。 圖表的這些部分展示了您可以實作為更廣泛的解決方案的內容。 本文特別討論陰影區域、API 管理和應用程式閘道。

顯示應用程式閘道和 API 管理 如何保護 API 的圖表。

下載此架構的 Visio 檔案。

Workflow

  1. 應用程式閘道會接收子網路安全性群組 （NSG） 允許的 HTTPS 要求。

  2. 應用程式閘道上的 Web 應用程式防火牆 （WAF） 會根據 WAF 規則檢查要求，包括 異地比對自訂規則。 如果要求有效，要求會繼續進行。

  3. 應用程式閘道會設定 URL Proxy 機制，以將要求傳送至適當的 後端集區。 路由行為取決於 API 呼叫的 URL 格式：

    • 格式化為 api.<some-domain>/external/* 的 URL 可以到達後端以與請求的 API 互動。

    • 格式化為 api.<some-domain>/* 的呼叫會移至死胡同，稱為 接收池，這是沒有目標的後端集區。

    • 應用程式閘道層級的路由規則會將使用者 portal.<some-domain>/* 重新導向至開發人員入口網站。 開發人員可以從內部和外部環境管理 API 及其配置。 或者，您可以完全封鎖開發人員入口網站。

  4. 應用程式閘道會接受並代理來自 下相同 Azure 虛擬網路 api.<some-domain>/internal/*中資源的內部呼叫。

  5. 在 API 管理 層級，API 會接受下列模式下的呼叫：

    • api.<some-domain>/external/*
    • api.<some-domain>/internal/*

    在此案例中，API 管理 會使用公用和私人 IP 位址。 公用 IP 位址支援管理平面和外部虛擬網路設定中運行時間 API 流量的埠 3443 上的管理作業。 當 API 管理 將要求傳送至公用因特網對向後端時，它會將公用IP位址顯示為要求的來源。 如需詳細資訊，請參閱 虛擬網路中 API 管理 的 IP 位址。

Components

  • Azure 虛擬網路 可讓許多類型的 Azure 資源彼此、因特網和內部部署網路私下通訊。 在此架構中，應用程式閘道會將公用網際網路流量通道化至此私人網路。

  • 應用程式閘道 是管理 Web 應用程式流量的 Web 流量負載平衡器。 這種類型的路由稱為 應用層（OSI 第 7 層）負載平衡。 在此架構中，閘道提供路由並裝載 WAF，以防範常見的 Web 型攻擊媒介。

  • API 管理 是適用於所有環境之 API 的混合式多重雲端管理平臺。 API 管理 會為現有的後端服務建立一致的新式 API 閘道。 在此架構中，API 管理 會以完全私人模式運作，以卸載 API 程式碼和主機的跨領域考量。

Alternatives

您可以使用其他服務來提供類似層級的防火牆和 WAF 保護：

Recommendations

此架構著重於實作整個解決方案，並測試來自 API 管理 虛擬網路內部和外部的 API 存取。 如需整合程式的詳細資訊，請參閱 使用應用程式閘道在內部虛擬網路中整合 API 管理。

若要與後端中的私人資源通訊，請將應用程式閘道和 API 管理 放在與資源相同的虛擬網路中，或放在對等互連的虛擬網路中。

  • 私人內部部署模型可讓 API 管理 連線到現有的虛擬網路，這可讓您從該網路內容內部存取。 若要啟用此功能，請部署傳統虛擬網路插入的 開發人員 或 進階 API 管理 層。 如需較新的虛擬網路選項，請使用具有虛擬網路整合或插入功能的 標準 v2 或 進階 v2 層。

  • 如果您的用戶端在不同的訂用帳戶中運作，或使用不同的 Microsoft Entra ID 目錄進行管理，請使用 適用於應用程式閘道的 Azure Private Link ，從跨訂用帳戶和區域的用戶端虛擬網路提供應用程式閘道的私人連線。

  • 管理 Azure 金鑰保存庫中的應用程式閘道憑證。

  • 若要個人化與服務的互動，您可以使用 標準名稱 （CNAME） 項目。

Considerations

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。

應用程式閘道一律會以高可用性設定部署，而不論執行個體計數為何。 若要減少區域故障的影響，您可以將應用程式閘道設定為跨越多個可用性區域。 如需詳細資訊，請參閱 自動調整和高可用性。

為您的 API 管理 服務元件啟用區域備援，以提供復原和高可用性。 區域備援會跨實體分隔區域中的數據中心複寫 API 管理閘道和控制平面。 此組態可讓它們對區域失敗進行復原。 您必須使用 API 管理 進階 層來支援 可用性區域。

API 管理 也支援多區域部署，如果一個區域離線，這可以改善可用性。 如需詳細資訊，請參閱 多區域支援。 在此拓撲中，為每個區域部署一個應用程式閘道，因為應用程式閘道是區域服務。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。

如需 應用程式閘道 安全性的詳細資訊，請參閱適用於 應用程式閘道 的 Azure 安全性基準。

如需 API 管理 安全性的詳細資訊，請參閱適用於 API 管理 的 Azure 安全性基準。

一律實作下列安全性措施：

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。

此架構的成本取決於數位組態層面：

  • 服務層級： 請考慮 API 管理的標準 v2 和進階 v2 層，以改善成本效益和效能。

  • 可擴展性：服務會動態配置執行個體數目，以支援指定的需求。

  • 運行時間持續時間： 成本會根據架構是連續執行還是每月僅執行幾個小時而有所不同。

  • 數據傳輸： 多區域部署會產生區域之間的傳輸成本。

  • WAF 處理： 成本取決於評估的要求和規則數目。

請考慮下列成本優化策略：

評估這些層面之後，請使用 Azure 定價計算機 來預估定價。

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。

實現全面的監控和可觀察性：

效能效率

效能效率是指工作負載能夠有效率地調整以符合使用者需求。 如需詳細資訊，請參閱 效能效率的設計檢閱檢查清單。

應用程式閘道可作為此架構的進入點，而 Azure Web 應用程式防火牆功能需要每個要求分析的處理能力。 若要允許應用程式閘道視需要擴充其運算容量，請啟用自動調整。 如需詳細資訊，請參閱 應用程式閘道中的自動調整和區域備援。 請遵循 應用程式閘道基礎結構設定的產品檔建議，包括適當的子網大小調整。 此方法可確保子網路足夠大，以支援完整橫向擴充。

請考慮下列 API 管理的效能優化：

後續步驟

若要設計 API，請遵循良好的 Web API 設計 指導方針。 若要實作 API，請使用良好的 Web API 實作 做法。