盤點云計算安全事故 |
發布時間: 2012/7/30 10:35:25 |
自古英雄難過美人關。英雄的卓越功勛在世人眼中是有目共睹的,但是惟獨過不了“美人”這一關。而如今,與此類似,谷歌、亞馬遜以及微軟這樣的國際IT巨頭,一度是何等的威武,但是在面對云計算“安全”這一關,也顯得有些束手無策。從云計算服務誕生的那一天起,頻頻爆出一些安全事件,讓用戶本來就有些狐疑的心更加不安了。
就在上個月,云計算服務提供商Amazon(亞馬遜)公司爆出了史前最大的宕機事件。4月21日凌晨,亞馬遜公司在北弗吉尼亞州的云計算中心宕機,這導致包括回答服務Quora、新聞服務Reddit、Hootsuite和位置跟蹤服務FourSquare在內的一些網站受到了影響。 這些網站都依靠亞馬遜的這個云計算中心提供服務。Quora網站周四上午和下午在英國都無法訪問。這個網站完全由亞馬遜的EC2(彈性云計算)服務托管,就像FourSquare和許多其它網站一樣。 受到影響,Hootsuite網站的響應速度很慢,而Reddit網站的搜索服務不能使用。Reddit網站稱,亞馬遜目前正出現服務下降的情況。亞馬遜云服務中斷持續將近4天,截止編者發稿時,Hootsuite、Reddit、FourSquare、Quora等網站已經基本恢復正常。 根據分析,亞馬遜的云計算狀態網頁目前顯示故障發生在北弗吉尼亞州的云計算中心。這個中心為許多Web 2.0公司提供服務。這次宕機故障發生在美國西海岸的大約凌晨1點40分,英國夏令時上午9點40分,并且從那時起一直有故障。 分析人士稱,北弗吉尼亞州云計算中心是亞馬遜經營的許多云計算中心之一,按照常規,系統的設計之處應用會考慮,一個中心宕機不會中斷其它的云計算中心,也不會影響使用那個服務的用戶。 此次,亞馬遜云計算中心沒有繞過北弗吉尼亞州云計算中心的故障把工作量轉移到許多其它的云計算中心,令人生疑。服務器宕機,這在人們預想當中,沒有那么嚴重。最簡單的,雙機熱備,一臺服務器宕機,另外一臺服務器在短時間內可以啟動,并不會影響用戶的服務。但是,亞馬遜的云計算中心這次不同,宕機影響了這么多用戶的正常云服務,而且引起用戶服務中斷的,還是亞馬遜引以為傲的彈性云,這對于云計算服務商剛剛建立起來的信任,絕對是一次沉重的打擊。 經過一番緊急的搶救,亞馬遜的云服務恢復了正常。但是,這個事件留給用戶的惡劣影響有些深遠,用戶大呼“傷不起”。 好在亞馬遜的態度還算坦誠。4月30日,亞馬遜為宕機事件向用戶發表了5700多字的道歉信,聲稱亞馬遜公司已經知道漏洞和設計缺陷所在的地方,它希望通過修復那些漏洞和缺陷提高EC2(亞馬遜ElasticComputeCloud服務)的競爭力。亞馬遜已經對EC2做了一些修復和調整,并打算在未來幾周里擴大部署,以便對所有的服務進行改善,避免類似的事件再度出現。 在賠償方面,亞馬遜表示,將向在此次故障中受到影響的用戶提供10天服務的點數(Credit),這些點數將自動充值到受影響的用戶帳號當中。但是,對于以后如何避免出現類似事件,并沒有提到任何法律上的保證。 據了解,亞馬遜云服務中斷持續了近4天,但是在法律上卻沒有違反亞馬遜EC2服務的服務等級協議(簡稱SLA)。亞馬遜的解釋是,亞馬遜出現故障的是EBS和RDS服務,而不是EC2服務,從法律上講,它并沒有違反服務等級協議。并且,對于亞馬遜提出的應對宕機事件的建議——多點備份,僅僅是一個技術規范并非合同保障。這些,似乎都不能給云服務的用戶帶來信心。 表面看來,亞馬遜宕機事件似乎有一個完美結局:廠商及時修復漏洞,書面道歉,賠償損失。但是,用戶心理上對云服務的恐懼似乎并不那么容易康復,未來,亞馬遜可能不僅僅要在技術上、還需要在制度和法律上給予用戶更多的保證,才能才能漸漸修復被此次宕機事件損壞的名聲。 歷數頻頻發生的云服務事件不僅亞馬遜,云計算領域充滿競爭的其他公司,如谷歌和微軟等,在近幾年也頻頻發生云服務“中斷”事件。 事件一:Google Gmail郵箱爆發全球性故障 Gmail是Google在2004年愚人節推出的免費郵件服務,但是自從推出這項服務以來,時有發生的“中斷”事件就成為業界的廣泛討論的話題。 2009年2月24日,谷歌的Gmail電子郵箱爆發全球性故障,服務中斷時間長達4小時。谷歌解釋事故的原因:在位于歐洲的數據中心例行性維護之時,有些新的程序代碼(會試圖把地理相近的數據集中于所有人身上)有些副作用,導致歐洲另一個資料中心過載,于是連鎖效應就擴及到其它數據中心接口,最終釀成全球性的斷線,導致其他數據中心也無法正常工作。 事件過去數日之后,Google宣布針對這一事件,谷歌向企業、政府機構和其他付費GoogleAppsPremier Edition客戶提供15天免費服務,補償服務中斷給客戶造成的損失,每人合計2.05美元。 2009年3月17日,微軟的云計算平臺Azure停止運行約22個小時。 雖然,微軟沒有給出詳細的故障原因,但有業內人士分析,Azure平臺的這次宕機與其中心處理和存儲設備故障有關。Azure平臺的宕機可能引發微軟客戶對該云計算機服務平臺的安全擔憂,也暴露了云計算的一個巨大隱患。 不過,當時的Azure尚處于“預測試”階段,所以出現一些類似問題也是可接受。提前暴露的安全問題,似乎也給微軟的Azure團隊敲了一次警鐘,在云計算平臺上,安全是客戶最看重的環節。 2010年,Azure平臺正式投入商用,成為開發者喜愛的云平臺之一。 事件三:Rackspace云服務中斷。 2009年6月,Rackspace遭受了嚴重的云服務中斷故障。供電設備跳閘,備份發電機失效,不少機架上服務器停機。這場事故造成了嚴重的后果。
為了挽回公司聲譽,Rackspace更新了所有博客,并在其中詳細討論了整個經過。但用戶并不樂意接受。 同年11月,Rackspace再次發生重大的服務中斷后。事實上,它的用戶是完全有機會在服務中斷后公開指責這位供應商的,但用戶卻表示“該事故并不是什么大事。”看來Rackspace不是走好運,而是持續提供了充足更新并快速修復了這些錯誤。 在服務中斷致使其業務脫機15到20分鐘后,博客服務提供商Posterous的創建者之一Sachin Agarwal就發表了自己的觀點。Agarwal對此并不生氣,相反,他表示Rackspace在這件事上做得“很透明”,處理問題也很及時到位。 看來,如果沒有嚴重數據的丟失,并且服務快速恢復,用戶依舊保持愉快的使用體驗。對于所謂的“100%正常運行”,大多數用戶似乎不會因為偶爾的小事故而放棄供應商,只是不要將問題堆積起來。 本文出自:億恩科技【www.laynepeng.cn】 |