發布時間：2016-01-14所屬分類：計算機職稱論文瀏覽：1次
摘 要： 在目前云計算新科技應用發展上有什么新的管理制度呢?同時現在計算新技術應用模式有什么轉變呢?本文是一篇計算機論文。我們也知道現在云計算是一個龐大而復雜的系統，這就使得我們可以在多個位置上尋找到合適的網絡流控制方法來解決安全隔離問題。我們需要先
在目前云計算新科技應用發展上有什么新的管理制度呢?同時現在計算新技術應用模式有什么轉變呢?本文是一篇計算機論文。我們也知道現在云計算是一個龐大而復雜的系統，這就使得我們可以在多個位置上尋找到合適的網絡流控制方法來解決安全隔離問題。我們需要先了解云計算的技術架構，才能夠更好地選擇適合的安全隔離方案。在云計算環境中，它的軟件系統的核心顯然是虛擬化平臺，而硬件環境的支持主要是實現虛擬化的硬件服務器和支撐整個云計算環境的網絡。安全作為云計算環境中的另外一個重要的組成部件，想要順利的集成進云計算這個系統中，無法避免將面臨三種技術選擇：與虛擬化平臺整合、與網絡環境整合或完全解耦合的獨立存在。
摘要： 在以虛擬化為主要技術平臺的云計算環境中，能夠提供有效可行的安全隔離方案，將直接決定整個云計算安全解決方案的安全防護能力。論文基于一般性的安全防護需求給出了一種較為通用的安全域規劃方法，并在此基礎上從虛擬機網絡驅動層、虛擬交換機層、虛擬機監控器網絡驅動層、二層物理網絡層、三層物理網絡層這五個不同的層面，針對可部署安全隔離防護設備的方案進行了深入的分析，比較了方案之間的優缺點，為用戶選擇合適的云安全隔離方案提供了有價值的參考。
關鍵詞：云計算;虛擬化;VLAN;Openflow;安全隔離,計算機論文
1 引言
隨著現在云計算市場競爭的激烈程度加劇以及用戶對云計算環境安全要求的提高，越來越多的集成商和云服務提供商開始注重基于其云計算環境的集成方案提供安全應用的接入接口，并以此作為其競標云計算集成方案的亮點之一。在云計算環境中實現網絡安全所要解決的一個重要技術問題就是對網絡安全域的邏輯劃分以及基于劃分的網絡安全域進行不同域間的隔離。用戶所使用不同的云平臺、采用不同集成商的方案、選用不同廠家的網絡設備，都將會使得云環境中的安全域及虛擬機間的隔離方案有所不同。本文將針對在不同層面實現云計算安全隔離的方案進行分析，對比各類技術方案的優劣以及其對不同云計算環境安全需求的適應性，為云計算使用者對云安全解決方案的選擇提供參考。
計算機論文：《計算機周刊》，《計算機周刊》1982年創刊，本刊集權威性、理論性與專業性于一體，具有很高的學術價值，是作者科研、晉級等方面的權威依據，歡迎廣大作者積極撰寫論文，踴躍投稿!征稿對象：全國高等學校、科研及推廣院所站、各級黨政機關、企事業單位的廣大專家學者、工程技術人員、碩士博士研究生、管理人員等。
2 控制網絡流的途徑
這里我們所說的隔離，并不是讓屬于不同安全域間的虛擬機完全無法相互訪問和通信，而是讓被劃分在不同的安全域邊界內的虛擬機間的通信必須經過相應的網絡安全設備的檢測和過濾，在網絡安全設備確認數據包安全后，跨安全域間的通信才能夠進行。這就對網絡安全提出了一個新的問題，即如何控制網絡流使之經過實現部署在云計算環境中的虛擬或物理的安全設備。這個問題我們可以從三個更具體的方面來分析。
第一，用戶的安全需求是什么。傳統網絡環境下，用戶通常關心的是出入一個物理網絡邊界的流量的網絡安全問題，這個邊界是物理存在的，比如連接接入交換機和匯聚交換機的一根網線。當外網的機器需要訪問內網機器時，是無法繞過這個邊界直接訪問，因此在傳統物理環境下，用戶的需求通常是對這個物理存在的邊界上流量的安全監控。在云計算環境中，整個網絡和其上所有虛擬機都存在于一個大二層的網絡環境中，為了實現邏輯上的隔離，通常使用劃分VLAN(或VXLAN)的方式來隔離具有不同安全需求的虛擬機，這時就出現了對虛擬機安全隔離的三種不同的安全需求：其一是只監控外網到云計算環境內部的通信;其二是只監控不同VLAN間的虛擬機間的通信(包含第一種需求);其三是需要監控任意兩臺虛擬機間的通信(包含前兩種需求)。
第二，網絡安全域的邊界如何劃分。為了從網絡層面保證虛擬機間的有效隔離，網絡安全域的劃分需要消除與VLAN間的多對一關系，即不能存在多個不同的網絡安全域劃分在同一個VLAN下的情況，這樣在這些不同網絡安全域間的虛擬機間的通信將可以通過虛擬交換機直接交換機而不被轉發到物理網絡上，使得安全監控產品的部署受到很大的局限性。
第三，安全設備的部署方式是什么。從安全設備的部署方式上，我們可以將其分為兩類：一類是透明部署在二層網絡環境中;另一類是以網關形式部署在三層網絡環境中。通常透明部署的方式更多的被應用在實際的生產環境中，因為透明部署將不需要修改用戶已有的業務網絡的配置。而將安全設以網關方式部署在三層網絡環境中的好處是，可以利用路由規則使得需要被監控的網絡流量經過安全設備。
綜合考慮以上三點，我們可以得出一個較為合理且應用較廣的云計算環境中的安全需求定義和規劃模型，即以VLAN劃分需要隔離的業務網絡，安全域的劃分需要消除安全域與VLAN間的多對一關系，通過監控VLAN或安全域邊界上的網絡流量實現安全監控和隔離，安全設備通常工作在二層網絡模式下，以透明方式進行部署。那么回到最初的問題，即在這樣的安全需求和規劃模型下，如何控制網絡流，使之能夠在出入VLAN或安全域邊界時經過部署在云環境中的安全設備。
3 網絡流控制方法
從云計算和虛擬化的整體技術架構進行剖析，可以在五個不同的層面通過對網絡流的控制實現虛擬機間的安全隔離。如圖1所示，這五個不同的層面分別是虛擬機網絡驅動層、虛擬交換機層、虛擬機監控器網絡驅動層、二層物理網絡層、三層物理網絡層。其中虛擬機網絡驅動層和虛擬機監控器網絡驅動層需要系統提供API級的支持，其他三層則需要交換機和網絡協議級的支持實現。
4 安全隔離方案
我們逐層分析在不同層面實現安全隔離時的實現原理和部署方式，以及此類安全隔離方案的優缺點。
方案一：在虛擬機網卡驅動層實現安全隔離的方案，如圖2所示，利用安裝在虛擬機內的網絡驅動層代理程序截獲進出該虛擬機的網絡流，實現將需要被監控的流量牽引至部署在云環境內的虛擬或物理安全設備上，由安全設備完成檢測和過濾后，送回代理程序，再送至虛擬機的業務程序中。該方案的優勢是能夠實現任意虛擬機間的通信隔離和監控，并且完全與虛擬化環境解耦合，不依賴于任何虛擬化平臺，可跨平臺部署，比較適合安全公司在用戶已經完成云計算環境的建設后，追加相應的安全功能。但該方案也存在明顯的缺陷，即需要在每臺虛擬機上安裝代理，管理復雜，且有可能影響業務虛擬機的穩定性，并且對整個虛擬化環境的計算和網絡資源消耗也較高。方案二：在虛擬交換機層實現安全隔離的方案，如圖3所示，虛擬交換機通常是工作在二層模式下，無法進行對其內部交換的流量的任意控制和牽引，但若虛擬交換機開啟了Openflow協議的支持，則可以實現基于Openflow流表對其內部流量的控制，通常需要將被監控的流量都牽引至部署在同一臺物理機上的安全虛擬機中進行檢測和過濾。
該方案的優勢仍然是支持任意兩臺虛擬機間的安全隔離，相對于方案一，在虛擬交換機層面實現的網絡流控制功能具有更好的性能和健壯性，且VMware平臺的5.5以上基于NSX的虛擬網絡實現和Open vSwitch都直接支持Openflow模式。該方案需要安全管理平臺或安全設備的管理中心與虛擬交換機的控制中心相耦合，但安全設備自身與虛擬化平臺并沒有耦合性，因此能夠支持安全設備直接虛擬化后的部署。該方案所存在的問題是需要在虛擬交換機上打開Openflow協議支持，這將使得網絡管理和配置和傳統模式大相徑庭，目前還不被所有用戶接受，并且在安全虛擬機中執行安全隔離任務也會消耗較高的虛擬化系統資源。該方案屬于跟虛擬網絡層耦合的方案，因為在虛擬化環境中，虛擬交換機通常為可替換的組件，但網絡流量的牽引需要通過調用虛擬交換機的配置接口修改Openflow規則來實現，因此虛擬交換機能否提供此類接口將影響方案實施的可行性。
方案三：在虛擬機監控器網絡驅動層實現安全隔離的方案，圖4給出了VMware平臺上的VMSafe Net API的實現原理圖，進入虛擬機監控器的網絡流在進入虛擬交換機前，將被虛擬機監控器所提供的VMSafe Net API導入到安全虛擬機中，安全虛擬機使用特殊的驅動來獲取由VMM快通道驅動模塊提供的數據包，而安全功能的實現則需要基于安全接口封裝層來實現，該層封裝了通過特殊驅動層獲取數據包的操作，相當于對安全業務實現層提供了相應的庫函數。
由于底層驅動級別的特殊API的支持，因此該方案最大的優勢是可提供零拷貝的數據包截獲，從而獲得更高的監控性能，并且能夠和虛擬化平臺較好的整合而不會影響虛擬化平臺的穩定性。但同時由于對虛擬機監控器底層API的依賴，使得該方案與虛擬化平臺緊密耦合，因此通常不具有跨平臺性，并且通常需要全新的開發相應的支持虛擬機監控器API的安全功能，而無法直接使用從硬件安全設備移植代碼。在安全業務實現層面，該方案必須把所有安全功能都集中在一臺虛擬機內實現，使得該虛擬機比較容易成為安全產品性能的瓶頸。
方案四：在二層接入物理交換機層實現安全隔離方案，在基于MAC地址學習的物理交換機上是無法實現安全隔離功能的，因此必須讓二層接入物理交換機層支持Openflow協議，通過關閉MAC地址學習功能，開啟Openflow來實現在物理接入層上對需要隔離的流量的牽引。
這里存在兩種不同的實現思路，其一是使用全SDN網絡，即虛擬交換機和二層接入物理交換機都要開啟Openflow協議支持，這樣完全控制任意兩臺虛擬機間的通信路徑，但是這就使得安全隔離方案在網絡流的轉發路徑控制時要同時跟虛擬化平臺中的虛擬交換機和物理交換機的管理中心進行交互和整合。由于在實際項目中，不能保證虛擬化平臺的提供商和網絡提供商是同一廠商，且不能保證他們在網絡建設方案上就安全隔離方案的選擇和使用達成一致，甚至會出現需要虛擬化平臺提供商、網絡提供商和安全提供商三方共同構建安全解決方案的情況，因此基于虛擬網絡和物理網絡全SDN實現安全隔離的方式較難實施。
第二種思路是在虛擬網絡層通過VLAN對虛擬機進行隔離，在物理接入交換機上開啟Openflow協議。相對于全SDN網絡的模式，只在物理網絡開啟Openflow在管理上相對簡單和高效，但該方案無法對在同一臺物理機上屬于同一VLAN內的不同虛擬機進行有效的隔離，并且在二層環境下，缺乏有效的流量匯聚能力，若完全通過接入交換機把屬于同一安全域邊界的流量向一個物理端口進行匯聚，會因為虛擬機的物理位置的分布而造成接入交換機網絡帶寬的極大占用。
方案五：在三層匯聚物理交換機層實現安全隔離方案，由于虛擬交換機和接入交換機都工作在二層模式下，因此所有跨VLAN的網絡流量都將上行至三層匯聚物理交換機進行交換，即三層匯聚交換機是整個網絡中所有跨VLAN流量的匯聚點，而這種特性與虛擬化平臺無關，因此當用戶的安全需求滿足前文所給出的安全需求定義和規劃模型時，都可以應用該方案實現對安全域邊界流量的網絡安全隔離。該方案的最大優勢是充分解耦合了安全隔離方案的實施與虛擬化環境的關系，僅需要在三層匯聚層與網絡環境相整合，能夠充分利用硬件安全設備的性能和功能優勢，完全不占用虛擬化環境的資源，穩定性和性能都超過前面的各種方案。在三層網絡環境中，靜態路由或Openflow都是可以控制網絡流量通過串行安全設備的方式，為了滿足之前給出的安全設備工作在二層透明模式的需求，利用Openflow實現流量牽引是更好的解決方案。
圖5給出了在啟明星辰泰合云安全管理平臺管理下的云安全隔離方案，在方案中，該方案要求在物理網絡環境中開啟Openflow協議支持，云安全管理平臺基于用戶在其上所定義的安全域劃分規則，通過網絡環境中SDN控制器提供的API修改服務鏈(Service Chain)，使得跨安全域邊界的網絡流被牽引至安全資源池，如圖中所示，VLAN100和VLAN200被劃分在了安全域1，VLAN300在安全域2。那么當VLAN100和VLAN200內的任意虛擬機間進行通信時，我們認為屬于同一安全域內的通信，可不隔離，而當VLAN100或VLAN200內的虛擬機和VLAN300內的虛擬機通信時，這部分流量將被通過安全管理平臺下發給SDN控制器的服務鏈修改策略進行修改，使得這部分流量被牽引到串行安全資源池中，并在安全資源池中基于流量的業務特性進行進一步的細分，使得相應的業務流量通過對應的安全設備(如http流量通過WAF設備)。該方案存在兩個方面的局限，其一是需要物理網絡環境支持Openflow，其二是無法隔離粒度在虛擬機級別的通信。5 結束語
綜上所述，在云計算環境中，網絡安全隔離方案的實施過程中，需要考慮到包括虛擬化、網絡和安全等不同供應商合作問題，虛擬化平臺API支持問題，用戶對網絡配置方式的接受問題(如是否使用SDN模式)，網絡平臺網絡流管控接口支持問題，安全隔離控制粒度問題(如虛擬機級別還是網絡安全域邊界級別的控制)，安全隔離方案性能、功能和穩定性問題等。
特別是由于云環境建設和安全建設的不同期，往往造成安全廠商后介入，而只能采用與云平臺和網絡環境都完全解耦的解決方案，而對于云平臺和網絡環境的建設方，往往或不承擔安全建設的任務或希望整合打包更多自有安全產品而并未開放足夠的可用安全管理調用的管理控制接口，這些都使得云安全特別是云安全隔離解決方案的實施困難重重。我們也期待更多的云服務商和網絡服務商更加重視對云計算環境安全的支持，為安全提供更多標準的管控接口，使得安全解決方案能夠很好的被整合進整個云環境中。
SCISSCIAHCI
