雲來了，安全盒子怎麼辦

雲來了，安全盒子怎麼辦

tomqq書於 9.22.2016

 

前提和假設：

本文主要討論“當下的”私有云安全，公有云不在此文範圍內

 

摘要

隨着傳統IDC迅速向雲機房轉型，人們對傳統計算資源的使用方式發生了很大的改變。隨之也帶來了不一樣的安全需求，這些變化也促使傳統“盒子廠商”對原有產品進行改造，以適應雲化的安全需求。

本文通過闡述雲化的具體變化，分析了對雲安全帶來的安全挑戰。通過研究具體雲的資源利用方式的變化以及研究現有私有云安全解決方案，分析了現有盒子安全設備要在雲時代繼續發揮作用，需要做出的改變。文章最後，對雲安全將來的發展趨勢，做了技術預測並闡明理由。

總的來說，雲是利用資源的新的方式，安全本質並沒有發生變化。但是，盒子發揮作用的方式，需要根據雲的變化而調整，才能繼續有效。

1、雲帶來的安全挑戰

近兩年，雲計算髮展迅猛，新建的IDC如政務雲，行業雲，絕大部分都是雲機房。雲計算是大勢所趨已經毫無疑問，已開始遍地開花。

關於雲環境下如何做網絡安全防護，常聽見一種觀點：雲是顛覆性的，傳統硬件安全設備完全不適用雲環境。

那麼，雲來了，安全盒子到底該怎麼辦？

從本質上來說，對於網絡安全設備，雲帶來的最直接挑戰有兩個：

1、  主機虛擬化

2、  網絡虛擬化

雲主機虛擬化帶來的挑戰

                                           

傳統機房裏面，每個租戶的服務器是看得見摸得着的。在雲環境下，租戶的服務器變爲了一個個運行在硬件服務器上的虛擬機，一個租戶的虛擬機，可以位於不同的硬件服務器上，這是形態的變化，會引起租戶的邊界，從傳統物理邊界，變爲動態、虛擬的邏輯的邊界。

另外，因爲一些歷史原因會出現軟硬件資源混合的情況。某些服務器不方便虛擬化，如歷史遺留的數據庫服務器，就需要和虛擬資源一起組成租戶的計算資產。

最後，不同虛擬化廠家，如vmware，citrix，Hawei，H3C，各家的hipervisor系統不兼容，也會給安全廠商帶來適配的工作量。安全廠家如果要以虛擬的形態運行在虛擬環境裏面，需要適配不同平臺的虛擬機格式。

因此，傳統安全硬件要繼續發揮作用，首先就要能夠識別和保護虛擬的資產域，並且以動態的方式，切入到虛擬計算環境裏面去。

另外，現在的運營商也不喜歡硬件盒子了。畢竟專用的盒子，利用率低，又互不兼容，運營商希望用通用的X86服務器來運行虛擬的安全設備，類似NFV，來提升經濟性，可擴展性，以及適應業務快速可變的要求。

網絡虛擬化帶來的挑戰

如果按照vmware 1999年發佈VMware WorkStation算起, OS虛擬化的發展時間已經不短了。但是，僅僅是服務器形態的虛擬化，還不足以支持雲的發展。在雲環境下，要滿足雲的虛擬性、動態性，還需要將網絡也虛擬化。

第一個問題是傳統vlan的4K問題。傳統vlan因爲tag字段位數限制，只能支持最多4k個vlan。但是在雲環境下，租戶的數量非常多，4K上限是不能滿足租戶數量的要求的。基於這個目的，擴展vlan tag字段位數，重新對ip報文做wrap，以便於支持更多的租戶容量，採用類似vxlan這種方式來劃分網絡是主流方式。對傳統安全盒子來說，首要問題就是能識別vxlan報文。另外vxlan帶來的不僅僅是報文tag改變這一點點內容，vxlan帶來的相關的網絡控制方式改變，調度，如服務鏈、SDN等等，也都是安全盒子需要去適應的。

