建置分割策略的建議
適用於架構完善的架構安全性檢查清單建議:
SE:04 | 在您的架構設計和平臺上的工作負載使用量中,建立刻意的分割和周邊。 分割策略必須包含網路、角色和責任、工作負載身分識別和資源組織。 |
---|
區段是解決方案的邏輯區段,需要以一個單位的形式加以保護。 分割策略會定義一個單位應該如何與其他單位區隔,以及其本身的安全性需求和量值。
本指南說明建置統一分割策略的建議。 在工作負載中使用周邊和隔離界限,您可以設計適合您的安全性方法。
定義
詞彙 | 定義 |
---|---|
Containment | 如果攻擊者取得區段的存取權,則為包含爆炸半徑的技術。 |
最低許可權存取 | 零信任 原則,旨在將一組許可權降到最低,以完成作業功能。 |
周邊 | 區段周圍的信任界限。 |
資源組織 | 依區段內的流程分組相關資源的策略。 |
角色 | 完成作業函式所需的一組許可權。 |
區段 | 與其他實體隔離並受到一組安全性措施保護的邏輯單元。 |
關鍵設計策略
分割的概念通常用於網路。 不過,在解決方案中可以使用相同的基本原則,包括分割用於管理用途和訪問控制的資源。
分割可協助您設計安全性方法,以根據 零信任 模型的原則來深入套用防禦。 請確定入侵某個網路區段的攻擊者無法透過分割具有不同身分識別控件的工作負載來存取另一個網路區段。 在安全系統中,身分識別和網路屬性會封鎖未經授權的存取,並隱藏要公開的資產。 以下是區段的一些範例:
- 隔離組織工作負載的訂用帳戶
- 隔離工作負載資產的資源群組
- 依階段隔離部署的部署環境
- 隔離與工作負載開發和管理相關作業功能的Teams和角色
- 依工作負載公用程式隔離的應用程式層
- 將一個服務與另一個服務隔離的微服務
請考慮分割的這些重要元素,以確保您正在建置完整的深度防禦策略:
界限 或周邊 是您套用安全性控制之區段的進入邊緣。 除非明確允許,否則周邊控件應封鎖對區段的存取。 目標是防止攻擊者突破周邊並取得系統的控制權。 例如,應用層可能會在處理要求時接受使用者的存取令牌。 但是數據層可能需要具有特定許可權的不同存取令牌,只有應用層才能要求。
內含專案 是區段的結束邊緣,可防止系統中橫向移動。 內含項目的目標是將缺口的效果降到最低。 例如,Azure 虛擬網路可用來設定路由和網路安全組,只允許您預期的流量模式,避免流量流向任意網路區段。
隔離 是將具有類似保證的實體群組在一起,以使用界限來保護實體的做法。 目標是簡化管理,以及環境中攻擊的內含。 例如,您可以將與特定工作負載相關的資源分組為一個 Azure 訂用帳戶,然後套用訪問控制,讓只有特定的工作負載小組可以存取訂用帳戶。
請務必注意周邊與隔離之間的差異。 周邊是指應檢查的位置點。 隔離是關於群組。 一起使用這些概念,主動包含攻擊。
隔離並不表示在組織中建立尋址接收器。 統一的分割策略提供技術小組之間的一致性,並設定明確的責任線。 釐清可降低人為錯誤和自動化失敗的風險,進而造成安全性弱點、作業停機時間或兩者。 假設在複雜企業系統的元件中偵測到安全性缺口。 請務必讓每個人都瞭解誰負責該資源,讓適當的人員包含在分級小組中。 組織和項目關係人可以藉由建立並記錄良好的分割策略,快速識別如何回應不同類型的事件。
取捨:分割引進複雜度,因為管理上有額外負荷。 成本也有取捨。 例如,當並行執行的部署環境分割時,會布建更多資源。
風險:超出合理限制的微分割會失去隔離的好處。 當您建立太多區段時,很難識別通訊點,或允許區段內有效的通訊路徑。
將身分識別建立為主要安全性周邊
各種身分識別,例如人員、軟體元件或裝置存取工作負載區段。 身分識別是一個周邊,應該是主要防禦線,以 驗證和授權跨隔離界限的存取,不論存取要求的來源為何。 使用身分識別作為周邊,以:
依角色指派存取權。 身分識別只需要存取執行其工作所需的區段。 藉由瞭解要求身分識別的角色和責任,以將匿名存取降到最低,讓您知道要求存取區段的實體以及用途為何。
身分識別在不同的區段中可能會有不同的存取範圍。 請考慮一般環境設定,每個階段都有個別區段。 與開發人員角色相關聯的身分識別具有開發環境的讀寫許可權。 當部署移至預備階段時,會限制這些許可權。 當工作負載升階至生產環境時,開發人員的範圍會縮減為只讀存取。
請個別考慮應用程式和管理身分識別。 在大部分的解決方案中,使用者具有與開發人員或操作員不同的存取層級。 在某些應用程式中,您可能會針對每種身分識別類型使用不同的身分識別系統或目錄。 請考慮使用存取範圍,併為每個身分識別建立個別的角色。
指派最低許可權存取權。 如果允許存取身分識別,請判斷存取層級。 請從每個區段的最低許可權開始,並視需要擴大該範圍。
藉由套用最低許可權,您可以在身分識別遭到入侵時限制負面影響。 如果存取受限於時間,攻擊面會進一步降低。 限時存取特別適用於重要帳戶,例如具有遭入侵身分識別的系統管理員或軟體元件。
取捨:工作負載的效能可能會受到身分識別周邊的影響。 確認每個要求明確需要額外的計算週期和額外的網路IO。
角色型訪問控制 (RBAC) 也會導致管理額外負荷。 追蹤身分識別及其存取範圍可能會變得複雜於角色指派。 因應措施是將角色指派給安全組,而不是個別身分識別。
風險:身分識別設定可能相當複雜。 設定錯誤可能會影響工作負載的可靠性。 例如,假設有設定錯誤的角色指派,拒絕存取資料庫。 要求開始失敗,最終導致在運行時間之前無法偵測到的可靠性問題。
如需身分識別控件的相關信息,請參閱 身分識別和存取管理。
與網路訪問控制相反,身分識別會在存取時驗證訪問控制。 強烈建議您定期進行存取權檢閱,並要求核准工作流程取得重要影響帳戶的許可權。 例如,請參閱 身分識別分割模式。
使用網路作為周邊加強
身分識別周邊與網路無關,而網路周邊會增強身分識別,但絕不會取代它。 建立網路周邊以控制爆炸半徑、封鎖非預期、禁止和不安全的存取,以及模糊處理工作負載資源。
雖然身分識別周邊的主要焦點是最低許可權,但您應該假設在設計網路周邊時會有缺口。
使用 Azure 服務和功能,在您的網路使用量中建立軟體定義的周邊。 當工作負載(或特定工作負載的一部分)放入不同的區段時,您可以 控制來自或傳送到這些區段的流量,以保護通訊路徑的安全。 如果區段遭到入侵,則會包含該區段,並防止其橫向傳播到您網路的其餘部分。
請考慮攻擊者在工作負載內達到立足點,並建立控件以將進一步擴充降至最低。 控件應該偵測、包含和阻止攻擊者取得整個工作負載的存取權。 以下是網路控件作為周邊的一些範例:
- 定義公用網路與工作負載所在網路之間的邊緣周邊。 盡可能限制從公用網路到您網路的視線。
- 在應用程式前面實作非軍事區域,並透過防火牆進行適當的控制。
- 在專用網內建立微分割,方法是將工作負載的元件分組成不同的區段。 建立它們之間的安全通訊路徑。
- 根據意圖建立界限。 例如,從作業網路區隔工作負載功能網路。
如需與網路分割相關的常見模式,請參閱 網路分割模式。
取捨:網路安全性控制通常很昂貴,因為它們隨附於進階 SKU 中。 在防火牆上設定規則通常會導致需要廣泛例外狀況的壓倒性複雜度。
私人聯機會變更架構設計,通常會新增更多元件,例如用於私人存取計算節點的跳板方塊。
因為網路周邊是以控制點或躍點為基礎,因此在網路上,每個躍點可以是潛在的失敗點。 這些點可能會對系統的可靠性產生影響。
風險:網路控制是以規則為基礎,而且設定錯誤的可能性很大,這是可靠性問題。
如需網路控制的相關信息,請參閱 網路和連線能力。
定義角色並明確責任線
藉由 明確定義工作負載小組內的責任 線,即可達成防止混淆和安全性風險的分割。
記錄和共用角色和函式,以建立一致性並促進通訊。 指定負責重要函式的群組或個別角色。 在為物件建立自定義角色之前,請先考慮 Azure 中的內建角色。
在指派區段的許可權時,請考慮一致性,同時容納數個組織模型。 這些模型的範圍可以從單一集中式 IT 群組到大部分獨立的 IT 和 DevOps 小組。
風險:隨著員工加入或離開團隊或變更角色,群組的成員資格可能會隨著時間而變更。 跨區段的角色管理可能會導致管理額外負荷。
組織資源以促進分割
分割可讓您 隔離工作負載資源與組織 的其他部分,甚至是在小組內。 Azure 建構,例如管理群組、訂用帳戶、環境和資源群組,是組織促進分割之資源的方式。 以下是資源層級隔離的一些範例:
- Polyglot 持續性牽涉到數據儲存技術的組合,而不是支援分割的單一資料庫系統。 使用 polyglot 持續性來區分各種數據模型、區隔數據儲存和分析等功能,或以存取模式分隔。
- 組織計算時,為每個伺服器配置一個服務。 這種隔離等級可將複雜度降至最低,並有助於包含攻擊。
- Azure 提供某些服務的內建隔離,例如將計算與記憶體區隔開。 如需其他範例,請參閱 Azure 公用雲端中的隔離。
取捨:資源隔離可能會導致總擁有成本增加(TCO)。 針對數據存放區,災害復原期間可能會增加複雜度和協調。
Azure 便利化
某些 Azure 服務可用於實作分割策略,如下列各節所述。
身分識別
Azure RBAC 藉由隔離作業函式的存取,支援分割。 特定角色和範圍只允許特定動作。 例如,只需要觀察系統的作業函式可以指派讀取者許可權與允許身分識別管理資源的參與者許可權。
如需詳細資訊,請參閱 RBAC 的最佳做法。
網路
虛擬網路:虛擬網路提供資源的網路層級內含專案,而不需在兩個虛擬網路之間新增流量。 虛擬網路會在訂用帳戶內的私人位址空間中建立
網路安全組 (NSG):訪問控制機制,用於控制虛擬網路與外部網路的資源之間的流量,例如因特網。 實作使用者定義的路由 (UDR) 來控制流量的下一個躍點。 NSG 可以藉由建立子網、虛擬機 (VM) 或 VM 群組的周邊,將您的分割策略提升到細微層級。 如需有關 Azure 中子網可能作業的資訊,請參閱 子網。
應用程式安全組 (ASG):ASG 可讓您將一組 VM 分組在應用程式標籤下,並定義流量規則,然後套用至每個基礎 VM。
Azure 防火牆:可在虛擬網路或 Azure 虛擬 WAN 中樞部署中部署的雲端原生服務。 使用 Azure 防火牆 來篩選雲端資源、因特網和內部部署資源之間流動的流量。 使用 Azure 防火牆 或 Azure 防火牆 管理員來建立規則或原則,以允許或拒絕使用第 3 層對第 7 層控制件的流量。 使用 Azure 防火牆 和第三方篩選因特網流量,方法是透過第三方安全性提供者引導流量,以進行進階篩選和用戶保護。 Azure 支援 網路虛擬設備部署,這有助於從第三方防火牆進行分割。
範例
以下是在 Azure 中分割工作負載的一些常見模式。 根據您的需求選擇模式。
此範例是以安全性基準 (SE:01) 中建立的資訊技術 (IT) 環境為基礎。 下圖顯示組織所完成之管理群組層級的分割。
身分識別分割模式
模式 1:以職稱為基礎的群組
組織安全組的其中一種方式是職稱,例如軟體工程師、資料庫管理員、網站可靠性工程師、品質保證工程師或安全性分析師。 此方法牽涉到 根據工作負載小組 的角色建立安全組,而不需要考慮需要完成的工作。 根據他們在工作負載中的責任,授與安全組 RBAC 許可權、站立或 Just-In Time (JIT)。 根據所需的存取權,將人力和服務原則指派給安全組。
成員資格在角色指派層級高度可見,可讓您輕鬆查看角色可存取的內容。 每個人通常是只有一個安全組的成員,這讓上線和下線變得容易。 不過,除非職稱與責任完全重疊,否則以職稱為基礎的群組不適合使用最低許可權實作。 您最終可能會結合實作與以函式為基礎的群組。
模式 2:以函式為基礎的群組
函式群組是一種安全組組織方法,可反映需要完成的離散工作,而不考慮小組結構。 使用此模式時,您會 根據工作負載中所需的功能,授與安全組 RBAC 許可權、站立或 JIT。
根據所需的存取權,將人力和服務原則指派給安全組。 可能的話,請使用現有的同質群組作為函式群組的成員,例如來自模式 1 的群組。 以函式為基礎的群組範例包括:
- 生產資料庫運算符
- 生產前資料庫運算符
- 生產憑證輪替運算符
- 生產階段前憑證輪替運算符
- 生產即時網站/分級
- 生產前所有存取
此方法會維護最嚴格的最低許可權存取,並提供範圍顯而易見的安全組,這可讓您輕鬆地稽核與執行作業職責相關的成員資格。 內建的 Azure 角色通常會存在,以符合此作業函式。
不過,成員資格至少會抽象化一層,迫使您前往識別提供者,以瞭解從資源觀點查看群組中的人員。 此外,一個人必須維護多個成員資格,才能完整涵蓋範圍。 重疊安全組的矩陣可能相當複雜。
建議使用模式 2,讓存取模式成為焦點,而不是組織結構。 組織結構和成員角色有時會變更。 從功能觀點擷取工作負載的身分識別和存取管理,可讓您從工作負載的安全管理中擷取小組組織。
網路分割模式
模式 1:工作負載內的分割(軟界限)
在此模式中,工作負載會使用子網來標示界限,放在單一虛擬網路中。 分割是使用兩個子網來達成,一個用於資料庫,一個用於 Web 工作負載。 您必須設定允許子網 1 只與子網 2 和子網 2 通訊的 NSG,才能與因特網通訊。 此模式提供第 3 層控制件。
模式 2:工作負載內的分割
此模式是平臺層級分割的範例。 工作負載 component 會分散到多個網路,而不會在它們之間對等互連。 所有通訊都會透過做為公用存取點的媒介路由傳送。 工作負載小組擁有所有網路。
模式 2 提供內含專案,但具有虛擬網路管理和重設大小的複雜度。 這兩個網路之間的通訊會透過公用因特網進行,這可能會造成風險。 公用連線也有延遲。 不過,這兩個網路可以對等互連,藉由連接它們來建立較大的區段來中斷分割。 不需要其他公用端點時,應該執行對等互連。
考量 | 模式 1 | 模式 2 |
---|---|---|
線上和路由:每個區段的通訊方式 | 系統路由提供工作負載元件的默認連線能力。 任何外部元件都無法與工作負載通訊。 | 在虛擬網路內,與模式 1 相同。 在網路之間,流量會經過公用因特網。 網路之間沒有直接連線能力。 |
網路等級流量篩選 | 默認允許區段之間的流量。 使用 NSG 或 ASG 來篩選流量。 | 在虛擬網路內,與模式 1 相同。 在網路之間,您可以透過防火牆篩選輸入和輸出流量。 |
意外開啟公用端點 | 網路適配器 (NIC) 不會取得公用IP。 虛擬網路不會公開至因特網 API 管理。 | 與模式 1 相同。 想要在一個虛擬網路上開啟公用端點,可能會設定錯誤以接受更多流量。 |
資源組織
根據擁有權責任組織 Azure 資源
請考慮包含多個工作負載和共用服務元件的 Azure 資產,例如中樞虛擬網路、防火牆、身分識別服務和安全性服務,例如 Microsoft Sentinel。 整個資產的元件應根據其功能區域、工作負載和擁有權進行分組。 例如,共用的網路資源應該分組為單一訂用帳戶,並由網路小組管理。 專用於個別工作負載的元件應該位於自己的區段中,而且可能會根據應用層或其他組織原則進一步劃分。
藉由建立 RBAC 角色指派,授與管理個別區段內資源的存取權。 例如,雲端網路小組可能會獲得包含其資源的訂用帳戶的系統管理存取權,但不會授與個別工作負載訂用帳戶。
良好的分割策略可讓您輕鬆地識別每個區段的擁有者。 請考慮使用 Azure 資源標籤,向擁有者小組標註資源群組或訂用帳戶。
設定及檢閱訪問控制
明確定義資源的區段,根據需求授與適當的存取權。
當您定義訪問控制原則時,請考慮最低許可權的原則。 請務必區分 控制平面作業 (資源本身的管理)和數據 平面作業 (存取資源所儲存的數據)。 例如,假設您有一個工作負載,其中包含具有員工敏感性信息的資料庫。 您可以授與管理存取權給某些需要設定設定的使用者,例如資料庫備份或監視資料庫伺服器效能的使用者。 不過,這些使用者不應該能夠查詢儲存在資料庫中的敏感數據。 選取許可權,授與使用者執行其職責所需的最低範圍。 定期檢閱每個區段的角色指派,並移除不再需要的存取權。
注意
某些高許可權角色,例如 RBAC 中的擁有者角色,可讓使用者授與其他用戶資源存取權的能力。 限制指派擁有者角色的使用者或群組數量,並定期檢閱稽核記錄,以確保他們只會執行有效的作業。
相關連結
安全性檢查清單
請參閱一組完整的建議。