“私有云”安全的“過渡”時期-“雲朵”方案的設計思路

“私有云”安全的“過渡”時期–“雲朵”方案的設計思路

Jack zhai

一、私有云安全的尷尬現狀

雲端計算因為能夠提供虛擬化的資源池、彈性的服務能力、自助服務等，深得CIO們的青睞，為了提高企業IT裝置的利用率，提高服務容災的能力，提高對業務支撐的快速響應能力，大多數的企業都開始嘗試企業私有云的建設。

一般來說，從現有的IT管理體系過渡到私有云平臺，大致需要幾個步驟：資料大集中、業務系統整合、IT資源的虛擬化、管理平臺雲化、雲服務提供。（很多人認為私有云就是資訊中心的建設，其實資訊中心的虛擬化改造一般是最後兩個階段合併為資訊中心的統一運維管理平臺，而不一定會提供雲服務，因此，不能稱為嚴格意義上的私有云。）這個過程中，資源虛擬化是關鍵，因為只有資源都虛擬化管理，才可以談得上動態的調配，才能夠提供彈性服務支撐能力。哪些資源可以且需要虛擬化管理？計算資源，包括CPU與內容，儲存資源、網路資源。我們注意到，一般都沒有涉及到安全資源。這不奇怪，因為虛擬化平臺廠家都是先以業務服務實現為主，安全問題大多是放在後邊考慮的。

這就給CIO們出來一個難題：私有云為企業各個業務部門提供統一服務，不僅僅包括計算資源、儲存資源、網路資源，還應該包括安全資源，如身份認證、病毒查殺、入侵檢測、行為審計等，只分配了計算資源與儲存資源的系統，對使用者來講，無異於“裸奔”。私有云與公用雲不同，公用雲的業務單一，可以建立統一的安全策略；而私有云不同業務系統的安全需求差異很大，在一個“雲”內，為不同業務系統提供不同的安全策略，安全策略如何部署？部署在哪裡？

雲端計算的安全問題一直是業界爭論的熱點，還有個專門的組織CSA(雲安全聯盟)指定了一些指導性意見，但落地都比較困難。總結起來，雲端計算的安全落地有兩方面的難題：

第一，是雲端計算系統架構本身的問題。

由於採用了虛擬化的資源管理，使用者業務系統的伺服器不再明確地執行在哪臺伺服器上，而是動態漂移的VM(虛擬機器)，不同業務系統的使用者都在一個“大雜院”內進進出出，各個業務系統之間沒有了“邊界”，如何保證那些不安分的使用者偷窺其他的系統的資料，只靠虛擬化作業系統的管理，能夠滿足使用者業務流之間的隔離嗎？且不說虛擬機器逃逸方面的研究，如“藍色藥丸”，傳統的作業系統都是漏洞一堆，虛擬化作業系統的漏洞就會很少嗎？危害程度可是更大。

第二，是虛擬化作業系統廠商的問題。

目前，能夠提供虛擬化作業系統的廠商不是很多，如VMware、Microsoft、Ctrix、Xen、RedHat、方物等。先說市場份額最大的VMware，是一家與微軟一樣的私有程式碼廠商，只提供第三方的開發介面API。VMware提供系統底層的安全介面，如VMSafe，但這個介面目前還沒有對國內的安全廠商開放，也就是說，實現安全部署，只能採購國外的第三方安全廠商產品。其他的廠商，如Xen是開源的，是沒有介面問題，但需要使用者自己的技術力量非常強才可以部署與維護。

一句話：雲內的安全問題是嚴重的，最好的方法，就是安全裝置可以如同儲存裝置一樣，形成池化的資源池，在使用者申請雲伺服器時，與計算資源、儲存資源一起按需分配給使用者。

但是，就目前安全廠商的現狀，完全達到這個階段還需要一段時間；為了應對過渡時期的私有云服務執行的安全，我們提出了過渡時期的安全解決方案—“雲朵”方案。

二、“雲朵”方案的設計思路

在沒有辦法確定多個不同業務系統在一個雲中執行可以做到安全的隔離的情況下，根據不同業務系統的安全需求，把安全需求近似的、服務物件相似的業務系統部署在一個雲內，否則就部署在不同的雲中，這樣在企業中就形成了一個一個的雲朵，如辦公業務雲、生產業務雲、網際網路服務雲等，或者按照等級保護的級別，分為一級系統雲、二級系統雲、三級系統雲等。

“雲朵”方案設計模型