另外，雲環境下業務動態變化非常頻繁，靠傳統硬件去動態開通或者銷燬一個業務，顯然是不行的。之前大家只知道需要把服務器虛擬化，後來隨着雲虛擬機數量規模的擴大，大家逐漸意識到光服務器虛擬化還不夠，需要把網絡部分也虛擬化，軟件化，並自動化。舉個例子：某租戶需要開通一個業務需要一臺路由器，過一段時間又不需要了，硬件路由器可以滿足這樣的頻繁變化嗎？硬件盒子，必須要也可以動態靈活的部署進去才行啊。

再加上雲環境爲了滿足虛機動態遷移，需要在一個大二層，傳統二層設備沒辦法支持這麼巨大的mac表項，這一塊也需要新的二層技術，如vxlan的支持。傳統網絡顯然不行的。

還有，租戶都有自己的vpc，IP地址範圍很可能是重疊的。傳統硬件設備大部分是不支持這個的，大部分不具備硬件設備虛擬爲多個硬件設備的功能的。租戶是邏輯的、虛擬的，是接在“邏輯交換機”上的。邏輯交換機本身就不位於任何一個固定位置，是通過計算機節點overlay的方式，分佈式部署的。因此，對多租戶的安全檢測能力，是傳統安全盒子不具備的，這顯然無法適應雲安全的要求。

最後，SDN控制網絡，控制和轉發平面分離，也使得雲環境的網絡和傳統網絡大大不一樣。傳統盒子如何接入如何適配新的網絡架構，這個也是需要有一個重大改變的。之前安全盒子通過策略路由、橋接、分光鏡像等方式接入網絡做安全檢測的方式，在SDN網絡架構下已經不能適用了。傳統安全盒子，需要按照新型網絡的控制方式，來接入業務流量。否則，就完全不能發揮作用。

總結

上述挑戰，傳統安全盒子通過交換機、路由器、分光器等物理方式接入租戶網絡的方式，在雲環境下就失效了。要繼續發揮作用，傳統硬件必須要解決在雲環境下的接入問題，要做到看得見、認得出、防的住，才行。

除了接入問題，安全盒子還需要適應雲的彈性。硬件固定性能的盒子不容易彈性擴展，在雲裏面，安全也要像計算資源一樣，可以動態的、彈性的擴展。

總的來說，雲是利用資源的新的方式，安全本質並沒有發生變化。但是，安全發揮作用的方式，需要根據雲的變化而調整，才能繼續有效。

2、  什麼是東西向流量

凡提到雲防護，必然會聽見“東西向防護”這個詞。那麼，什麼是東西向流量？

下面這幅圖，是傳統IDC的流量走向：

可以看到，大部分業務流量，都是從外到內爲主，安全防護設備，也集中在由外到內的防護路徑上，我們稱之爲“南北向”防護。

IDC雲化以後，服務器的規模，包括虛擬機的數量，都擴大了很多。橫向的虛機密度大大增加，也因此衍生出租戶和各種複雜的網絡虛擬設備，如下圖：

   傳統IDC的安全問題，主要集中在①這個位置。雲化以後，流量問題複雜化了，衍生出②、③、④、⑤這幾個新的情況，防護也因此而有所不同。

在雲網絡內部，租戶之間是隔離的，互相訪問要通過***或者隧道訪問。租戶內部可以劃分不同的子網，子網之間，子網內部虛擬機之間，虛擬到外部，外部到虛擬機，都會產生訪問流量，安全問題也由此而生。

重要的是，這些流量往往產生在雲內部，甚至不出服務器（如同一服務器內部虛機之間的流量）。因此這些流量，對傳統硬件盒子不可見，從而也無法防護。這些流量，會成爲一個真空地帶，一旦發生安全問題，如虛機中***或者病毒，將會迅速在雲內部蔓延，並難以進行防護控制。這種情況是非常可怕的。根據《雲等保增補方案》同等防護的原則，雲內部流量也需要進行同等安全強度的防護，防護缺失是無法接受的。

