從Code Space消亡看云時代的黑客攻擊行為

對于Code Space在黑客手中消亡這件事兒，由于在金錢上無法滿足黑客，就只能在數(shù)據(jù)上滿足了黑客，也許看來是無法避免的，但事后看來，卻是意見很神奇的事兒。

在感嘆Code Spaces倒閉的文章中，我們發(fā)現(xiàn)了一個問題，相似問題時常發(fā)生。

一個云有一個潛在的致命錯誤，其數(shù)據(jù)以貼錯標簽的形式存在。舊版的API密鑰，可能已被訪問或者通過與第三方合作伙伴的連接泄漏，但調(diào)查仍在進行中。

相反，另一個云托管的SaaS提供者One More Cloud，同樣遭受了黑客的攻擊，但其受攻擊的覆蓋面較小。這是因為它可以在防御和生存中變得十分團結(jié)。若是因此認定云計算不安全，還不如視此次攻擊為云管理改變的方向標。

我們可以看到，兩個黑客的攻擊有很多的相似之處，例如，他們都發(fā)生在AWS EC2中，都是針對GitHubs資料庫，都妥協(xié)于用戶資料。確實，Code Spaces的黑客在某種程度上非常復雜，它包含對DDoS的攻擊，贖金的需求和在控制面板的數(shù)據(jù)刪除。

但這兩種攻擊我們看到了完全不一樣的結(jié)果。Code Spaces是一個代碼托管和軟件協(xié)作平臺，因為簡陋的備份造成了嚴重的數(shù)據(jù)流失，數(shù)據(jù)分離和危機處理最終造成了Code Spaces公司的倒閉。而One More Cloud，為了挽回客戶數(shù)據(jù)面臨為期一周的戰(zhàn)斗，以達到全面數(shù)據(jù)恢復。經(jīng)驗表明，問題的發(fā)現(xiàn)與客戶溝通策略和在受保護賬戶中占得先機的隔離策略都有很大聯(lián)系。

兩家云供應(yīng)商共同的特點是對安全架構(gòu)的混亂認知和不充足的回應(yīng)計劃。值得強調(diào)的是，這兩家公司都已經(jīng)制定安全措施。但其中存在的問題是，攻擊者總能利用安全保護中的漏洞進行攻擊。

不管用戶是否喜歡，在任何類似情形中，云服務(wù)提供商都將責任推卸的一干二凈。訪問管理，備份和數(shù)據(jù)的分離方式仍然是用戶自身的責任。云服務(wù)提供商越來越頻繁的提供安全工具，但用戶是否選擇使用這些安全工具，這完全取決于用戶自身。然而，對于許多企業(yè)來說，這需要他們進入未知的領(lǐng)域，并從業(yè)務(wù)的主線路搶奪了時間和資源。許多在云中的這種遷移承擔不起任何犧牲，這會將用戶的短處暴露出來。

這也許會促成企業(yè)建立一個云計算的危機感。安全已經(jīng)成為一個燙手的山芋，無論是云服務(wù)供應(yīng)商還是企業(yè)都愿意或能夠設(shè)法解決安全問題。他們希望在安全方面共同進步，同時暗自祈禱黑客不要來進行攻擊。但是，相對于感知Code Spaces和一些被直接命中的云，也許用戶應(yīng)該聽從襲擊的警告，公司應(yīng)該將攻擊作為公司云改革的催化劑。目前的“放手”策略不再有效，采取一些基本的安全原則變得更加急切。

從本質(zhì)上講，云計算的網(wǎng)絡(luò)無異于其他任何形式的網(wǎng)絡(luò)架構(gòu)。其中將會有固有的風險需要被評估，也會用來標識業(yè)務(wù)的風險偏好。

現(xiàn)在所需要的是一個久經(jīng)考驗的事故應(yīng)急預(yù)案，渠道內(nèi)部和外部進行有效的溝通以及制定詳細的恢復策略，來達到恢復關(guān)鍵的業(yè)務(wù)運營的效果。然而，在某些時候，應(yīng)該聯(lián)系云服務(wù)供應(yīng)商，以協(xié)調(diào)這些步驟的實施。例如，能夠識別訪問管理控制臺查看和終止活動的會話必須來自供應(yīng)商。

