建置分割策略的建議
適用于 Well-Architected Framework 安全性檢查清單建議:
SE:04 | 在您的架構設計中建立刻意的分割和周邊,以及平臺上工作負載的使用量。 分割策略必須包含網路、角色和責任、工作負載身分識別和資源組織。 |
---|
區段是解決方案的邏輯區段,需要以一個單位來保護。 分割策略會定義一個單位與另一個單位的分隔方式,以及其本身的安全性需求和量值。
本指南說明 建置統一分割策略的建議。 在工作負載中使用周邊和隔離界限,您可以設計適合您的安全性方法。
定義
詞彙 | 定義 |
---|---|
Containment | 如果攻擊者取得區段的存取權,則為包含暴增半徑的技術。 |
最低許可權存取 | 零信任原則,旨在將一組許可權降到最低,以完成作業函式。 |
周邊 | 區段周圍的信任界限。 |
資源組織 | 依區段內的流程分組相關資源的策略。 |
角色 | 完成作業函式所需的一組許可權。 |
區段 | 與其他實體隔離且受到一組安全性措施保護的邏輯單元。 |
主要設計策略
分割的概念通常用於網路。 不過,在解決方案中可以使用相同的基礎準則,包括分割管理用途的資源和存取控制。
分割可協助您設計安全性方法,以根據零信任模型的原則來深入套用防禦。 確定違反某個網路區段的攻擊者無法透過分割具有不同身分識別控制項的工作負載來存取另一個網路區段。 在安全系統中,身分識別和網路屬性會封鎖未經授權的存取,並隱藏資產不受公開。 以下是區段的一些範例:
- 隔離組織工作負載的訂用帳戶
- 隔離工作負載資產的資源群組
- 依階段隔離部署的部署環境
- 與工作負載開發和管理相關的工作功能隔離的小組和角色
- 依工作負載公用程式隔離的應用程式層
- 將某個服務與另一個服務隔離的微服務
請考慮分割的下列重要元素,以確定您正在建置深度防禦策略:
界限或周邊是您套用安全性控制之區段的進入邊緣。 除非明確允許,否則周邊控制項應該封鎖對區段的存取。 目標是防止攻擊者中斷周邊並控制系統。 例如,應用層可能會在處理要求時接受使用者的存取權杖。 但 資料 層可能需要具有特定許可權的不同存取權杖,而只有應用層可以要求。
內含專案 是區段的結束邊緣,可防止系統中橫向移動。 內含專案的目標是將缺口的效果降到最低。 例如,Azure 虛擬網路可用來設定路由和網路安全性群組,只允許您預期的流量模式,以避免流量流向任意網路區段。
隔離 是將具有類似保證的實體分組在一起,以使用界限來保護實體的做法。 目標是輕鬆管理和環境中攻擊的內含專案。 例如,您可以將與特定工作負載相關的資源分組為一個 Azure 訂用帳戶,然後套用存取控制,讓只有特定工作負載小組可以存取訂用帳戶。
請務必注意周邊與隔離之間的差異。 周邊是指應該檢查的位置點。 隔離是關於群組。 一起使用這些概念主動包含攻擊。
隔離並不表示在組織中建立定址接收器。 統一的分割策略提供技術小組之間的一致性,並設定清楚的責任線。 Clarity可降低人為錯誤和自動化失敗的風險,這可能會導致安全性弱點、作業停機或兩者。 假設在複雜企業系統的元件中偵測到安全性缺口。 請務必讓每個人都瞭解負責該資源的人員,讓適當的人員包含在分級小組中。 組織和專案關係人可以藉由建立和記錄良好的分割策略,快速識別如何回應不同類型的事件。
取捨:分割會產生複雜度,因為管理有額外負荷。 成本也有取捨。 例如,當並存執行的部署環境已分割時,會布建更多資源。
風險:超出合理限制的微分割會失去隔離的優點。 當您建立太多區段時,很難識別通訊點,或允許區段內有效的通訊路徑。
以身分識別作為周邊
各種身分識別,例如人員、軟體元件或裝置存取工作負載區段。 身分識別是一種周邊,應該是主要防禦線,可 跨隔離界限進行驗證和授權存取,不論存取要求的來源為何。 使用身分識別作為周邊,以:
依角色指派存取權。 身分識別只需要存取執行其工作所需的區段。 藉由瞭解要求身分識別的角色和責任,將匿名存取降至最低,讓您知道要求區段存取權的實體,以及為了何種目的。
身分識別在不同的區段中可能有不同的存取範圍。 請考慮一般環境設定,每個階段都有個別的區段。 與開發人員角色相關聯的身分識別具有開發環境的讀寫許可權。 當部署移至預備階段時,這些許可權會受到限制。 在工作負載升級為生產環境時,開發人員的範圍會減少為唯讀存取。
請個別考慮應用程式和管理身分識別。 在大部分的解決方案中,使用者具有與開發人員或操作員不同的存取層級。 在某些應用程式中,您可以針對每種身分識別類型使用不同的身分識別系統或目錄。 請考慮使用存取範圍,並為每個身分識別建立個別的角色。
指派最低許可權存取權。 如果允許存取身分識別,請判斷存取層級。 請從每個區段的最低許可權開始,並視需要擴大該範圍。
藉由套用最低許可權,您會在身分識別遭到入侵時限制負面影響。 如果存取受限於時間,則會進一步減少受攻擊面。 限時存取特別適用于重要帳戶,例如具有遭入侵身分識別的系統管理員或軟體元件。
取捨:工作負載的效能可能會受到身分識別周邊的影響。 確認每個要求明確需要額外的計算週期和額外的網路 IO。
角色型存取控制 (RBAC) 也會導致管理額外負荷。 追蹤身分識別及其存取範圍在角色指派中可能會變得複雜。 因應措施是將角色指派給安全性群組,而不是個別身分識別。
風險:身分識別設定可能十分複雜。 設定錯誤可能會影響工作負載的可靠性。 例如,假設有設定錯誤的角色指派拒絕存取資料庫。 要求開始失敗,最終會導致在執行時間之前偵測到無法偵測到的可靠性問題。
如需身分識別控制項的相關資訊,請參閱 身分識別和存取管理。
相較于網路存取控制,身分識別會在存取時驗證存取控制。 強烈建議您進行定期存取權檢閱,並要求核准工作流程以取得重大影響帳戶的許可權。 例如,請參閱 身分識別分割模式。
網路作為周邊
身分識別周邊與網路無關,而網路周邊會增強身分識別,但永遠不會取代。 已建立網路周邊,以控制非預期、禁止和不安全的存取,以及混淆工作負載資源。
雖然身分識別周邊的主要焦點是最低許可權,但當您設計網路周邊時,應該假設會有缺口。
使用 Azure 服務和功能,在您的網路使用量中建立軟體定義的周邊。 當工作負載 (或特定工作負載的一部分) 放入個別區段時,您可以 控制這些區段的流量,以保護通訊路徑的安全。 如果區段遭到入侵,則會包含並防止橫向分散到您網路的其餘部分。
想像攻擊者在工作負載內達到腳點,並建立控制,以將進一步擴充降至最低。 控制項應該偵測、包含及阻止攻擊者取得整個工作負載的存取權。 以下是網路控制作為周邊的一些範例:
- 定義公用網路與工作負載放置所在的網路之間的邊緣周邊。 盡可能限制從公用網路到您網路的視線。
- 在應用程式前面實作非目的地區域 (DMZ) ,並透過防火牆進行適當的控制。
- 在私人網路內建立微分割,方法是將工作負載的各個部分分組成不同的區段。 建立它們之間的安全通訊路徑。
- 根據意圖建立界限。 例如,從作業網路區隔工作負載功能網路。
如需與網路分割相關的常見模式,請參閱 網路分割模式。
取捨:網路安全性控制通常很昂貴,因為它們隨附于進階 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 Virtual WAN中樞部署中部署。 使用Azure 防火牆篩選雲端資源、網際網路和內部部署資源之間的流量。 使用Azure 防火牆或Azure 防火牆管理員來建立規則或原則,以允許或拒絕使用第 3 層到第 7 層控制項的流量。 使用Azure 防火牆和協力廠商篩選網際網路流量,方法是透過協力廠商安全性提供者將流量導向,以進行進階篩選和使用者保護。 Azure 支援網路虛擬裝置部署,這有助於從協力廠商防火牆進行分割。
範例
以下是在 Azure 中分割工作負載的一些常見模式。 根據您的需求選擇模式。
此範例是以在安全性基準中建立的資訊技術 (IT) 環境為基礎 , (SE:01) 。 下圖顯示組織所完成之管理群組層級的分割。
身分識別分割模式
模式 1:以職稱為基礎的群組
組織安全性群組的其中一種方式是軟體工程師、資料庫管理員、網站可靠性工程師、品質保證工程師或安全性分析師等職稱。 這種方法牽涉 到根據工作負載小組的角色建立安全性群組 ,而不需要考慮需要完成的工作。 根據工作負載中的責任,授與安全性群組 RBAC 許可權、常設或即時 (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 中的擁有者角色,可讓使用者將資源的存取權授與其他使用者。 限制指派擁有者角色的使用者或群組數目,並定期檢閱稽核記錄,以確保他們只執行有效的作業。
相關連結
安全性檢查清單
請參閱一組完整的建議。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應