# 云計算設計模式（十）——守門員模式 通過使用充當客戶端和應用程序或服務之間的代理，驗證和進行消毒的請求，并將它們之間的請求和數據的專用主機實例保護的應用程序和服務。這可以提供一個額外的安全層，并限制了系統的攻擊面。 ## 背景和問題 應用程序通過接受和處理請求揭露它們的功能提供給客戶。在云托管方案，應用程序暴露終端客戶機連接，一般包括代碼來處理來自客戶端的請求。此代碼可以執行認證和驗證，一些或所有請求的處理，并有可能訪問存儲等服務代表客戶端的。 如果惡意用戶能夠危及系統和訪問應用程序的托管環境，它使用安全機制，諸如憑證和存儲密鑰，并且該服務并訪問數據，被暴露。因此，惡意用戶可能能夠獲得無節制訪問敏感信息和其他服務。 ## 解決方案 為了盡量減少接觸到敏感信息和服務客戶的風險，去耦，揭露出從處理請求并訪問存儲在代碼公共端點的主機或任務。這可以通過使用一個立面或專用任務，與客戶端進行交互，然后手拿開的請求（可能通過一個去耦接口）連接到主機或任務將要處理的請求來實現。圖1示出了這種方法的一個高層視圖。  圖1 - 這種模式的高級概述 守門員模式可以簡單地用來保護存儲，或者它可被用作一個更全面的立面，以保護所有的應用程序的功能。的重要因素是： - 控制驗證。守門員驗證所有請求，并拒絕那些不符合驗證要求。 - 有限的風險和曝光。守門員不具有訪問所使用的可信主機訪問存儲和服務的憑證或密鑰。如果關守被攻破，攻擊者無法獲得訪問這些憑據或密鑰。 - 適當的安全性。守門員運行在一個有限的特權模式，而應用程序的其余部分在訪問存儲和服務所需要的完全信任模式下運行。如果關守被破壞，它不能直接訪問應用程序的服務或數據。 此圖案有效地作用就像一個防火墻在一個典型的網絡拓撲。它允許關守來檢查請求并做出關于是否將請求傳遞到可信主機決定（有時也被稱為鑰匙之王），執行所需的任務。這一決定通常需要守門員來驗證并將其傳遞到受信任主機前消毒要求的內容。 ## 問題和注意事項 在決定如何實現這個模式時，請考慮以下幾點： - 確保受信任主機到網守請求通過僅暴露內部或保護端點，只有連接到守門員。受信任主機不應該暴露任何外部端點或接口。 - 關守必須在有限的特權模式下運行。通常，這意味著運行守門員和獨立的托管服務或虛擬機的可信主機。 - 關守不應該執行相關的應用程序或服務，或訪問任何數據的任何處理。它的功能是純粹的驗證和消毒要求。受信任的主機可能需要執行的請求額外的驗證，但核心的驗證應該由守門員進行。 - 使用守門員和信任的主機或任務，如果這是可能的之間的安全通信通道（HTTPS，SSL或TLS）。然而，一些托管環境可能不支持HTTPS內部端點。 - 添加額外的層，以實現守門員模式的應用有可能對應用程序的性能造成一定影響，由于它需要額外的處理和網絡通信。 - 關守實例可能是一個單點故障。為了最大限度地減少故障的影響，考慮部署其他實例，并使用自動縮放機制，以確保有足夠的能力來保持可用性。 ## 何時使用這個模式 這種模式非常適合于： - 應用程序，處理敏感信息，揭露必須具有高一定程度的保護免受惡意攻擊，或執行不得破壞關鍵業務服務。 - 分布式應用中，有必要從主要任務分別執行請求驗證，或集中此驗證，以簡化維護和管理。 ## 例子 在一個云托管的情況下，該模式可以通過使用一個內部端點，一個隊列，或存儲作為中間通信機制解耦從受信任的角色和服務應用程序中的關守角色或虛擬機來實現。圖 2 示出了使用內部的端點時的基本原則。  圖 2 - 的模式使用云服務的網絡和輔助角色的一個例子