一文了解微分段應用場景與實現機制

在《零信任安全，從微分段做起》這篇文章中，我們介紹瞭如何透過微分段技術實現超融合環境下的“零信任”安全策略。同時，日趨顯著的“東西向”安全威脅和“等保 2.0”的落實都要求企業儘快在生產環境中實現虛擬機器間的安全保護策略。那麼， 為什麼企業需要將微分段納入現有網路安全策略？如何透過微分段保護實際生產場景中的資料安全？ 本文將聚焦以上兩個問題解讀微分段的作用與應用。

為什麼虛擬化環境中需要微分段？

1. 虛擬化環境的複雜性必然加大了安全管控的難度

在探討微分段的作用之前，我們需要了解虛擬化環境為基礎架構安全帶來了哪些新的挑戰。相較於基於物理伺服器的傳統架構，虛擬化環境中，一個物理伺服器上會執行多個虛擬機器，這就給資料中心內部構成帶來了三個主要變化：

這些變化不僅讓虛擬化環境變得複雜，也給新形勢下安全策略的編寫和管理出了一道難題：

2. “東西向”安全威脅已不再是“小題大做”

虛擬機器間的安全管理，也就是常說的“東西向”防禦，主要是在資料中心內部的伺服器、虛擬伺服器之間部署安全措施進行網路通訊的管理。

資料中心的安全設計中，普遍會在“南北向”關鍵通路上設定防火牆、入侵檢測 / 防禦、病毒查殺、防 DDoS 等一系列安全裝置和措施，來識別並攔截由資料中心外向內進行的攻擊。然而，“未知安全威脅”的種類和數量正在不斷增加，難免有些會因為技術或管理上的瑕疵而成功侵入某臺伺服器， 隨後 更容易順著防備薄弱的“東西向”通路快速擴散，造成資料中心內部的虛擬機器 / 伺服器連鎖淪陷。Apache Log4j 的遠端程式碼執行漏洞就是一個典型的例子：

由此可見， 虛擬化環境中的網路安全策略應充分保護“東西向”網路通訊安全，避免安全威脅在資料中心內部橫向擴散。

3. “等保 2.0”的客觀要求

隨著資料中心內部虛擬化比例越來越高，虛擬化環境安全風險越來越大，在 2019 年頒佈並實施的《資訊保安技術 網路安全等級保護基本要求 GB/T 22239 — 2019》（以下簡稱為“等保 2.0”）中，也明確將“虛擬機器之間的訪問控制”列為所有安全級別都應滿足的要求：

這就意味著， 所有需要透過等保 2.0 的企業系統，都必須滿足上述要求，來保障資料中心內部的通訊安全。微分段，即在任意虛擬機器之間都設定安全訪問控制的技術，是虛擬化環境中有效的、必應採用的安全機制。

微分段在實際生產場景中如何應用？

知易行難！在 SmartX 超融合中，是如何對生產環境進行高效率的東西向微分段呢？

1. 從“預設允許”到“預設拒絕”的轉變

現在經常採用的“明確拒絕、預設允許”安全策略（俗稱“黑名單”模式），只能防禦已知的攻擊，卻給未知安全威脅留了機會。而且，由於已知安全威脅數量不斷增加，因此需要為阻攔這些具有潛在危險的通訊制定很多安全策略。

而 SmartX 超融合環境下的安全策略基於“明確允許、預設拒絕”的邏輯（俗稱“白名單”模式），這也是“等保 2.0”中對訪問控制的明確要求。

在虛擬化環境中，物理伺服器的功能逐漸被拆分到不同虛擬伺服器上執行，每個虛擬伺服器需要對外暴露的協議埠屈指可數——只需明確允許對這幾個協議埠的訪問，便可滿足虛擬伺服器正常工作的要求，而其他埠上的通訊“預設拒絕”，就杜絕了來自未知安全漏洞的威脅—— 實現了“以最少數量的安全規則，最大限度保障通訊安全”的目標。

以 WannaCry 蠕蟲病毒舉例，它利用 Windows 作業系統 445 埠存在的漏洞，主要在主機 / 虛擬機器之間進行橫向擴散，並具有自我複製、主動傳播的特性，感染計算機後會向計算機中植入敲詐者病毒，導致電腦大量檔案被加密。當時普遍認為 Windows 系統的 445 埠主要在內網使用，沒什麼風險，因此這個埠上的通訊都被“預設允許”了；病毒一旦因某種偶然契機成功侵入了一臺 Windows 系統，就可以借 445 埠在內網進行橫向擴散，導致整個資料中心的 Windows 系統都被感染。

在啟用了虛擬機器之間的微分段機制之後， 只有經過“明確允許”的資料流才能夠到達虛擬機器，不再“預設允許”。假設某臺 Windows 虛擬機器是用作網頁和 FTP 伺服器的，那麼對它的安全規則只會包含“明確允許”這幾種協議，其他所有通訊（包括 445 埠）會被“預設拒絕”。這種安全配置模式下， 不僅外部威脅透過未知埠上侵入到內網的機率將大大降低，也避免了偶發的安全漏洞在資料中心內部被放大。

