閘道守衛模式

使用專用主機實例來保護應用程式和服務，以代理用戶端與應用程式或服務之間的要求。 訊息代理程式會驗證並清理要求，並提供額外的安全性層級，並限制系統的受攻擊面。

內容和問題

雲端服務會公開可讓用戶端應用程式呼叫其 API 的端點。 用來實作 API 觸發程式或執行數項工作的程式代碼，包括但不限於驗證、授權、參數驗證，以及部分或所有要求處理。 API 程式代碼可能會代表用戶端存取記憶體和其他服務。

如果惡意使用者入侵系統並取得應用程式主控環境的存取權，則會公開其安全性機制及數據和其他服務的存取權。 因此，惡意使用者可以取得認證、記憶體密鑰、敏感性資訊和其他服務的不受限制存取權。

解決方案

此問題的其中一個解決方案是將實作公用端點的程式代碼與處理要求和存取記憶體的程式代碼分離。 您可以使用外觀或與客戶端互動的專用工作來達成分離，然後透過分離介面將要求交給處理要求的主機或工作。 此圖提供此模式的高階概觀。

閘道守衛模式可用來保護記憶體，也可以做為更全面的外觀來保護應用程式的所有功能。 重要因素包括：

• 受控制的驗證。 閘道守衛會驗證所有要求，並拒絕不符合驗證需求的要求。
• 風險和風險有限。 閘道守衛無法存取受信任主機用來存取記憶體和服務所使用的認證或密鑰。 如果閘道守衛遭到入侵，攻擊者就無法存取這些認證或密鑰。
• 適當的安全性。 閘道守衛會以有限的許可權模式執行，而應用程式的其餘部分則以存取記憶體和服務所需的完全信任模式執行。 如果閘道守衛遭到入侵，則無法直接存取應用程式服務或數據。

此模式就像一般網路地形中的防火牆一樣。 它可讓閘道守衛檢查要求，並決定是否要將要求傳遞給執行必要工作的受信任主機。 此決策通常需要閘道守衛先驗證並清理要求內容，再將其傳遞至信任的主機。

問題和考量

當您決定如何實作此模式時，請考慮下列幾點：

• 請確定信任的主機只會公開內部或受保護的端點，且僅由網關守衛使用。 信任的主機不應該公開任何外部端點或介面。
• 網關守衛必須以有限的許可權模式執行，這通常需要在不同的託管服務或虛擬機中執行網關守衛和受信任的主機。
• 網關守衛不應該執行與應用程式或服務相關的任何處理，或存取任何數據。 其函式純粹是用來驗證和清理要求。 受信任的主機可能需要執行額外的要求驗證，但閘道守衛應該執行核心驗證。
• 盡可能使用閘道與受信任主機或工作之間的安全通道（HTTPS、SSL 或 TLS）。 不過，某些主控環境不支持內部端點上的 HTTPS。
• 新增額外的層以實作閘道守衛模式，可能會因為需要額外的處理和網路通訊而影響效能。
• 閘道守衛實例可以是單一失敗點。 若要將失敗的影響降到最低，請考慮部署備援實例，並使用自動調整機制確保容量維持可用性。

使用此模式的時機

此模式對於下列應用程式很有説明：

• 處理敏感性資訊
• 公開需要高度保護的服務，以免遭受惡意攻擊
• 執行無法中斷的任務關鍵性作業。
• 要求驗證需要與主要工作分開執行，或集中進行此驗證以簡化維護和管理

工作負載設計

架構設計人員應該評估閘道守衛模式如何用於其工作負載的設計，以解決 Azure 架構架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

範例

在雲端裝載的案例中，此模式可以藉由將閘道守衛角色或虛擬機與應用程式中的信任角色和服務分離來實作。 實作可以使用內部端點、佇列或記憶體作為中繼通訊機制。 此圖說明如何使用內部端點。

相關資源

實 作 Gatekeeper 模式時，代客密鑰模式 也可能相關。 在 Gatekeeper 與信任角色之間進行通訊時，最好是使用限制存取資源的密鑰或令牌來增強安全性。 此模式描述使用令牌或密鑰，以提供用戶端對特定資源或服務的限制、直接存取。