隨著更多工作負載遵守 API 優先的設計方法 ，以及透過因特網對 Web 應用程式威脅的日益增多和嚴重性，因此必須有安全性策略來保護 API。 API 安全性的其中一個步驟是使用 閘道路由模式來保護網路流量。 除了支持彈性路由規則之外，您還可以使用閘道來限制流量來源位置和流量品質。 本文說明如何使用 Azure 應用程式閘道 和 Azure API 管理 來保護 API 存取。
架構
本文不會解決應用程式的基礎平臺，例如 App Service 環境、Azure SQL 受控執行個體 和 Azure Kubernetes Services。 圖表的那些部分只會展示您可以做為更廣泛解決方案執行的動作。 本文特別討論陰影區域、API 管理 和 應用程式閘道。
下載此架構的 Visio 檔案。
工作流程
應用程式閘道 會接收其子網網路安全組 （NSG） 允許的 HTTP 要求。
應用程式閘道 上的 Web 應用程式防火牆 （WAF）接著會根據WAF規則檢查要求，包括 Geomatch 自定義規則。 如果要求有效，要求會繼續進行。
應用程式閘道 設定 URL Proxy 機制，以將要求傳送至適當的後端集區。 例如，視 API 呼叫的 URL 格式而定：
格式如下
api.<some-domain>/external/*的 URL 可以連線到後端，以與要求的 API 互動。格式化為
api.<some-domain>/*的呼叫會移至死端 （sinkpool），這是沒有目標的後端集區。
此外，應用程式閘道 接受和 Proxy 內部呼叫，其來自相同 Azure 虛擬網路中的資源。。
api.<some-domain>/internal/*最後，在 API 管理 層級，API 會設定為接受下列模式下的呼叫：
api.<some-domain>/external/*api.<some-domain>/internal/*
在此案例中，API 管理 使用兩種類型的IP位址：公用和私用。 公用IP位址適用於埠3443上的內部通訊，以及外部虛擬網路組態中的運行時間 API 流量。 當 API 管理 將要求傳送至公用因特網對向後端時，它會將公用IP位址顯示為要求的來源。 如需詳細資訊，請參閱 VNet 中 API 管理 服務的 IP 位址。
應用程式閘道 層級的路由規則會適當地將使用者
portal.<some-domain>/*重新導向至開發人員入口網站，讓開發人員能夠從內部和外部環境管理 API 及其設定。
元件
Azure 虛擬網絡 可讓許多類型的 Azure 資源私下彼此通訊、因特網和內部部署網路。 在此架構中，應用程式閘道 負責將公用因特網流量通道傳送至此專用網。
Azure 應用程式閘道 是一個 Web 流量負載平衡器，可管理 Web 應用程式的流量。 此類型的路由稱為應用程式層 (OSI 第 7 層) 負載平衡。 在此架構中，網關不僅用於路由，而且閘道也會裝載 Web 應用程式防火牆 （WAF） 來保護常見的Web型攻擊向量。
Azure API 管理 是適用於所有環境的 API 的混合式多重雲端管理平臺。 API 管理 為現有的後端服務建立一致的新式 API 閘道。 在此架構中，API 管理 用於完全私人模式，以卸載 API 程式代碼和主機的交叉考慮。
建議
此解決方案著重於實作整個解決方案，以及測試來自 API 管理 虛擬網路內外的 API 存取。 如需 API 管理 虛擬網路整合程式的詳細資訊，請參閱在內部 VNET 中整合 API 管理 與 應用程式閘道。
若要與後端中的私人資源通訊，應用程式閘道 和 API 管理 必須與資源或對等互連虛擬網路中的虛擬網路相同。
私人的內部部署模型可讓 API 管理 連線到現有的虛擬網路，使其可從該網路內容內部連線。 若要啟用此功能，請部署開發人員或進階 API 管理 層。
在 Azure 金鑰保存庫 中管理應用程式閘道憑證。
若要個人化與服務的互動，您可以使用 CNAME 專案。
替代項目
您可以使用其他服務來提供類似的防火牆層級和 Web 應用程式防火牆 （WAF） 保護：
- Azure Front Door
- Azure 防火牆
- Barracuda 等 合作夥伴解決方案
- Azure Marketplace 中 提供的其他解決方案
考量
可靠性
不論實例計數為何，Azure 應用程式閘道 一律會以高可用性的方式部署。 若要避免區域故障的影響，您可以設定 應用程式閘道 跨越多個 可用性區域。 如需詳細資訊，請參閱 自動調整和高可用性。
為您的 API 管理 服務元件啟用區域備援，以提供復原和高可用性。 區域備援會在實體分隔區域中跨數據中心複寫 API 管理 閘道和控制平面，使其能夠復原區域失敗。 需要 API 管理 進階層才能支援可用性區域。
API 管理 也支援多區域部署，如果某個區域離線，可以改善可用性。 如需詳細資訊，請參閱 多區域部署。 在此拓撲中，每個區域也必須有一個 應用程式閘道，因為 應用程式閘道 是區域服務。
安全性
如需 應用程式閘道 安全性的詳細資訊，請參閱適用於 應用程式閘道 的 Azure 安全性基準。
如需 API 管理 安全性的詳細資訊，請參閱適用於 API 管理 的 Azure 安全性基準。
Azure DDoS 保護 (結合應用程式設計最佳做法) 可提供增強的 DDoS 風險降低功能，以針對 DDoS 攻擊提供更多的防禦。 您應該在任何周邊虛擬網路上啟用 Azure DDOS 保護。
成本最佳化
此架構的成本取決於組態層面，例如：
- 服務層
- 延展性，表示服務動態配置的實例數目，以支援指定的需求
- 此架構會持續執行，還是每月僅執行數小時
評估這些層面之後，請移至 Azure 定價計算機 以預估定價。
效能效益
應用程式閘道 是此架構的進入點，而 WAF 功能需要每個要求分析的額外處理能力。 若要允許 應用程式閘道 在現場擴充其計算容量，請務必啟用自動調整。 如需詳細資訊，請參閱 指定自動調整。 請遵循產品文件建議 應用程式閘道 的子網大小。 這可確保子網夠大，可支援完整向外延展。
若要支援高度並行的案例，請開啟 API 管理 自動調整。 自動調整可擴充 API 管理 功能，以回應越來越多的傳入要求。 如需詳細資訊，請參閱自動調整 Azure API 管理 實例。
部署此案例
此案例示範於 Azure 快速入門資源庫發行 應用程式閘道 與內部 API 管理 和 Web 應用程式。
下一步
遵循良好的 Web API 設計指導方針來設計 API，並使用良好的 Web API 實 作做法加以實作。