所以， SmartX 微分段安全策略對虛擬機器進行保護的基本原則就是“預設拒絕 ”， 只有經過管理員指定的通訊流可以到達 / 離開虛擬機器。

2. 用“看得懂”的方式簡化虛擬機器之間安全策略

要實現安全策略模式的轉變，為所有的虛擬機器的網路通訊制定“明確允許”的策略，這個工作量會不會太大？會不會導致安全管理過於複雜而無法運維？

上一小節的對比已經表明，對某一個虛擬伺服器而言，採用“白名單”模式所需的安全規則數量，會遠遠少於“黑名單”模式。那麼擴充套件到多個虛擬伺服器、擴充套件到整個資料中心 / 多個資料中心呢？

我們試想一下為如下場景編寫安全策略的工作量：

這些部門、系統、應用之間的複雜業務聯絡，確實有可能導致基於 IP 地址的安全規則數量爆炸式增長（參考上文配圖中的安全策略數量級），安全體系過於複雜而無法維護，亟需更好的方法對安全策略進行最佳化。

SmartX 超融合的微分段機制原生於自身的 ELF 虛擬化系統，允許管理員為每一個虛擬機器設定自定義的“標籤” 。這個“標籤”可以理解為虛擬機器的“別名”，比如：“HR 部門的虛擬機器”、“HR 專用檔案伺服器”等等。有了這些標籤，制定出來的安全策略就大大簡化了，就像是下面這樣：

為虛擬機器設定了標籤（比如， “HR 部門的虛擬機器” ），就意味著它 遵循“預設拒絕”原則，除了這些被“明確允許”的行為以外，其他的網路通訊都會被拒絕。

這樣的策略基於業務場景，比起使用一串 IP 地址編寫的安全規則更加容易被理解，而且規則條目也經過了彙總簡化。今後，即便這個應用環境發生了一些變化，比如：

以上這些場景下， 每個虛擬機器設定了“標籤”就會和對應的安全策略自動關聯 ，具有以下優點：

3. 對可疑虛擬機器進行“一鍵式”隔離

對於運維人員而言，沒有什麼安全措施是萬全的保障，必須提前備好在突發安全狀態下的緊急預案，才能對“萬一”發生的安全事件進行快速響應。SmartX 超融合的微分段功能，也包含了對於虛擬機器進行緊急隔離的技術方法。

具體來說，當管理員或安全運維中心（SOC）發現某個虛擬機器的行為異常，比如某個用作檔案伺服器的虛擬機器上的收 / 發流量突增，但所有普通使用者都無法連線到這個伺服器，此時就可以：

我們可以將超融合系統中的安全機制總結為兩個“常態”和一個“非常態”：

SmartX 微分段的內在機制

為什麼 SmartX 超融合可以實現虛擬化環境安全機制的徹底轉型？

1. “安全微分段”內生在超融合架構中

SmartX 的安全微分段內生於超融合作業系統，在每臺主機上執行專用程式，對虛擬機器之間的通訊流量進行直接管理。 要對一個或多個超融合叢集啟用安全微分段， 僅需在集中管理器上將此功能與對應的虛擬交換機進行關聯就可以。開啟後，虛擬機器之間的資料包被“允許”或“拒絕”動作，由叢集上的每臺主機分散式執行，優勢體現為：

這是對於整體架構影響最小的方式，也要求超融合系統具有過硬的自主核心技術才能實現。

2. CloudTower 實現統一安全管理

以上提到的虛擬機器管理、標籤管理、安全策略管理、虛擬機器隔離等安全運維操作，都可以在 SmartX 超融合系統的“管理中心”—— CloudTower ——上完成。CloudTower 是 SmartX 自主研發的多叢集管理軟體， 在同一個管理介面上即可對不同叢集上的虛擬機器、分散式儲存和安全微分段進行配置。虛擬機器即使發生了跨叢集的遷移，也仍然在原有 CloudTower 管理範圍內，虛擬機器標籤可以保持、與標籤關聯的安全策略也可以在不同叢集上被執行。

CloudTower 的管理任務可以透過圖形介面和 API 介面完成。管理員的人工操作主要在圖形介面上完成；API 介面可以對接獨立的“安全運維中心（SOC）”，按照 SOC 的指令完成超融合叢集內部的配置調整。而且，由於安全微分段機制完全不需要變更任何物理線路、不需要配置任何物理網路裝置， 因此可以實現基於 API 的安全管理智慧化和自動化 。

結語

企業建設資料中心的目的是為了提高數字化應用的服務質量和效率，部署相應的安全措施也是為了保障數字化服務的連續性。在外部和內部網路安全威脅越來越嚴重的情勢下，如果僅僅是簡單地累加安全裝置的種類和數量，有可能適得其反——不合理的安全措施會降低資料中心的效率、彈性、敏捷性和業務處理能力。

SmartX 基於自主研發的超融合系統， 透過在資料中心的虛擬機器之間部署分散式微分段安全機制，幫助使用者減輕、消除資料中心內部的東西向安全威脅，在執行效率和安全保障之間很好地實現了平衡， 特別適合於符合以下特點的虛擬化環境：