數據中心里的虛擬機（VM）越來越多，VM之間流量交換的安全風險開始成為管理員的新麻煩。繼上期闡述安全產品與安全管理平臺的變化后，本期聚焦云時代虛擬化環境下對安全的需求以及相應技術方案的發展。
一、 云計算時代虛擬化環境下的安全需求
虛擬化是目前云計算最為重要的技術支撐，需要整個虛擬化環境中的存儲、計算及網絡安全等資源的支持。在這個方面，基于服務器的虛擬化技術走在了前面，已開始廣泛的部署應用。基于該虛擬化環境，系統的安全威脅和防護要求也產生了新的變化：
傳統風險依舊，防護對象擴大
一方面，一些安全風險并沒有因為虛擬化的產生而規避。盡管單個物理服務器可以劃分成多個虛擬機，但是針對每個虛擬機，其業務承載和服務提供和原有的單臺服務器基本相同，因此傳統模型下的服務器所面臨的問題虛擬機也同樣會遇到，諸如對業務系統的訪問安全、不同業務系統之間的安全隔離、服務器或虛擬機的操作系統和應用程序的漏洞攻擊、業務系統的病毒防護等；另一方面，服務器虛擬化的出現，擴大了需要防護的對象范圍，如IPS入侵防御系統就需要考慮以Hypervisor和vCenter為代表的特殊虛擬化軟件，由于其本身所處的特殊位置和在整個系統中的重要性，任何安全漏洞被利用，都將可能導致整個虛擬化環境的全部服務器的配置混亂或業務中斷。
VM之間產生新安全訪問風險
和傳統的安全防護不同，虛擬機環境下同一個服務器上不同的VM可能屬于同一個物理VLAN內，如果相鄰VM之間的流量交換不通過外部交換機，而是基于服務器內部的虛擬交換網絡解決，此時在不可控的情況下，網絡管理員將面臨兩個新的安全問題（如圖1所示）：
1）如何判斷VM之間的二層流量交換是規則允許范圍內的合法訪問還是非法訪問？
2）更進一步，即使不同VM之間的流量允許交換，如何判斷這些流量是否存在諸如針對應用層安全漏洞的網絡攻擊行為？
圖1 VM虛擬機之間的安全風險
二、 虛擬化環境下安全防護的方法
在利用現有的經驗模型解決好當前存在的普遍性安全威脅后，現階段虛擬化環境下的安全防護還需要重點考慮VM之間的流量安全。分析流量的轉發路徑，我們可以將用戶流量劃分成縱向流量和橫向流量兩個維度，并基于每個維度的安全需求提供有針對性的解決方案。
1.縱向流量的安全防護
這部分縱向流量包括從客戶端到服務器側的正常流量訪問請求，以及不同VM之間的三層轉發的流量。這些流量的共同特點是其交換必然經過外置的硬件安全防護層，我們也稱之為縱向流量控制層，流量模型如圖2所示。
圖2 縱向流量模型的主要內容
一方面，這些流量的防護方式，和傳統的數據中心的安全防護相比沒有本質區別，用戶可以直接借鑒原有經驗進行。如防護的設備類型仍然是以防火墻和入侵防御系統等產品為主，在部署的方式上要求防火墻或入侵防御設備具備INLINE阻斷安全攻擊的能力，部署的位置可以旁掛在匯聚層或者是串接在核心層和匯聚層之間，同時對于設備的性能可擴展和穩定性等常規指標也完全適用。如圖3所示。
另一方面，在虛擬化環境下的云安全部署，因為可能存在多租戶*的服務模型，因此對于設備的虛擬化實現程度又有了更高的要求，除了常規的虛擬化實例進行轉發隔離和安全策略獨立配置外，還要求實現對于不同租戶的獨立的資源管理配置和策略管理.每個虛擬實例的管理員可以隨時監控、調整本租戶的策略的配置實現情況等。這些新的技術要求，對于虛擬化環境下的縱向流量防護有著重要的影響。
2. 橫向流量安全防護
VM之間的橫向流量安全是在虛擬化環境下產生的特有問題，在這種情況下，同一個服務器的不同VM之間的流量將直接在服務器內部實現交換，導致外層網絡安全管理員無法對這些流量進行監控或者實施各種高級安全策略如防火墻規則或者入侵防御規則。圖4展示了橫向安全防護重點關注的流量模型。
在服務器的虛擬化過程中，以VMware為代表的虛擬化廠商，通過在服務器Hypervisor層集成vSwitch虛擬交換機特性，也可以實現一些基本的訪問允許或拒絕規則，但是并沒有也很難集成更高級的安全檢測防護引擎，以實現VM之間的流量漏洞攻擊的行為檢測。要做到更深度的安全檢測，目前主要有兩種技術方式：基于虛擬機的安全服務模型，以及利用EVB技術實現流量重定向的安全檢測模型，如圖5所示。
基于虛擬機的安全防護
在虛擬化技術推進的過程中，一些廠商很敏銳的觀察到了VM之間直接交換流量無法通過外部防火墻等設備進行檢測，因此想通過直接在服務器內部部署虛擬機安全軟件，通過對VMware開放的API接口的利用，將所有VM之間的流量交換在進入到vSwitch之前，先引入到虛擬機安全軟件進行檢查。此時可以根據需求將不同的VM劃分到不同的安全域，并配置各種安全域間隔離和互訪的策略。同時，一些技術能力強的軟件廠商，還考慮在軟件中集成IPS深度報文檢測技術，判斷VM之間的流量交換是否存在漏洞攻擊。這種方式的優點是部署比較簡單，只需要在服務器上開辟資源并運行虛擬機軟件運行即可，但是其不足之處也很明顯：
不足一：每個服務器需要有專門的資源來安裝該軟件，服務器流量越大，開啟的功能如IPS深度檢測越多，對系統的資源占用就越大，不僅可能影響其它VM的性能，同時也導致服務器投資的增加；以常見的酷睿2雙核雙CPU服務器【4核】為例，虛擬化情況下服務器的CPU利用率得到有效提升，對外可以提供的應用吞吐量有望達到800Mbps以上；同時根據現有的經驗，基于雙核CPU處理器的IPS應用其吞吐量維持在300Mbps左右；可以預見：如果利用該服務器進行虛擬化劃分并使能安全虛擬機軟件的話，至少需要劃分出2個核來做安全虛擬機，才可以保證對300M的流量進行深度報文檢測，而真正的應用虛擬機將只能利用剩余的2個核，這也意味著整個服務器的吞吐量將下降到300Mbps左右；要達到原定的應用交付性能，用戶必須部署更多的服務器才能滿足要求。
不足二：由于該防護模型需要安全軟件廠商在Hypervisor層進行代碼開發，其開發水平的差異將導致Hypervisor出現潛在的安全漏洞，并危及到整個虛擬機的正常運轉。可以預見虛擬化廠商將不可能完全開放該API接口，這也意味著只有很少的廠商才能獲得虛擬化廠商的許可并進行嚴格受控的軟件集成；目前我們并沒有看到具有影響力的安全廠商的成熟的虛擬化產品，整個生態系統未來如何發展將取決于虛擬機廠商對于API的開放程度以及安全軟件廠商的成熟的開發能力，這些都存在很大的不確定性。
既然VM之間的流量交換一直在服務器內部，不利于安全策略的部署，也不利于管理界限的明晰，因此正在進行標準化EVB技術，計劃通過VEPA等技術實現將這些流量引入到外部的交換機。在接入交換機轉發這些流量之前，可以通過鏡像或者重定向等技術，將流量先引入到專業的安全設備進行深度報文檢查、安全策略配置或是允許/拒絕其訪問。
這種實現方式的優點在于外置硬件安全設備的高性能，在不損失服務器能力的情況下，可以使用數目較少的高端安全設備來實現萬兆甚至十萬兆的安全檢測能力,管理員也可以充分利用先前的經驗，很容易實現對這些外置安全設備的管理維護。同時因為該標準的相對開放性，相關的網絡安全廠商都可以參與到這個方案當中來，減少了客戶對于單一網絡安全廠商的依賴。
對于該方式下安全策略跟隨VM遷移的問題，在網絡管理組件及時感知到VM虛擬機遷移時，通過內部的消息傳送，安全管理組件可以及時獲取到此次遷移的相關參數如新的接入交換機ID及端口VLAN等屬性；此時再比對自身保存的拓撲關系圖定位到新的虛擬機遷移位置所對應的安全產品ID，從而實現虛擬機的安全策略profile的遷移，這也是一種簡單易行的解決方案。如表1對比了兩種方式的差異。
三、結束語
綜上所述，現階段基于虛擬機的安全軟件部署方式，在小型的虛擬化環境中，更容易得到較好的用戶體驗，但是在大規模高性能的應用環境中，基于高性能的專業硬件設備來搭建安全防護層，更容易滿足對性能的要求，在總的投資上也更有優勢。未來一段時間內，這兩種方式將作為主要的技術方式而存在，用戶可以根據自身的實際應用環境進行選擇。