透過使用專用元件在用戶端與應用程式或服務間介接請求，來保護應用程式與服務。 經紀人會驗證並淨化請求，並提供額外的安全層，限制系統的攻擊面。
內容和問題
許多雲端服務會暴露端點，讓客戶端應用程式能透過網際網路或其他不受信任的網路呼叫他們的 API。 實作 API 的程式碼會觸發或執行多項任務，包括但不限於認證、授權、參數驗證，以及部分或全部請求處理。 API 程式碼很可能會代表客戶端存取儲存空間及其他服務。
如果惡意使用者入侵系統並取得應用程式主控環境的存取權，則會公開其安全性機制及數據和其他服務的存取權。 因此，惡意使用者可以取得認證、記憶體密鑰、敏感性資訊和其他服務的不受限制存取權。
Solution
解決這個問題的一個方法是將實作公開端點的程式碼與處理請求及存取儲存的程式碼解耦。 透過使用一個與客戶互動的表面層級來解耦程式碼，並將核准的請求經由內部端點、佇列或代理路由到處理業務運作的工作負載元件。 圖示提供了此模式的高層次概述。
你可以使用 Gatekeeper 模式來保護儲存，或將其作為更全面的表象，保護應用程式的所有功能。 重要因素包括：
受控驗證： 閘控人會驗證所有請求，並拒絕不符合驗證要求的請求。
風險與暴露有限： 風險和風險暴露會降低，因為守門人不會存取受信任主機用來存取儲存和服務的憑證或金鑰。 如果守門人被攻破，攻擊者就無法取得這些憑證或金鑰。
適當的安全措施： 守門人以有限權限模式運作，而應用程式其餘部分則以存取儲存與服務所需的完整信任模式運作。 如果閘道守衛遭到入侵，則無法直接存取應用程式服務或數據。
此模式就像一般網路地形中的防火牆一樣。 與傳統防火牆不同，它允許守門人詳細檢視請求，並以應用程式驅動的決策決定是否將請求轉交給執行所需任務的受信任主機。 此決策通常要求守門人在請求內容交給受信任主機前，先驗證並消毒該請求內容。 守門人可能會授權請求、尋找意外或無效的有效載荷內容、執行速率限制，以及執行各種其他檢查。
問題和考慮
在決定如何實施此模式時，請考慮以下幾點：
確保受信任的主機只暴露只有閘門管理員使用的內部或受保護端點。 信任的主機不應該公開任何外部端點或介面。
守門人必須以有限權限模式運行。 實務上，將守門人與受信任後端分別設於不同的計算邊界，並保持後端端點私密。
守門人不應該執行與應用程式或服務相關的處理，也不應該存取資料。 其功能純粹是驗證並淨化請求。 受信任主機可能需要額外執行請求驗證，但閘門管理員應該執行核心驗證。
在守門人與受信任主機或任務之間，盡可能使用安全通訊通道，如 HTTPS、安全套接層層（SSL）或傳輸層安全（TLS）。 不過，某些主控環境不支持內部端點上的 HTTPS。
新增一層實作 Gatekeeper 模式，可能會因額外的處理與網路通訊而影響效能。
閘道器可能成為單點故障（SPoF）。 為了減少失敗的影響，可以考慮部署冗餘實例並使用自動擴展機制來確保容量並維持可用性。
使用此模式的時機
當下列情況時，請使用此模式：
你負責敏感資訊。
你對外提供的服務需要嚴密防護，以抵禦惡意流量。
你執行的是關鍵任務作業，不能容許後端服務直接暴露。
你需要將請求驗證與淨化與核心業務處理分離。
在下列情況下，此模式可能不適用：
你可以透過後端服務內建的平台控制來滿足安全與驗證需求，而無需新增專門的守門人層。
新增的網路跳數與驗證延遲違反嚴格的端對端延遲要求。
工作負載設計
評估如何在工作負載設計中使用守門人模式，以達成Azure Well-Architected框架支柱所涵蓋的目標與原則。 下表提供此模式如何支援每個要素目標的指引。
| 支柱 | 此模式如何支援支柱目標 |
|---|---|
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 請求流程中的守門人協助你集中管理安全功能，如網頁應用防火牆、DDoS防護、機器人偵測、請求操作、驗證啟動及授權檢查。 - SE：06 網路控制 - SE：10 監視和威脅偵測 |
| 效能效率 可透過調整、數據和程式碼的優化， 有效率地協助您的工作負載符合需求 。 | 你可以用這個模式在守門人層級實作限速，而不是在節點層級實作速率檢查。 所有節點之間的速率狀態協調本身並不具備一定的效能。 - PE：03 精選服務 |
如果此模式在一個支柱內部引入取捨，請將它們與其他支柱的目標進行考量。
Example
Gatekeeper 模式通常實作分層請求路徑，每層有特定責任與有限的信任範圍。
下載此架構的 Visio 檔案 。
在此設計中，Azure 應用程式閘道 與 Azure Web 應用程式防火牆 是外層守門人。 它會檢查面向網際網路的流量，並在流量到達 API 層級前施加安全控管。 Azure API 管理 是內部守門人。 它會套用 API 專屬的控制，並且只會將核准的流量轉發到私有後端。
例如，Azure Web 應用程式防火牆 能偵測並阻擋 SQL 注入與跨站腳本模式，強制執行協定與請求大小規則，並在請求進入 API 管理或私有後端前，套用機器人與 IP 過濾。
當你在內層使用 API Management 時，它會對閘道管線中的入站請求和出站回應套用政策。 欲了解更多關於 API 管理如何處理請求與回應的資訊，請參閱 API Management 中的政策。 關於 JSON Web Token （JWT） 驗證、速率限制、標頭轉換及回應整形等政策選項，請參閱 API 管理政策參考。
在此路徑中，進行服務對服務驗證時，應一致使用 Azure 資源的受控識別。 例如，API 管理可以使用 authentication with managed identity policy 來取得後端呼叫的 Microsoft Entra token，且不儲存秘密。
後端維持不對外公開。 例如，後端可以是 Azure App 服務 應用程式，使用 private endpoint，因此該應用程式可以私密存取。
對於容器化工作負載，另一種替代方案可以以基於入口的運算取代 API Management 加上 App Service 的內部路徑：
Azure Kubernetes Service (AKS)，讓你能更好地控制入口控制器的選擇、Kubernetes 政策、網路拓撲和叢集操作。
Azure 容器應用程式，這是一個無伺服器管理的容器平台，提供入口功能並減少基礎設施管理。
在這些替代方案中，入口可依主機或路徑路由、終止 TLS，並暴露僅限內部服務。 具體功能如請求限制及允許或拒絕規則，取決於所選入口實作。 無論如何，都要維持守門人邊界：在入口處執行驗證與政策執行，並讓後端服務只能透過該守門人路徑存取。
這條路徑的每一層都會產生日誌和指標，你應該集中管理。 Azure Web 應用程式防火牆 的診斷日誌記錄每個請求匹配與被阻擋的規則。 API 管理會發布閘道日誌，記錄請求長度、回應代碼及政策結果。 後端服務會發出應用層級的遙測資料。 將這些日誌和指標收集到
下一步
以下指引在你實施此模式時可能有參考價值：
相關資源
以下雲端設計模式常與 Gatekeeper 模式一起使用：