綜上，南北向流量，主要是指外部公網進出雲計算內部的流量。東西向流量，主要是指租戶內部虛擬機的訪問所產生的流量。注意，東西向流量在這裏是泛指租戶相關的流量，並不僅僅是從外到內的流量。如果外部流量訪問虛擬機，需要按照不同租戶的策略來防護，此刻也稱之爲“東西向”。

南北向防護，傳統方案都可以繼續有效。而東西向防護，是雲化後的機房新增加的需求。本文後面的討論，主要集中在東西向防護方案。

3、  現有東西向防護方案

凡是解決方案，出發點都是根據安全廠商自身情況優先考慮。同樣的，對客戶而言，“反廠商綁架”也是自然的訴求。

虛擬OS廠商的方案

虛擬OS廠商，指的是虛擬系統廠家。這類廠家因爲掌握了虛擬操作系統，所以自然考慮從虛擬系統本身入手來構建安全方案。通用的示意圖如下：

 

虛擬操作系統廠家，通過在虛擬系統網卡之上增加驅動過濾層，將虛擬機的流量截獲，將流量導向系統內置安全模塊，或第三方的安全虛擬機，進行安全防護。

從上圖可以看出，對內部流量的防護，利用了計算節點本身的計算能力進行，流量在出計算節點之前，就得到了有效的防護。

這種方式有他的優缺點。優點是，在靠近虛擬機的位置進行防護，能夠在最短路徑上防護，同時流量不出計算節點，不會對雲內部骨幹網絡，造成額外的流量負擔。另外隨着虛擬OS的部署，安全能力隨之部署，在部署上也會比較便利。

缺點也很明顯，首先是第三方安全廠商必須獲取虛擬OS的防護API授權，才能引入自己的安全虛機，如vmware的nsx認證。對於虛擬OS廠商來說，自然不願意第三方碰自己的蛋糕。比如vmware的NSX模塊，終端用戶須付費購買，第三方安全廠商須通過商業認證。只有同時滿足這兩個條件，用戶纔可以用到想要的安全廠商的安全能力。

另外一個缺點是安全模塊和安全虛機運行在計算節點，會佔用計算資源。對於計算資源緊缺型的用戶，或許無法接受。同時安全能力和計算能力混合在一起，出現問題的時候，排查責任也會有較高的複雜度，互相依賴交叉的情況，會對虛擬OS廠商和安全廠商造成同時困擾。

最後一個缺點，是安全虛機廠商多樣性也會有問題。不同廠家的安全虛機，要同時出現在同一個計算節點上，技術上會有很大的問題。從客戶長遠利益考慮，客戶需要一個比較好的，兼容各個安全廠商的安全架構，或者說良好的生態圈。

網絡廠商的方案

         這類廠商，以傳統網絡數通廠家爲主。雲化，不僅僅需要服務器虛擬化，也需要網絡的虛擬化。流量可以在計算節點的驅動層捕獲，也可以在網絡層面捕獲。我們知道，業務流量在哪裏，安全問題就在哪裏。因此對於網絡安全盒子來說，在網絡層面接入纔是正道。

         

如上圖所示，SDN網絡，控制面和轉發面分離，通過控制器來集中控制所有流量的轉發。在SDN網絡內部，可規劃安全區。在安全區域，安全虛擬機或安全設備，可註冊爲服務節點。在SDN協議字段裏，通常有服務字段。通過設置服務字段的值，即可控制任意的流通過指定的服務節點。

         那麼，安全盒子的部署，在這種情況下，也簡單了。只要把安全盒子或者安全虛機，部署在服務區域，並註冊爲標準服務節點，即可利用SDN的服務編排能力，“指揮”任意流量，經過相應的安全節點，從而完成安全防護。

         同時，SDN也有強大的網絡控制力，可以實現流量鏡像到服務節點，以及把服務節點的虛擬機工作口，綁定到用戶VPC從而完成掃描類任務。

         因爲流量調度，通過網絡進行了橫向遷移，此刻可能大家會擔心對網絡帶寬佔用問題。爲因對此問題，SDN網絡內部增加了橫向交換機的密度，所謂spine-leaf架構，通過增加橫向帶寬，來滿足流量橫向遷移的能力。

         這種方式的優點很明顯：通過設置服務節點，將流量通過網絡調度的方式，進行服務編排，可以很方便的接入第三方廠商的傳統盒子以及安全虛機。同時，因爲通過網絡控制器來進行流量牽引，可以自然兼容大部分hipervisor OS廠家——因爲引流和虛擬OS沒有關係。

         缺點主要是增加了橫向流量，會增加一部分網絡建設的開銷。另外在網絡時延方面，不如內置在計算節點的方式。最後，採用這種方式，網絡設備必須是支持服務編排的SDN網絡，這對於採用傳統網絡方式的客戶，增加了改造費用。

 