最近幾天，開發(fā)人員試圖通過使用一種稱為Elasticsearch工具來避免這些障礙，這成為安全保護的方式之一并且已被用于云DDoS中。 Elasticsearch可用于執(zhí)行除其他事項外的檢索和在云計算環(huán)境中的文檔登錄，包括AWS EC2服務(wù)。用戶一直呼吁要更新云供應(yīng)商的軟件來修復漏洞，但是，應(yīng)用程序更新將會成為云供應(yīng)商的責任，這是其中的一個風險，即使是更新，只可能是零碎的實施。這在as-hoc安全應(yīng)用中延續(xù)了自力更生的文化，無知和混亂讓攻擊有增無減。

顯然，目前在云中仍有安全盲點，但這些都可以緩解。組織必須確保他們有rudimentaries來實施基于角色的訪問控制，雙因素身份驗證，加密的密鑰存儲和遠程離線備份。

必須具備警覺性，在事故應(yīng)急預(yù)案中設(shè)定的活動監(jiān)測和異常以及定期的安全審查執(zhí)行，以確保足夠的控制。公司可以尋求與這些元素相同的外部援助，但該公司也應(yīng)該勇敢地與云服務(wù)供應(yīng)商進行困難問題的討論。

一定要確定CSP是否持有任何認可資格，特別是ISO27001、ISO9001和ISO20000，并檢查是否提供包括任何此類認證范圍之內(nèi)的服務(wù)。CSP是否有自己的DDoS攻擊緩解解決方案或者它依賴于一個ISP？它有什么防火墻功能做這些擴展并且可以根據(jù)用戶的應(yīng)用程序和業(yè)務(wù)需求進行Web應(yīng)用防火墻設(shè)定？CSP是否提供了多因素身份驗證及VPN的安全訪問？漏洞掃描怎樣發(fā)生以及如何監(jiān)控？

不要害怕，應(yīng)該對數(shù)據(jù)將被存儲在何處（地理和分離方面），活動如何被追蹤（錄音和終止條款）提出問題，保持溝通并尋求補救，了解供應(yīng)商是否可以違反服務(wù)。在后者的情況中，一個專門的標準如BS10008：2008所用的“證據(jù)力和電子信息規(guī)范的法定受理”，如果云供應(yīng)商附著于此，將會有額外的保護。

最近接二連三的攻擊證明許多人一直在等待譴責云的安全問題。但許多de-perimeterisation網(wǎng)絡(luò)實施意味著云現(xiàn)在都有效地工作或在某些時間在虛擬環(huán)境中運行，這樣可以保持創(chuàng)新和對云的完善。

進入云而沒有足夠的安全性就像丟失備用鑰匙或者更糟，在尋找鑰匙失敗后干脆鎖門。這是真實的情況，用戶可能永遠不會被人偷竊，但用戶是否愿意抓住這個提高的機會？除了有效的鎖和鑰匙，門必須是有的放矢，所以用戶和云供應(yīng)商之間必須有安全的關(guān)系。

這樣攻擊的事情在提醒我們，安全性需要得到有效的執(zhí)行，指定責任，有效記錄，以及數(shù)據(jù)備份，并在多個不同的地方存儲數(shù)據(jù)，以達到分散風險的效果。而且，當事情出錯，經(jīng)得起考驗的應(yīng)對策略沒有另一個替代品。但是，我們不能忽視這樣一個事實，云是一種高效的管理數(shù)據(jù)的工具，它可以平衡企業(yè)規(guī)模和競爭。什么是利害攸關(guān)，這不會比人的生計和未來的經(jīng)濟增長更加值得捍衛(wèi)。

原文鏈接：http://www.information-age.com/technology/cloud-and-virtualisation/123458406/catastrophe-cloud-what-aws-hacks-mean-cloud-providers

如您需要了解AWS最新資訊或是技術(shù)文檔可訪問AWS中文技術(shù)社區(qū)；如您有更多的疑問請在AWS技術(shù)論壇提出，稍后會有專家進行答疑。 

訂閱“AWS中文技術(shù)社區(qū)”微信公眾號，實時掌握AWS技術(shù)及產(chǎn)品消息！

AWS中文技術(shù)社區(qū)為廣大開發(fā)者提供了一個Amazon Web Service技術(shù)交流平臺，推送AWS最新資訊、技術(shù)視頻、技術(shù)文檔、精彩技術(shù)博文等相關(guān)精彩內(nèi)容，更有AWS社區(qū)專家與您直接溝通交流！快加入AWS中文技術(shù)社區(qū)，更快更好的了解AWS云計算技術(shù)。

                                                                                                            （譯者/李雪 責編/王玉平） 

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