精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

從數據流的走向看云安全問題如何解決

責任編輯:editor005

作者:魏俊

2015-06-24 14:19:36

摘自:綠盟科技

先說說vSwitch的轉發過程,正常情況下,VSwitch處理過程與傳統交換機類似,如果從物理網卡收到報文后,查MAC表轉發;如果從虛擬機收到報文,目的MAC在外部則從物理網卡轉發,在內部則查MAC表轉發,如下圖所示:

以往大家更多是從云計算技術、云計算模型體系架構等方面來對云安全進行研究和探討,本文將從另外一個角度——從數據流的走向來探討一下云計算,尤其是云計算平臺下的安全問題。

以往大家更多是從云計算技術、云計算模型體系架構等方面來對云安全進行研究和探討,本文將從另外一個角度——從數據流的走向來探討一下云計算,尤其是云計算平臺下的安全問題。

一. 云平臺下數據流向的大致分類

從云平臺數據流的方向來看,大致可分為以下幾類:

從數據流的走向看云安全

  圖1 云平臺下數據流的大致分類

外部訪問虛擬機

外部用戶訪問虛擬機上承載的業務,流量由互聯網進入——核心——接入——物理機網卡——虛擬機。

虛擬機訪問外部

由虛擬機訪問互聯網,流量方向與上一種情況剛好相反,虛擬機——物理機網卡——接入——核心——互聯網。

跨物理機的虛擬機之間訪問

VM 1——物理機1網卡——接入交換機1——核心交換機(可有可無)——接入交換機2——物理機2網卡——VM 3。

同一物理機上的各虛擬機之間互相訪問(隱蔽信道)

物理機1上的VM 1訪問VM 2。

物理機和虛擬機之間的訪問(虛擬機逃逸)

物理機和虛擬機之間的雙向流量,物理機與VM相互訪問。

二. 從數據流向分類看云安全

外部訪問虛擬機

此種情況下與傳統IDC的防護思路一樣,就不詳述了,只是部分串聯設備部署方式需要考慮調整。一是因為云平臺扁平化是趨勢,能少串一個設備是一個設備,二來設備吞吐向來也不是安全設備的優勢,云平臺下動則10G、40G的鏈路串上去也吃不消,所以可以考慮旁路部署,按需防護。

虛擬機訪問外部

通常云平臺虛擬機用來對外提供服務比較多,較少有主動訪問互聯網的需求。不過有一種較為常見的場景就是虛擬機被攻擊者控制后用作跳板,往外進行大流量的 ddos攻擊。這種情形下一方面會消耗服務器的CPU資源,另一方面也會消耗云平臺的大量帶寬。因此有必要對由內往外的流量進行監測,這里就可以使用 NTA(網絡流量分析系統),一旦發現由內往外的DDoS攻擊則可以將進行攻擊的源IP路由直接丟棄,中斷該IP的對外訪問。

跨物理機的虛擬機之間訪問

由于跨物理機的虛擬機訪問會經過傳統的交換機,因此該場景下可采用傳統的安全措施來進行防護,如ACL、IDS等;如果沒有這類需求,可直接通過VLAN劃分的方式隔離。

同一物理機上的虛擬機之間訪問(隱蔽信道)

常見的虛擬化軟件缺省采用軟件VEB(又稱vSwitch)來完成同一個物理機上的虛擬機之間通訊,由于多數vSwitch只進行二層轉發,導致VM互訪流量不可見,是云平臺下的一大安全問題。

先說說vSwitch的轉發過程,正常情況下,VSwitch處理過程與傳統交換機類似,如果從物理網卡收到報文后,查MAC表轉發;如果從虛擬機收到報文,目的MAC在外部則從物理網卡轉發,在內部則查MAC表轉發,如下圖所示:

從數據流的走向看云安全

  圖2 vSwitch轉發

目前的思路有兩種,一種是通過vSwitch來解決。vSwitch在二層轉發基礎上還可實現其它功能,從VMware的介紹來看至少包括VLAN、安全功能、流量管理、甚至負載均衡等功能,但是由于其實現這些功能需要消耗服務器大量的CPU資源,使用效果如何還有待考驗。

另一種解決辦法是采用IEEE標準組織提出的802.1Qbg EVB(Edge Virtual Bridging)和802.1Qbh BPE(Bridge Port Extension)兩條標準,這兩條標準可以將虛擬機內部的流量引出到虛擬機外部,這樣就可以采用傳統的安全防護手段來解決隱蔽信道下的安全問題。這里主要探討一下應用范圍更廣的802.1Qbg EVB,其包含了傳統的vSwitch功能的VEB模式、VEPA(Virtual Ethernet Port Aggregator)和Multi-Channel。VEB上面已經說過了,簡單說下另外兩種處理方式。