企業核心網路是“物理”的，不同的業務服務雲朵連線在核心網路上，每個雲朵內部有自己的雲朵管理中心，負責雲朵內的計算、儲存、安全資源管理；企業使用者分為虛擬終端(如執行虛擬桌面的“傻終端”)與真實終端(如PC等“富終端”)，通過企業網路，可以登入不同的雲朵；整個網路的使用者採用統一的身份認證，並建立雲朵安全管理的中心平臺，該平臺通過各個雲朵的管理中心介面，可以直接監控雲朵內虛擬機器的執行狀態。

雲朵方案的優點是明顯的：一朵雲內是業務系統安全需求是相近的、使用者是相同的，安全隔離的需求大大降低了，這樣就解決了不同業務系統在一個雲內安全隔離的安全難題，在雲朵之間的網路是“物理”可見的，傳統的安全邊界思路完全適用；當然，不同雲朵可以採用不同的虛擬化作業系統，減少對一個廠家的過度依賴(桌面作業系統對微軟的依賴是很多CIO頭痛的難題)；最後，若一朵雲出現問題，也不會影響其他雲朵內的業務系統；

雲朵方案的缺點也是明顯的：IT資源利用率提高有限，這與採用虛擬化技術的目標顯然是違背的；人為地建設多個雲朵，多個管理運營平臺，管理複雜度明顯是加大的。

但是，雲朵方案可以解決目前虛擬化平臺自身安全還不到位，業務需求推動雲端計算模式紛紛上馬的矛盾。邊走邊學，“摸著石頭過河”，總比因噎廢食要好。

雲朵方案把企業私有云的安全問題進行了分解：

Ø雲朵間的安全

Ø雲朵內的安全

三、雲朵間的安全設計思路

不同的雲朵，邏輯上如同傳統安全方案設計中的“安全域”，具有明確的安全區域邊界，因此，雲朵間的安全完全可以按照傳統的安全方案設計思路，部署思路可以參考“花瓶模型”的三條基線一個平臺，網路邊界與安全域邊界的安全防護基線；重要資源區域與核心匯聚的動態監控基線；使用者與運維人員的信用管理基線；日常運維與應急處理的安全管理平臺，具體的技術與管理要求，可以參照等級保護的要求，這裡就不贅述了。

四、雲朵內的安全設計思路

雲朵內實際上是一個雲朵平臺管理的系統範圍內，也可以說是一個虛擬化作業系統的管理平臺下的安全設計。從系統角度看，可以分為兩個層面的安全設計：

Ø虛擬機器內的安全

Ø虛擬化平臺上的安全

（1）虛擬機器內的安全：

就是使用者申請到的虛擬機器，從使用者角度看起來與物理伺服器是一樣的，使用者選定的作業系統與業務服務軟體，因此，虛擬機器內的安全就如同對一個主機系統進行安全防護設計。由於虛擬機器的管理比起物理機要簡單的多，容易進行配置修改與補丁升級管理，開關機就是一個目錄下的檔案執行而已。

同時，虛擬機器的計算資源是可動態申請的，不再存在傳統主機內安全與業務爭資源的矛盾，即因為駐留主機內部的安全監控會降低業務執行的效率，很多業務管理者拒絕安裝其他駐留軟體。當然，軟體間的相容問題依然是存在的，因此，在系統升級或安裝安全軟體前，一定要在其他的虛擬機器上測試，保證不影響業務軟體的正常運轉。

虛擬機器內的安全考慮如下幾個方面：

1.身份鑑別與許可權管理：身份鑑別可以與整個網路的身份認證系統統一起來，但許可權管理在雲朵內部有自己的明細管理，保證雲朵內部使用者可訪問業務的差異；

2.服務加固與反控制防禦：這主要是針對伺服器的，如同普通的業務伺服器一樣，需要基本的安全加固，安裝適合的補丁、關閉不需要的服務、刪除不需要的賬戶等，但這還是不夠的。伺服器是面向網路服務的，中斷了服務，僅僅是影響自己的業務；若被黑客入侵，成為“肉雞”，就可能成為攻擊其他目標的工具。由於雲朵內一般是多個業務系統在執行，一個系統的漏洞被利用，就建立了黑客入侵的橋頭堡，成為內部攻擊的跳板，很多黑客入侵正是這樣一步一步滲透到核心機密伺服器中的。因此，伺服器不被入侵者控制，不成為“肉雞”是伺服器安全的最低底線要求，安裝反控制防禦系統，或對系統進行反控制加固是非常有必要的；

