本文摘要:HyperStratus諮詢公司首席執行官伯納德·戈爾登(Bernard Golden)撰文指出,一個接一個的調查表明,對於公有雲計算,安全是潛在使用者最擔心的問題。 例如,2010年4月的一項調查指出,45%的以上的受訪者感到雲計算帶來的風險超過了收益。
HyperStratus諮詢公司首席執行官伯納德·戈爾登(Bernard Golden)撰文指出,一個接一個的調查表明,對於公有雲計算,安全是潛在使用者最擔心的問題。 例如,2010年4月的一項調查指出,45%的以上的受訪者感到雲計算帶來的風險超過了收益。 CA和Ponemon Institute進行的一項調查也發現了類似的擔心。 但是,他們還發現,儘管有這些擔心,雲應用還是在部署著。 類似的調查和結果的繼續發佈表明人們對雲計算安全的不信任繼續存在。
當然,大多數對雲計算的擔心與公有雲計算有關。 全球IT從業者不斷地對使用一個公有雲服務提供者提出同樣的問題。 例如,戈爾登本周去了臺灣並且在臺灣雲SIG會議上發表了演講。 有250人參加了這個會議。 正如預料的那樣,人們向他提出的第一個問題是「公有雲計算足夠安全嗎,我是否應該使用私有雲以避免安全問題?」 所有的人似乎都認為公有雲服務提供者是不可信賴的。
然而,把雲安全的討論歸結為「公有雲不安全,私有雲安全」的公式似乎過於簡單化。 簡單地說,這個觀點存在兩個大謊言(或者說是兩個基本的誤會)。 主要原因是這種新的計算模式迫使安全產品和方法發生了巨大變化。
第一個雲安全謊言
第一個謊言是私有雲是安全的,這個結論的依據僅僅是私有雲的定義:私有雲是在企業自己的資料中心邊界範圍內部署的。 這個誤解產生于這樣一個事實:雲計算包含與傳統的計算不同的兩個關鍵區別:虛擬化和活力。
第一個1區別是,雲計算的技術基礎是在一個應用的管理程式的基礎上的。 管理程式能夠把計算(及其相關的安全威脅)與傳統的安全工具隔離開,檢查網路通訊中不適當的或者惡意的資料包。 由於在同一台伺服器中的虛擬機器能夠完全通過管理程式中的通信進行溝通,資料包能夠從一個虛擬機器發送到另一個虛擬機器,不必經過物理網路。 一般安裝的安全設備在物理網路檢查通訊流量。
至關重要的是,這意味著如果一個虛擬機器被攻破,它能夠把危險的通信發送到另一個虛擬機器,機構的防護措施甚至都不會察覺。 換句話說,一個不安全的應用程式能夠造成對其它虛擬機器的攻擊,使用者採用的安全措施對此無能為力。 僅僅因為一個使用者的應用程式位於私有雲並不能保護這個應用程式不會出現安全問題。
當然,人們也許會指出,這個問題是與虛擬化一起出現的,沒有涉及到雲計算的任何方面。 這個觀點是正確的。 雲計算代表了虛擬化與自動化的結合。 它是私有雲出現的另一個安全缺陷的第二個因素。
雲計算應用程式得益于自動化以實現靈活性和彈性,能夠通過迅速遷移虛擬機器和啟動額外的虛擬機器來管理變化的工作量,並對不斷變化的應用狀況做出回應。 這意味著新的實例在幾分鐘之內就可以上線,不用任何人工干預。 這意味著任何必要的軟體安裝或者配置也必須實現自動化。 這樣,當新的實例加入現有的應用程式池的時候,它能夠立即作為一個資源使用。
同樣,它還意味著任何需要的安全軟體必須自動化地安裝和配置,不需要人工干預。 遺憾的是,許多機構依靠安全人員或者系統管理員人工安裝和配置必要的安全性群組件,但這通常是作為這台機器的其它軟體元件安裝和配置完畢之後的第二個步驟。
換句話說,許多機構在安全實踐與雲要求的現實方面是不匹配的。 估計私有雲本身是安全的這個觀點是不正確的。 在你的安全和基礎設施實踐與自動化的實例一致之前,肯定會產生安全性漏洞。
而且,使它們一致是非常重要的。 否則,你可能出現這種情況:你的應用程式自動化超過了你的安全實踐的應對能力。 這不是一個好現象。 毫無疑問,人們不喜歡解釋為什麼好像安全的私有雲最終還是有安全性漏洞,因為雲計算的自動化特徵還沒有擴展到軟體基礎設施的所有方面。
因此,關於雲計算的第一個大謊言的結果是私有雲本身就是不安全的。
第二個雲安全謊言
關於雲計算安全的第二個謊言是對公有雲安全的推測,特別是推測公有雲計算的安全完全取決於雲服務提供者。 現實是,服務提供者領域的安全是供應商與使用者共同承擔的責任。 服務提供者負責基礎設施的安全以及應用程式與託管的環境之間的介面的安全;使用者負責接入這個環境的介面的安全,更重要的是負責應用程式本身的內部安全。
沒有正確地配置應用程式,如環境安全介面或者沒有採取適當的應用程式級安全預防措施,會使使用者產生一些問題。 任何供應商也許都不會對這種問題承擔責任。
讓我提供一個例子。 與我們合作的一家公司把自己核心的應用程式放在亞馬遜的Web服務中。 遺憾的是這家公司既沒有針對亞馬遜Web服務安全機制可能存在漏洞部署安全措施,也沒有針對應用程式設計的問題採取措施。
實際上,亞馬遜提供了一個虛擬機器級別的防火牆(稱作安全性群組)。 人們配置這個防火牆以允許資料包訪問具體的埠。 與安全性群組有關的最佳做法是對它們進行分區,這樣,就會為每一個虛擬機器提供非常精細的訪問埠。 這將保證只有適用于那種類型機器的通信才能夠訪問一個實例。 例如,一台Web伺服器虛擬機器經過配置允許埠80上的通信訪問這個實例,同時,資料庫虛擬機器經過配置允許埠80上的通訊訪問這個實例。 這就阻止了來自外部的利用web通信對包含重要應用程式資料的資料庫實例的攻擊。
要建立一個安全的應用程式,人們必須正確地使用安全性群組。 但下述這個使用者沒有這樣做。 它對於訪問所有實例的通信都使用一個安全性群組。 這意味著訪問任何實例的任何類型的通信都可以訪問每一種類型的實例。 這顯然是糟糕地使用亞馬遜Web服務安全機制的一個例子。
關於使用者的應用程式本身,它採用了糟糕的安全措施。 它沒有在不同類型的機器之中對應用程式代碼分區,它把所有的應用程式代碼都裝載到同一個實例中。 這個實例接收其企業網站的通信,還有包含專有演算法的代碼。
這種情況的關鍵事實是:如果這個使用者以為所有的安全責任都由雲服務提供者來承擔(在這個案例中是亞馬遜Web服務),這將是一個嚴重的疏忽,因為它沒有採取重要的步驟來解決安全問題, 而這個安全問題是沒有任何一個雲服務提供者會承擔相關責任的。 這就是共同承擔責任的意義——雙方必須建立自己控制的安全方面。 沒有這樣做,意味著應用程式是不安全的。 即使雲服務提供者在自己控制的範圍內所做的一切都是正確的,如果這個應用程式的擁有者沒有正確地履行自己的責任,這個應用程式也將會不安全。
戈爾登稱,我曾經見過許多安全人員討論有關公有雲服務提供者的問題。 他們拒絕承擔自己的公司在公有雲環境中的責任,堅持把每一個安全話題轉向對雲服務提供者的擔心。
坦率地說,這使我感到他們是輕率的,因為這暗示他們拒絕認真地做一些必要的工作以便創建一個基於公有雲服務提供者的盡可能安全的應用程式。 這個態度好像所有的安全責任都在雲服務提供者身上,進一步發展就是認為他的公司與在雲服務提供者環境中運行的應用程式的任何安全事故都無關。 因此,這種情況並不讓人感到意外:有關人士堅決支援私有雲,聲稱私有雲有優越的安全性。
現實是,使用者正在越來越多地在公有雲服務提供者環境中部署應用程式。 安全性群組織保證自己採取一切可能的步驟盡可能安全地執行應用程式是非常重要的。 這意味著使用者本身也需要在這方面採取些什麼步驟。
因此,安全是雲計算的第三條軌道。 安全一直被說成是私有雲固有的好處和公有雲計算的基本缺陷。 實際上,事實比這些情況暗示的還要模糊不清。 斷言公有雲環境有安全缺陷,不認真考慮如何緩解這些不安全因素,似乎是不負責任的。
一個管理不善和配置糟糕的私有雲應用程式是非常容易受到攻擊的。 而一個管理妥當的和配置合格的公共雲應用程式卻能夠達到很好的安全性。 把這種情況描非黑即白地簡單化,會危害這個雲環境。
在這兩個環境中的更有建設性的做法是詢問必須採取什麼行動才能實現在時間、預算和容許風險的條件下盡可能保證應用程式安全的目標。 考慮到一個具體環境和應用,安全從來不是一個或黑或白的簡單問題,而是如何盡可能地將黑色變成白色的問題。
(責任編輯:呂光)