傳統終端安全廠商的方案

傳統終端安全廠商，優勢在於有安全終端，劣勢在於沒有網絡產品，也沒有虛擬操作系統產品。那麼，自然會從自身優勢出發，在虛擬機操作系統內想辦法來構建安全能力，如下圖：

即：通過在虛擬機操作系統內，安裝安全代理（通過虛擬機模板部署），以及在HiperVisor OS內安裝安全模塊，或稱之爲“無代理”方式，通過在HiperVisor系統底層以及虛擬機操作系統驅動層，捕獲數據流以及文件內容，來實現安全防護。一般可實現殺毒、文件監控、網絡防護等功能。

這種方式的優點在於，通過在虛擬機操作系統部署安全代理，避免了必須依賴虛擬OS以及SDN網絡，而直接實現了流量捕獲以及防護。另外，也可以充分利用計算節點的計算能力，無需額外增加安全硬件資源的投入，也不會引起流量的橫向調度。

缺點主要有三個：一個是在客戶虛擬機上安裝代理，會有信任問題。如果客戶數據比較敏感，可能不願意安裝第三方的程序在自己的虛擬機內；另外，如果要按照不同租戶不同策略來進行防護，還是需要一個集中的管理中心和虛擬系統用戶數據庫進行對接，以便於識別租戶以及下發相應的策略。第三個缺點是防護能力的多樣化會有問題，即：很難在這樣高度集成的架構內，開放的引入各家廠商的安全能力。

網絡安全廠商的方案

網絡安全廠家，既沒有SDN產品，也沒有虛擬OS產品。在這種情況下，往往會選擇一箇中立的態度來構建雲內的安全解決方案。

網絡安全廠商，優勢在於安全產品線很全，可以很快的將安全盒子，虛擬化爲各種安全虛機，並池化。如下圖：

通過在標準x86服務器上，安裝各類虛擬機，並形成安全池集羣；然後，根據租戶的需求，構建虛擬的安全能力，如虛擬WAF，虛擬IPS，以對應虛擬資源的概念。這樣做可以將以前安全盒子專屬硬件才能提供的能力，靈活的虛擬化到通用硬件，客無須再採購專用硬件，可就地利用虛擬服務器來作爲安全池的部署環境，甚至利用現有的虛擬資源池來部署安全虛機。

那麼剩下的，就是通過各種方式，將流量往安全池牽引，以實現安全防護。具體的引流方式，需要結合用戶網絡環境來實現。比如通過SDN API引流，通過傳統路由器進行策略路由方式引流，通過虛擬/傳統交換機鏡像口引流，以及在計算節點內安裝引流代理，通過代理方式引流。如下圖：

上圖的微代理，可以看作一個特殊的虛擬交換機。如果VM2需要被防護，那麼只需要拆除VM2和原有虛擬交換機的連接，並將VM2的虛擬網卡，連接到微代理，微代理用TRUNK的方式再連接到虛擬交換機上，這樣便不會破壞原有VM2的VLAN拓撲。然後，所有VM2的流量就會經過微代理，即使是同一個計算節點內虛機之間的互訪流量，也會被微代理截獲。截獲後的流量，通過隧道送往安全池過安全策略，然後發回原有微代理進行正常轉發。