3.終端防護系統：這主要是針對遠端桌面或BYOD的，因為訪問者的終端種類繁多，安全狀態千奇百怪，對訪問終端進行適當的安全檢查，或限制其訪問雲服務的許可權都是必須的；當然，也可以利用“容器式”的遠端桌面，隔離遠端終端內本業務與其他系統，保證終端上的病毒、木馬不能入侵到雲服務內；

4.防病毒：病毒與木馬是無孔不入的，對使用者流量進行病毒過濾是必要的。當然，防病毒也可以在雲朵的入口處實現，但對於應用層的病毒，還是要通過主機監控查殺的方式更為有效。

（2）虛擬化平臺上的安全：

虛擬化平臺上的安全與廠家產品的開放性有直接的關係，可以分為兩種情況：

第一種情況是開源的平臺，或者是得到了廠家的底層安全API介面，如VMware的VMSafe介面，你可以利用介面插入自己的安全程式碼，對虛擬機器上的流量進行安全檢查與控制。

這種方式直接在虛擬化平臺的底層hypervisor上控制使用者資料流，有些象我們所理解的作業系統分為核心態與使用者態，黑客要突破hypervisor到核心層是比較困難的，想繞過這種安全監控也是十分困難的。

第二種情況是得不到虛擬化平臺的底層介面，或者是希望通過第三方的安全控制措施，使用者才放心(虛擬化平臺自己管理、自己控制的安全，總讓人有些疑惑)。這種方式是目前安全廠家流行的流量牽引的安全控制措施。

實現的思路是利用SDN技術中的流量牽引控制協議openflow，引導使用者業務流量按照規定的安全策略流向，結合安全產品的虛擬化技術，建立防火牆、入侵檢測、使用者行為審計、病毒過濾等資源池，在使用者申請虛擬機器資源時，隨著計算資源、儲存資源一起下發給使用者，保證使用者業務的安全。

實現的步驟大致如下：

1.對安全資源虛擬池化：先對安全裝置進行“多到一”的虛擬化，形成一個虛擬的、邏輯的、高處理能力的安全裝置，如虛擬防火牆、虛擬入侵檢測等；再對虛擬的安全裝置進行“一到多”的虛擬，生成使用者定製的、處理能力匹配的虛擬安全裝置；

2.部署流量控制伺服器：為流量控制管理的中心，接受並部署使用者流量的安全策略，當使用者業務虛擬機器遷移時，負責流量牽引策略的遷移落地；該伺服器可以是雙機熱備，提高系統安全性，也可以採用虛擬機器模式。同時，在虛擬計算資源池內安裝流量控制引擎：具體方法是在每個物理伺服器內開一個虛擬機器執行流量控制引擎，負責引導該物理伺服器上所有虛擬機器，按照安全策略進行流量的牽引；

3.使用者業務流量的牽引分為兩種模式：

a)映象模式：針對入侵檢測、行為審計等旁路接入的安全裝置，需要把使用者流量複製出來即可，不影響原先的使用者業務流量；

b)控制模式：針對防火牆等安全閘道器類安全裝置，需要把使用者的流量先引導到安全裝置虛擬化池中，“清洗”流量以後，再把流量引導到正常的業務處理虛擬機器；

4.因為需要改變使用者流量的流向，需要對目的MAC、目的IP進行修改。具體的方案很多，這裡我們採用的是MAC in MAC技術，對資料包二次封裝，經過安全裝置處理以後的“安全流量”恢復到“正常”狀態；在雲朵中的物理交換機與虛擬交換機支援SDN模式時，也可以採用openflow協議進行導引時的封裝；

5.當使用者業務服務的虛擬機器在不同的物理服務中遷移時，該使用者業務的安全策略也隨著遷移到目的物理服務內的流量控制虛擬機器，繼續執行對該使用者的業務流量進行引導。

五、小結

“雲朵”方案通過把不同安全需求的業務系統部署在不同的雲朵內，降低了對雲內業務流隔離的需求，而在雲朵內部，通過流量牽引與虛擬機器加固等辦法，實現網路層面的安全過濾，同時加強業務系統自身的安全管理，如使用者許可權管理、業務行為審計等，實現應用層面的訪問控制，對敏感資料的儲存與傳輸都建議採用加密方式。

“雲朵”方案是個過渡性質的方案，等到雲朵內的安全隔離與控制技術成熟，多個雲朵就可以合成一個雲了。

本文轉自 zhaisj 51CTO部落格，原文連結：http://blog.51cto.com/zhaisj/1213015，如需轉載請自行聯絡原作者