云計算環(huán)境下如何確保數(shù)據(jù)安全性

云計算環(huán)境下如何確保數(shù)據(jù)安全性

與第一個風(fēng)險因素相關(guān)的例子是2008年12月報道的亞馬遜Web服務(wù)(AWS)漏洞注1。在一篇博客文章中，作者詳細說明了在數(shù)字簽名算法中的一個漏洞，“通過HTTP對亞馬遜SimpleDB數(shù)據(jù)庫(AmazonSimpleDB)、亞馬遜彈性計算云(AmazonElasticComputeCloud，EC2)或亞馬遜簡單隊列服務(wù)(AmazonSimpleQueueService，SQS)執(zhí)行查詢(Query，又稱REST)請求?！北M管采用HTTPS(代替HTTP)可能會降低完整性風(fēng)險，但是不使用HTTPS(卻使用HTTP)的用戶卻面臨著越來越大的風(fēng)險，他們的數(shù)據(jù)可能在傳輸中被莫名其妙地修改。注1：這個問題于2008年12月18日報告在ColinPercival的博客“DaemonicDispatches”上，參見“AWSsignatureversion1isinsecure”在亞馬遜Web服務(wù)網(wǎng)站上并沒有公開承認(rèn)這個問題，也沒有對Percival的博客文章做公開回應(yīng)。確保適當(dāng)?shù)脑L問控制由于資源的一部分(也可能是資源的全部)現(xiàn)在暴露在互聯(lián)網(wǎng)上，公共云使用機構(gòu)的數(shù)據(jù)將面臨日益增長的風(fēng)險。對云計算提供商的網(wǎng)絡(luò)運行進行審計(更不用說基于自身網(wǎng)絡(luò)進行實時監(jiān)控)基本上是不太可能的，哪怕是事后審計也很困難。能夠獲取的網(wǎng)絡(luò)層面的日志和數(shù)據(jù)不多，而且全面進行調(diào)查并收集取證數(shù)據(jù)的能力也是相當(dāng)有限的。與第二個風(fēng)險因素相關(guān)的例子是IP地址再使用(再分配)的問題。一般來說，當(dāng)用戶不再需要已分配的IP地址時，云計算提供商不再保留用戶的IP地址。當(dāng)?shù)刂纷優(yōu)榭捎煤螅刂吠ǔＴ俜峙浣o其他用戶使用。從云計算提供商的角度看，這么做是有道理的。IP地址數(shù)量有限，同時也是用于收費的資產(chǎn)。然而從用戶安全的角度出發(fā)，IP地址再分配使用可能會帶來問題。用戶無法確信他們對資源的網(wǎng)絡(luò)訪問能隨著IP地址的釋放一并終止，從DNS中的IP地址改變到DNS緩存清理，這之間顯然存在一段時間延遲。從ARP表中改變物理地址(例如MAC)到將ARP地址從緩存中清除也會有一定的滯后時間，因此在老的地址被清除之前，還是會一直存在于ARP緩存中。這意味著即使地址可能已經(jīng)變化，原先的地址在緩存中依舊有效，因此用戶還是可以訪問到那些理應(yīng)不存在的資源。近期，最大的云計算提供商之一接到了許多與未失效IP地址相關(guān)的問題報告。這極有可能是2008年3月亞馬遜網(wǎng)絡(luò)極力宣揚其彈性IP地址能力的一個推動因素注2。(使用彈性IP地址，分配給用戶5個可路由的IP地址，而這些地址由用戶控制分派。)此外，根據(jù)SimsonGarfinkel：現(xiàn)有負載均衡系統(tǒng)中所存在一個問題導(dǎo)致任何超過231字節(jié)內(nèi)容的TCP/IP連接都會終止。這就意味著超過2GB的目標(biāo)內(nèi)容必須在亞馬遜簡單存儲服務(wù)(S3)中分幾次執(zhí)行，每次執(zhí)行都對應(yīng)著相同目標(biāo)內(nèi)容的不同字節(jié)區(qū)域注3。然而，未失效IP地址以及對資源的未授權(quán)網(wǎng)絡(luò)訪問等問題并不僅僅出現(xiàn)在可路由的IP地址上(例如那些提供互聯(lián)網(wǎng)直接訪問的資源)。這個問題也存在于提供商為用戶提供的內(nèi)部網(wǎng)絡(luò)以及非可路由IP地址的分配上注4。雖然資源可能無法通過互聯(lián)網(wǎng)直接獲得，但出于管理的目的，這些資源必須可通過專用地址在提供商網(wǎng)絡(luò)上進行訪問。(每個公共的或者面向互聯(lián)網(wǎng)的資源都有其私有地址。)你的云計算提供商的其他用戶有可能從內(nèi)部通過云計算提供商的網(wǎng)絡(luò)獲得你的資源，雖然他們未必會故意這么做注5。正如在《華盛頓郵報》中報道的，亞馬遜Web服務(wù)存在著對其資源濫用的問題，危及公眾及其他用戶注6。市面上的一些產(chǎn)品注7可以幫助減輕IP地址再使用的問題，但除非云計算提供商把這些產(chǎn)品作為服務(wù)提供給用戶，否則用戶將不得不尋求第三方的產(chǎn)品并支付費用，以解決由云計算提供商所帶來的問題。確保面向互聯(lián)網(wǎng)資源的可用性越來越多的數(shù)據(jù)以及越來越多的機構(gòu)人員都依賴外部托管以確保云計算提供的資源的可用性，人們對網(wǎng)絡(luò)安全的依賴程度在逐漸上升。因此你的機構(gòu)一定可以接受我們在之前部分列舉的三個風(fēng)險因素。BGP注8前綴劫持(例如對網(wǎng)絡(luò)層可達信息的篡改)為第三個風(fēng)險因素提供了很好的示例。前綴劫持包括在未經(jīng)他人允許的情況下通報屬于他人的自治系統(tǒng)注9地址空間。這樣的通報常常是由于配置錯誤而產(chǎn)生的，但這些錯誤的配置可能仍然影響你的基于云計算的資源的可用性。根據(jù)在2006年2月提交給北美網(wǎng)絡(luò)運營商集團(NANOG)的一份研究顯示，這種配置錯誤每個月會發(fā)生數(shù)百次注10。這種錯誤配置最出名的實例是在2008年2月發(fā)生的。當(dāng)時巴基斯坦電信公司由于操作失誤，把YouTube假路由通報給其位于中國香港的PCCW電信合作伙伴。由于網(wǎng)站上有據(jù)稱褻瀆的視頻，YouTube在巴基斯坦是被封鎖的。這次事件的直接結(jié)果是YouTube在全球范圍內(nèi)無法使用長達兩個小時注11。除了配置錯誤，還有其他的蓄意攻擊。雖然出于蓄意攻擊的前綴劫持情況遠少于配置錯誤，但這種問題還是會產(chǎn)生，并阻礙對數(shù)據(jù)的訪問。根據(jù)提交給NANGO的同份研究報告顯示，這種前綴劫持攻擊每月出現(xiàn)的次數(shù)在100次以內(nèi)。雖然這種攻擊并不新穎，但無疑會隨著云計算的廣泛使用而增多，也有可能變得十分普遍。隨著云計算使用的增長，基于云計算的資源可用性對用戶的價值也在逐漸增長。這種對用戶不斷增長的價值也導(dǎo)致了不斷增長的惡意行為風(fēng)險，給這些資源的可用性帶來了巨大的威脅。DNS注12攻擊也是與第三個風(fēng)險因素相關(guān)的例子。事實上，與云計算相關(guān)的DNS攻擊有若干種形式。雖然DNS攻擊并不新穎也不直接與云計算相關(guān)，但是由于不斷增加的外部DNS查詢(減少了“水平分割”DNS配置的影響注13)以及越來越多的機構(gòu)人員愈加依賴網(wǎng)絡(luò)安全以確保其使用的基于云計算的資源的可用性，導(dǎo)致在網(wǎng)絡(luò)層面上DNS和云計算的問題對于機構(gòu)的風(fēng)險也在逐步上升。雖然在2008年絕大多數(shù)網(wǎng)絡(luò)安全的關(guān)注集中在“KaminskyBug”注14(CVE-2008-1447中“DNSInsufficientSocketEntropyVulnerability”)上，但其他的DNS問題也同樣影響云計算。DNS協(xié)議和DNS的實施過程注15中存在著漏洞，DNS緩存中毒攻擊也十分普遍，這種攻擊欺騙DNS服務(wù)器接受錯誤的信息。雖然很多人認(rèn)為DNS緩存中毒攻擊在幾年前就已經(jīng)平息，但事實并非如此，這些攻擊如今仍然是個大問題，尤其是在云計算領(lǐng)域內(nèi)。基本的緩存中毒攻擊的變體包括重定向目標(biāo)域名服務(wù)器(NS)，將域名服務(wù)器記錄重定向到其他的目標(biāo)域，并在真正的域名服務(wù)器之前進行響應(yīng)(稱之為動態(tài)域名服務(wù)器偽造)。與第三個風(fēng)險因素相關(guān)的最后一個例子是拒絕服務(wù)(DoS)攻擊和分布式拒絕服務(wù)(DDoS)攻擊。同樣地，雖然DoS/DDoS攻擊并不新穎并且與云計算沒有直接的聯(lián)系，但由于機構(gòu)網(wǎng)絡(luò)外部資源使用的增加，在網(wǎng)絡(luò)層面上這些攻擊和云計算的問題對機構(gòu)的風(fēng)險也在逐步上升。例如，在亞馬遜Web服務(wù)上關(guān)于持續(xù)DDoS攻擊的消息不斷，使得這些服務(wù)曾一度中斷幾小時無法供用戶使用注16。(亞馬遜并沒有承認(rèn)其服務(wù)中斷是由DDoS攻擊所導(dǎo)致。)然而，當(dāng)使用基礎(chǔ)設(shè)施即服務(wù)(IaaS)時，DDoS攻擊的風(fēng)險就不僅僅存在于外部(例如面向互聯(lián)網(wǎng))了。通過IaaS提供商的網(wǎng)絡(luò)供用戶(分散于IaaS供應(yīng)商的企業(yè)網(wǎng)絡(luò))使用的部分中也存在著內(nèi)部DDoS攻擊。內(nèi)部(不可路由的)網(wǎng)絡(luò)是分享的資源，用戶可以借此訪問其非公眾事務(wù)(例如AmazonMachineImage，AMI)，并通過提供商對其網(wǎng)絡(luò)和資源(如物理服務(wù)器)進行管理。如果我是個不守規(guī)矩的用戶，沒有任何機制可以阻止我通過訪問這個內(nèi)部網(wǎng)絡(luò)來查找或者攻擊其他用戶，抑或攻擊IaaS提供商的基礎(chǔ)設(shè)施，而且供應(yīng)商也很可能沒有部署任何偵查控制手段，更不用說針對此類攻擊向用戶預(yù)警了。其他用戶唯一能做的預(yù)防措施只有加固他們的事務(wù)(如AMI)，并使用提供商的防火墻功能(如亞馬遜Web服務(wù))增強業(yè)務(wù)的安全性。用域替換已建立的網(wǎng)絡(luò)區(qū)域及層面模型在基礎(chǔ)設(shè)施即服務(wù)(IaaS)和平臺即服務(wù)(PaaS)中，已有的網(wǎng)絡(luò)區(qū)域及層面不再存在。這些年來，網(wǎng)絡(luò)安全往往依賴于域進行構(gòu)建，例如內(nèi)聯(lián)網(wǎng)與外聯(lián)網(wǎng)，開發(fā)與生產(chǎn)，為了改善安全隔離網(wǎng)絡(luò)流量等。這種模式是基于排他性的，只有具有特定角色的個人和系統(tǒng)才可以訪問特定的區(qū)域。類似地，特定層面內(nèi)的系統(tǒng)往往只可以訪問特定層面。例如，表示層的系統(tǒng)不允許直接與數(shù)據(jù)庫層的系統(tǒng)進行通信，而只能與在應(yīng)用域內(nèi)授權(quán)的系統(tǒng)進行通信。建立在公共IaaS和PaaS上的軟件即服務(wù)(SaaS)云計算也有類似的特征。然而，在私有IaaS上建立的公共SaaS(例如S)可按照傳統(tǒng)的隔離模式，但通常不與用戶分享拓撲信息。典型的網(wǎng)絡(luò)區(qū)域及層面模式在公共云計算中被“安全組”、“安全域”或者“虛擬數(shù)據(jù)中心”所取代，新的模式在層與層之間有邏輯隔離，但在精確性以及提供的保護方面不如早先的模式。例如，亞馬遜云計算中安全組特性允許你的虛擬機(VM)可以通過虛擬防火墻相互訪問，虛擬防火墻具有基于IP地址(特定的地址或子網(wǎng))、數(shù)據(jù)包類型(TCP、UDP或者ICMP)以及端口(或者端口范圍)進行流量過濾的功能。域名現(xiàn)在廣泛應(yīng)用于各種網(wǎng)絡(luò)環(huán)境中，實現(xiàn)基于DNS的特定應(yīng)用命名和尋址的目的。例如Google的AppEngine基于域名對應(yīng)用程序進行了邏輯分組，如及。在網(wǎng)絡(luò)區(qū)域及層面的已有模式中，不僅僅開發(fā)系統(tǒng)邏輯上與生產(chǎn)系統(tǒng)在網(wǎng)絡(luò)層面上相隔離，這兩個系統(tǒng)在主機層面上也是物理隔離的(例如它們運行在邏輯分隔的網(wǎng)絡(luò)域中，且運行于物理隔離的服務(wù)器上)。然而在云計算中，這種隔離不復(fù)存在。在基于域分割的云計算模型中，只為尋址提供了邏輯隔離。由于測試域和生產(chǎn)域很可能剛好在同一個物理服務(wù)器上，于是不再有任何物理隔離的“需要”。此外，早先的邏輯網(wǎng)絡(luò)隔離也不復(fù)存在;現(xiàn)在的測試域和生產(chǎn)域在主機層面上同時運行在相同的物理服務(wù)器上，只靠VM監(jiān)控(管理程序)實現(xiàn)邏輯隔離。網(wǎng)絡(luò)層減災(zāi)基于前面部分對風(fēng)險因素的討論，我們可以做些什么以降低這些不斷增長的風(fēng)險因素呢？首先要注意到，網(wǎng)絡(luò)層面風(fēng)險的存在與使用哪方面的云計算服務(wù)是無關(guān)的。因此風(fēng)險等級的確定并不取決于使用哪種服務(wù)，而是取決于你的機構(gòu)是否打算或者正在使用公共云、私有云還是混合云。雖然有些IaaS云計算提供虛擬的網(wǎng)絡(luò)域，這還是無法與內(nèi)部私有云計算環(huán)境相比的，后者可以執(zhí)行全面的狀態(tài)監(jiān)視以及其他網(wǎng)絡(luò)安全監(jiān)測。如果你的機構(gòu)足夠大以至于可以承擔(dān)私有云計算所需的資源開銷，就可以在網(wǎng)絡(luò)內(nèi)部使用真正的私有云，那么所面臨的風(fēng)險會大大降低