一種是VEPA。VEPA組件從VM1接收到數據后,先轉發到物理網卡,物理網卡不管三七二十一先轉發出去到接入交換機,再由接入交換機根據MAC表原端口轉回,VEPA收到從接入交換機來的報文才查表進行內部轉發,最終數據到達VM2和VM3,如下圖所示:

從數據流的走向看云安全

  圖3 VEPA轉發

通過這種方式可以將所有VM之間的交互數據通過接入交換機上進行轉發,因此可以在交換機上實施訪問控制策略,隔離不相關的業務,對流量進行分析實現入侵檢測和審計等功能。

另一種是通道技術(Multichannel Technology),多通道技術方案將交換機端口或網卡劃分為多個邏輯通道,并且各通道間邏輯隔離。每個邏輯通道可由用戶根據需要定義成VEB、 VEPA或Dircetor IO(基于網卡SR-IOV技術實現的硬件VEB技術,減小了CPU的開銷,但是與軟件VEB存在相同的問題)的任何一種。每個邏輯通道作為一個獨立的到外部網絡的通道進行處理。多通道技術借用了802.1ad S-TAG(Q-IN-Q)標準,通過一個附加的S-TAG和VLAN-ID來區分網卡或交換機端口上劃分的不同邏輯通道。如下圖所示,多個VEB或 VEPA共享同一個物理網卡。

從數據流的走向看云安全

  圖4 多通道轉發

因此從理論上來說,虛擬機之間可以套用安全域劃分的概念,依靠多通道技術進行合理的虛擬安全域劃分,同一個虛擬安全域內采用VEB技術,域內虛擬機互訪不受限制,保證了足夠的交換性能;虛擬安全域之間采用VEPA技術,將流量引到交換機上,部署訪問控制與流量監控策略等;對于單獨的安全域,尤其是獨立業務的虛擬機,采用Dircetor IO,與其它虛擬機流量隔離,直接轉發到外部,在外部交換機上監控其流量。

同一物理機和虛擬機之間的訪問(虛擬機逃逸)

由于Hypervisor(Hypervisor是一種運行在物理服務器和操作系統之間的中間軟件層,可允許多個操作系統和應用共享一套基礎物理硬件,也可以看作是虛擬環境中的”元”操作系統)存在一些已知的漏洞,這就為攻擊者從已控制的虛擬機利用Hypervisor的漏洞滲透到Hypervisor提供了可能。雖然利用這種方式的技術難度相對較高,但是由于所有的VM都由Hypervisor來控制(啟動、停止、暫停、重啟虛擬機;監控和配置虛擬機資源等),因此危害相當大。要解決這個問題必須得修復Hypervisor的漏洞,一方面依賴于能否發現這些已知漏洞(可采用具備虛擬化檢測能力的漏掃工具或專業的滲透測試服務),另一方面依靠于VM廠商是否能夠及時提供補丁。同時個人猜想是否可以采用VEPA(從能查到的資料來看都是VEPA如何解決VM之間的流量問題的)或者類似VEPA之類的技術,將VM到Hypervisor的雙向流量引出到外部的交換機轉發一下,這樣就為監測這類攻擊提供了可能。

三. 小結

總的來說,本文簡單地從數據流的走向來探討了一下云計算,尤其是云計算平臺下的安全問題和解決思路,對于云計算平臺下的安全問題除了云計算技術引發的特定的安全問題外(隱蔽信道、虛擬機逃逸、虛擬化漏洞等),其它的安全問題基本都可以用傳統的思路來解決。

鏈接已復制,快去分享吧

企業網版權所有?2010-2024 京ICP備09108050號-6京公網安備 11010502049343號

  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 永福县| 绥阳县| 资溪县| 临泽县| 双牌县| 海淀区| 虹口区| 顺平县| 宜良县| 南安市| 东丽区| 囊谦县| 江永县| 兴城市| 通江县| 邳州市| 玛纳斯县| 赣州市| 宜兰县| 镇赉县| 寻乌县| 汝城县| 济源市| 双鸭山市| 莱西市| 利辛县| 阳高县| 汾阳市| 福州市| 娱乐| 边坝县| 垦利县| 迁西县| 民乐县| 汶上县| 合江县| 天镇县| 明溪县| 辉县市| 东乌珠穆沁旗| 沁水县|