這種方式的好處在於，通過池化安全能力，可以構建彈性、多樣化且開放的安全池，方案本身符合雲的特性。同時利用各種引流手段，能夠靈活的實現安全防護。

缺點在於，引流方式會帶來額外的帶寬佔用和延時。同時，需要對接不同的客戶網絡方案，對接成本較大。

總結：

綜上，可看出目前雲環境下，缺乏統一的網絡安全設備部署環境，目前局勢還有點混亂。從另一個側面，也看出虛擬化發展過程中，基礎設施對於安全方面考慮的缺失。

 

4、  關於變化和發展

安全能力池化

傳統的安全能力，都是通過固定的硬件盒子的形式提供的。在雲時代，這種情況將發生變化。固化的安全能力，不能匹配雲防護的要求。安全能力池化，首先是將傳統的安全能力（引擎）虛擬化，其次是可彈性伸縮的安全池，最後能適應雲環境的部署方式。雲環境都是有租戶的，那麼雲平臺除了提供基礎安全能力以外，也需要提供不同租戶需求的不同安全能力套餐，並做到可運營。這樣做的原因，本質是爲了匹配雲的特點：彈性，敏捷，虛擬化，可運營。

未來，傳統硬件盒子的份額，可預見會持續下降，虛擬化安全產品的份額則會持續提高，此消彼長。傳統盒子爲了適應虛擬化，數通部分的模塊會退化，引擎部分會持續強化。

在安全池基礎上，需要有一個運營平臺，對安全池進行統一管理，對安全業務進行靈活的開通、計費，並按照租戶查看報表，以及雲內部整體態勢等功能。傳統盒子的安全視角，是基於設備的。雲安全池的視角，是基於運營平臺的，安全盒子（虛機），只是平臺下的一個基礎模塊。

最後，安全池是軟件不是硬件，安全池泛指所有安全能力的集合，包含以安全硬件、安全虛機等組成的混合能力的“池”。

內嵌模式和外置模式互爲補充

內嵌模式，指的是安全池內置在計算節點內，充分利用計算節點的計算能力進行安全防禦的模式，簡單可認爲如下圖所示：

外置模式，正好相反，安全能力放在單獨的通用服務器內，如下圖所示：

關於這兩種方案的優劣勢，爭論很多。總的來說，內置式的最大優點，是充分利用計算節點進行就近防禦。外置式最大優點，是有單獨的安全能力空間，不佔用計算資源。

不論安全廠商如何聲稱哪種方案好，從技術角度看，這兩種方式實際上是互補的。外置安全池，更適合通過網絡調度能力比較強的場合，以及以網絡流量防護爲主的場合；但是對於網絡調度能力弱，需要結合local防護的場合，就適合內置方式。比如HWAF，本地殺毒，就近阻斷，以及想在宿主機OS上搞點事情的場合。

外置和內置模式，都有對方幹不了的事兒。從技術角度看，互補能夠形成最完整的解決方案，缺一不可。無論目前堅持哪一派的廠商，最終都會走到這條路上來。從看見的客戶實際需求，以及大廠的收購路線，都能印證這個趨勢。

平臺爲王

傳統盒子都是以賣盒子爲主要銷售模式。雲機房，不但需要虛擬化的安全盒子（池），還需要處理和虛擬系統的對接以獲取租戶信息、vxlan信息，SDN引流對接；另外從運營模式看，雲平臺除了提供基礎防護，更重要的是提供滿足租戶多樣化需求的可運營的平臺，並滿足增值收入。

傳統機房只需要安全盒子接入，最多加個網管軟件，即可完成銷售。對雲安全來說，這是不夠的，需要提供平臺能力，通過將虛擬化能力引入平臺，並將平臺和雲平臺的對接，從而提供雲防護能力。

雲安全平臺的模式和盒子不一樣，平臺模式是平臺先行，盒子和虛機隨後逐步建設。從這個角度看，得平臺者得天下。平臺模式示意圖簡單如下所示：