原來局限在私有網(wǎng)絡(luò)的資源和數(shù)據(jù)現(xiàn)在暴露在互聯(lián)網(wǎng)上，并且這些資源和數(shù)據(jù)放到了第三方云計(jì)算提供商所有的共享公共網(wǎng)絡(luò)上。

與第一個(gè)風(fēng)險(xiǎn)因素相關(guān)的例子是2008 年12 月報(bào)道的亞馬遜Web 服務(wù)(AWS )漏洞注1。在一篇博客文章中，作者詳細(xì)說明了在數(shù)字簽名算法中的一個(gè)漏洞，“通過HTTP 對亞馬遜SimpleDB 數(shù)據(jù)庫(Amazon SimpleDB )、亞馬遜彈性計(jì)算云(Amazon Elastic Compute Cloud，EC2 )或亞馬遜簡單隊(duì)列服務(wù)(Amazon Simple Queue Service，SQS)執(zhí)行查詢(Query ，又稱REST )請求。”盡管采用HTTPS (代替HTTP )可能會(huì)降低完整性風(fēng)險(xiǎn)，但是不使用HTTPS (卻使用HTTP )的用戶卻面臨著越來越大的風(fēng)險(xiǎn)，他們的數(shù)據(jù)可能在傳輸中被莫名其妙地修改。

注1：這個(gè)問題于2008 年12 月18 日報(bào)告在Colin Percival 的博客“Daemonic Dispatches ”上，參見“AWS signature version 1 is insecure”。在亞馬遜Web 服務(wù)網(wǎng)站上并沒有公開承認(rèn)這個(gè)問題，也沒有對Percival 的博客文章做公開回應(yīng)。

圖3-1 ：私有云計(jì)算的一般拓?fù)鋱D

確保適當(dāng)?shù)脑L問控制

由于資源的一部分(也可能是資源的全部)現(xiàn)在暴露在互聯(lián)網(wǎng)上，公共云使用機(jī)構(gòu)的數(shù)據(jù)將面臨日益增長的風(fēng)險(xiǎn)。對云計(jì)算提供商的網(wǎng)絡(luò)運(yùn)行進(jìn)行審計(jì)(更不用說基于自身網(wǎng)絡(luò)進(jìn)行實(shí)時(shí)監(jiān)控)基本上是不太可能的，哪怕是事后審計(jì)也很困難。能夠獲取的網(wǎng)絡(luò)層面的日志和數(shù)據(jù)不多，而且全面進(jìn)行調(diào)查并收集取證數(shù)據(jù)的能力也是相當(dāng)有限的。

與第二個(gè)風(fēng)險(xiǎn)因素相關(guān)的例子是IP 地址再使用(再分配)的問題。一般來說，當(dāng)用戶不再需要已分配的IP 地址時(shí)，云計(jì)算提供商不再保留用戶的IP 地址。當(dāng)?shù)刂纷優(yōu)榭捎煤螅刂吠ǔＴ俜峙浣o其他用戶使用。從云計(jì)算提供商的角度看，這么做是有道理的。IP 地址數(shù)量有限，同時(shí)也是用于收費(fèi)的資產(chǎn)。然而從用戶安全的角度出發(fā)，IP 地址再分配使用可能會(huì)帶來問題。用戶無法確信他們對資源的網(wǎng)絡(luò)訪問能隨著IP 地址的釋放一并終止，從DNS 中的IP 地址改變到DNS 緩存清理，這之間顯然存在一段時(shí)間延遲。從ARP 表中改變物理地址(例如MAC )到將ARP 地址從緩存中清除也會(huì)有一定的滯后時(shí)間，因此在老的地址被清除之前，還是會(huì)一直存在于ARP 緩存中。這意味著即使地址可能已經(jīng)變化，原先的地址在緩存中依舊有效，因此用戶還是可以訪問到那些理應(yīng)不存在的資源。近期，最大的云計(jì)算提供商之一接到了許多與未失效IP 地址相關(guān)的問題報(bào)告。這極有可能是2008 年3月亞馬遜網(wǎng)絡(luò)極力宣揚(yáng)其彈性IP 地址能力的一個(gè)推動(dòng)因素注2。(使用彈性IP 地址，分配給用戶5個(gè)可路由的IP 地址，而這些地址由用戶控制分派。)此外，根據(jù)Simson Garfinkel：

現(xiàn)有負(fù)載均衡系統(tǒng)中所存在一個(gè)問題導(dǎo)致任何超過231 字節(jié)內(nèi)容的TCP/IP 連接都會(huì)終止。這就意味著超過2GB 的目標(biāo)內(nèi)容必須在亞馬遜簡單存儲(chǔ)服務(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)直接訪問的資源)。這個(gè)問題也存在于提供商為用戶提供的內(nèi)部網(wǎng)絡(luò)以及非可路由IP 地址的分配上注4。雖然資源可能無法通過互聯(lián)網(wǎng)直接獲得，但出于管理的目的，這些資源必須可通過專用地址在提供商網(wǎng)絡(luò)上進(jìn)行訪問。(每個(gè)公共的或者面向互聯(lián)網(wǎng)的資源都有其私有地址。)你的云計(jì)算提供商的其他用戶有可能從內(nèi)部通過云計(jì)算提供商的網(wǎng)絡(luò)獲得你的資源，雖然他們未必會(huì)故意這么做注5。正如在《華盛頓郵報(bào)》中報(bào)道的，亞馬遜Web 服務(wù)存在著對其資源濫用的問題，危及公眾及其他用戶注6。

市面上的一些產(chǎn)品注7可以幫助減輕IP 地址再使用的問題，但除非云計(jì)算提供商把這些產(chǎn)品作為服務(wù)提供給用戶，否則用戶將不得不尋求第三方的產(chǎn)品并支付費(fèi)用，以解決由云計(jì)算提供商所帶來的問題。

確保面向互聯(lián)網(wǎng)資源的可用性

越來越多的數(shù)據(jù)以及越來越多的機(jī)構(gòu)人員都依賴外部托管以確保云計(jì)算提供的資源的可用性，人們對網(wǎng)絡(luò)安全的依賴程度在逐漸上升。因此你的機(jī)構(gòu)一定可以接受我們在之前部分列舉的三個(gè)風(fēng)險(xiǎn)因素。

BGP 注8前綴劫持(例如對網(wǎng)絡(luò)層可達(dá)信息的篡改)為第三個(gè)風(fēng)險(xiǎn)因素提供了很好的示例。前綴劫持包括在未經(jīng)他人允許的情況下通報(bào)屬于他人的自治系統(tǒng)注9地址空間。這樣的通報(bào)常常是由于配置錯(cuò)誤而產(chǎn)生的，但這些錯(cuò)誤的配置可能仍然影響你的基于云計(jì)算的資源的可用性。根據(jù)在2006 年2月提交給北美網(wǎng)絡(luò)運(yùn)營商集團(tuán)(NANOG )的一份研究顯示，這種配置錯(cuò)誤每個(gè)月會(huì)發(fā)生數(shù)百次注10 。這種錯(cuò)誤配置最出名的實(shí)例是在2008 年2 月發(fā)生的。當(dāng)時(shí)巴基斯坦電信公司由于操作失誤，把YouTube 假路由通報(bào)給其位于中國香港的PCCW 電信合作伙伴。由于網(wǎng)站上有據(jù)稱褻瀆的視頻，YouTube 在巴基斯坦是被封鎖的。這次事件的直接結(jié)果是YouTube 在全球范圍內(nèi)無法使用長達(dá)兩個(gè)小時(shí)注11 。

除了配置錯(cuò)誤，還有其他的蓄意攻擊。雖然出于蓄意攻擊的前綴劫持情況遠(yuǎn)少于配置錯(cuò)誤，但這種問題還是會(huì)產(chǎn)生，并阻礙對數(shù)據(jù)的訪問。根據(jù)提交給NANGO 的同份研究報(bào)告顯示，這種前綴劫持攻擊每月出現(xiàn)的次數(shù)在100 次以內(nèi)。雖然這種攻擊并不新穎，但無疑會(huì)隨著云計(jì)算的廣泛使用而增多，也有可能變得十分普遍。隨著云計(jì)算使用的增長，基于云計(jì)算的資源可用性對用戶的價(jià)值也在逐漸增長。這種對用戶不斷增長的價(jià)值也導(dǎo)致了不斷增長的惡意行為風(fēng)險(xiǎn)，給這些資源的可用性帶來了巨大的威脅。

DNS 注12 攻擊也是與第三個(gè)風(fēng)險(xiǎn)因素相關(guān)的例子。事實(shí)上，與云計(jì)算相關(guān)的DNS 攻擊有若干種形式。雖然DNS 攻擊并不新穎也不直接與云計(jì)算相關(guān)，但是由于不斷增加的外部DNS 查詢(減少了“水平分割”DNS 配置的影響注13 )以及越來越多的機(jī)構(gòu)人員愈加依賴網(wǎng)絡(luò)安全以確保其使用的基于云計(jì)算的資源的可用性，導(dǎo)致在網(wǎng)絡(luò)層面上DNS 和云計(jì)算的問題對于機(jī)構(gòu)的風(fēng)險(xiǎn)也在逐步上升。

雖然在2008 年絕大多數(shù)網(wǎng)絡(luò)安全的關(guān)注集中在“Kaminsky Bug”注14(CVE-2008-1447 中“DNS Insufficient Socket Entropy Vulnerability ”)上，但其他的DNS 問題也同樣影響云計(jì)算。DNS 協(xié)議和DNS 的實(shí)施過程注15 中存在著漏洞，DNS 緩存中毒攻擊也十分普遍，這種攻擊欺騙DNS 服務(wù)器接受錯(cuò)誤的信息。雖然很多人認(rèn)為DNS 緩存中毒攻擊在幾年前就已經(jīng)平息，但事實(shí)并非如此，這些攻擊如今仍然是個(gè)大問題，尤其是在云計(jì)算領(lǐng)域內(nèi)。基本的緩存中毒攻擊的變體包括重定向目標(biāo)域名服務(wù)器(NS )，將域名服務(wù)器記錄重定向到其他的目標(biāo)域，并在真正的域名服務(wù)器之前進(jìn)行響應(yīng)(稱之為動(dòng)態(tài)域名服務(wù)器偽造)。

與第三個(gè)風(fēng)險(xiǎn)因素相關(guān)的最后一個(gè)例子是拒絕服務(wù)(DoS )攻擊和分布式拒絕服務(wù)(DDoS )攻擊。同樣地，雖然DoS/DDoS 攻擊并不新穎并且與云計(jì)算沒有直接的聯(lián)系，但由于機(jī)構(gòu)網(wǎng)絡(luò)外部資源使用的增加，在網(wǎng)絡(luò)層面上這些攻擊和云計(jì)算的問題對機(jī)構(gòu)的風(fēng)險(xiǎn)也在逐步上升。例如，在亞馬遜Web 服務(wù)上關(guān)于持續(xù)DDoS 攻擊的消息不斷，使得這些服務(wù)曾一度中斷幾小時(shí)無法供用戶使用注16 。(亞馬遜并沒有承認(rèn)其服務(wù)中斷是由DDoS 攻擊所導(dǎo)致。)

然而，當(dāng)使用基礎(chǔ)設(shè)施即服務(wù)(IaaS )時(shí)，DDoS 攻擊的風(fēng)險(xiǎn)就不僅僅存在于外部(例如面向互聯(lián)網(wǎng))了。通過IaaS 提供商的網(wǎng)絡(luò)供用戶(分散于IaaS 供應(yīng)商的企業(yè)網(wǎng)絡(luò))使用的部分中也存在著內(nèi)部DDoS 攻擊。內(nèi)部(不可路由的)網(wǎng)絡(luò)是分享的資源，用戶可以借此訪問其非公眾事務(wù)(例如Amazon Machine Image，AMI )，并通過提供商對其網(wǎng)絡(luò)和資源(如物理服務(wù)器)進(jìn)行管理。如果我是個(gè)不守規(guī)矩的用戶，沒有任何機(jī)制可以阻止我通過訪問這個(gè)內(nèi)部網(wǎng)絡(luò)來查找或者攻擊其他用戶，抑或攻擊IaaS 提供商的基礎(chǔ)設(shè)施，而且供應(yīng)商也很可能沒有部署任何偵查控制手段，更不用說針對此類攻擊向用戶預(yù)警了。其他用戶唯一能做的預(yù)防措施只有加固他們的事務(wù)(如AMI )，并使用提供商的防火墻功能(如亞馬遜Web 服務(wù))增強(qiáng)業(yè)務(wù)的安全性。

用域替換已建立的網(wǎng)絡(luò)區(qū)域及層面模型

在基礎(chǔ)設(shè)施即服務(wù)(IaaS )和平臺(tái)即服務(wù)(PaaS )中，已有的網(wǎng)絡(luò)區(qū)域及層面不再存在。這些年來，網(wǎng)絡(luò)安全往往依賴于域進(jìn)行構(gòu)建，例如內(nèi)聯(lián)網(wǎng)與外聯(lián)網(wǎng)，開發(fā)與生產(chǎn)，為了改善安全隔離網(wǎng)絡(luò)流量等。這種模式是基于排他性的，只有具有特定角色的個(gè)人和系統(tǒng)才可以訪問特定的區(qū)域。類似地，特定層面內(nèi)的系統(tǒng)往往只可以訪問特定層面。例如，表示層的系統(tǒng)不允許直接與數(shù)據(jù)庫層的系統(tǒng)進(jìn)行通信，而只能與在應(yīng)用域內(nèi)授權(quán)的系統(tǒng)進(jìn)行通信。建立在公共IaaS 和PaaS 上的軟件即服務(wù)(SaaS )云計(jì)算也有類似的特征。然而，在私有IaaS 上建立的公共SaaS (例如Salesforce.com )可按照傳統(tǒng)的隔離模式，但通常不與用戶分享拓?fù)湫畔ⅰ?/p>

典型的網(wǎng)絡(luò)區(qū)域及層面模式在公共云計(jì)算中被“安全組”、“安全域”或者“虛擬數(shù)據(jù)中心”所取代，新的模式在層與層之間有邏輯隔離，但在精確性以及提供的保護(hù)方面不如早先的模式。例如，亞馬遜云計(jì)算中安全組特性允許你的虛擬機(jī)(VM )可以通過虛擬防火墻相互訪問，虛擬防火墻具有基于IP 地址(特定的地址或子網(wǎng))、數(shù)據(jù)包類型(TCP 、UDP 或者ICMP )以及端口(或者端口范圍)進(jìn)行流量過濾的功能。域名現(xiàn)在廣泛應(yīng)用于各種網(wǎng)絡(luò)環(huán)境中，實(shí)現(xiàn)基于DNS 的特定應(yīng)用命名和尋址的目的。例如Google 的App Engine 基于域名對應(yīng)用程序進(jìn)行了邏輯分組，如mytestapp.test.mydomain.com及myprodapp.prod.mydomain.com 。

在網(wǎng)絡(luò)區(qū)域及層面的已有模式中，不僅僅開發(fā)系統(tǒng)邏輯上與生產(chǎn)系統(tǒng)在網(wǎng)絡(luò)層面上相隔離，這兩個(gè)系統(tǒng)在主機(jī)層面上也是物理隔離的(例如它們運(yùn)行在邏輯分隔的網(wǎng)絡(luò)域中，且運(yùn)行于物理隔離的服務(wù)器上)。然而在云計(jì)算中，這種隔離不復(fù)存在。在基于域分割的云計(jì)算模型中，只為尋址提供了邏輯隔離。由于測試域和生產(chǎn)域很可能剛好在同一個(gè)物理服務(wù)器上，于是不再有任何物理隔離的“需要”。此外，早先的邏輯網(wǎng)絡(luò)隔離也不復(fù)存在;現(xiàn)在的測試域和生產(chǎn)域在主機(jī)層面上同時(shí)運(yùn)行在相同的物理服務(wù)器上，只靠VM 監(jiān)控(管理程序)實(shí)現(xiàn)邏輯隔離。

網(wǎng)絡(luò)層減災(zāi)

基于前面部分對風(fēng)險(xiǎn)因素的討論，我們可以做些什么以降低這些不斷增長的風(fēng)險(xiǎn)因素呢？首先要注意到，網(wǎng)絡(luò)層面風(fēng)險(xiǎn)的存在與使用哪方面的云計(jì)算服務(wù)是無關(guān)的。因此風(fēng)險(xiǎn)等級(jí)的確定并不取決于使用哪種服務(wù)，而是取決于你的機(jī)構(gòu)是否打算或者正在使用公共云、私有云還是混合云。雖然有些IaaS 云計(jì)算提供虛擬的網(wǎng)絡(luò)域，這還是無法與內(nèi)部私有云計(jì)算環(huán)境相比的，后者可以執(zhí)行全面的狀態(tài)監(jiān)視以及其他網(wǎng)絡(luò)安全監(jiān)測。

如果你的機(jī)構(gòu)足夠大以至于可以承擔(dān)私有云計(jì)算所需的資源開銷，就可以在網(wǎng)絡(luò)內(nèi)部使用真正的私有云，那么所面臨的風(fēng)險(xiǎn)會(huì)大大降低。在某些情況下，位于云計(jì)算提供商處的私有云可以幫助你滿足安全需求，但這也取決于提供商的能力和成熟度。

你可以通過加密降低安全方面的風(fēng)險(xiǎn)，尤其對傳輸中的數(shù)據(jù)進(jìn)行有效的加密。安全數(shù)字水印可以大大增加他人篡改數(shù)據(jù)的難度，這樣就保證了數(shù)據(jù)的完整性。

云計(jì)算在網(wǎng)絡(luò)層的可用性風(fēng)險(xiǎn)是很難降低的，除非機(jī)構(gòu)在網(wǎng)絡(luò)拓?fù)鋬?nèi)部使用私有云。即使私有云是在云計(jì)算提供商設(shè)施內(nèi)的私有(非共享的)外部網(wǎng)絡(luò)，在網(wǎng)絡(luò)層面上也會(huì)面臨不斷增加的風(fēng)險(xiǎn)，公共云則會(huì)面臨更大的風(fēng)險(xiǎn)。我們在這里先保留些觀點(diǎn)。

即使是有豐富資源的大企業(yè)在網(wǎng)絡(luò)層面的基礎(chǔ)設(shè)施安全上也面臨著相當(dāng)大的挑戰(zhàn)。云計(jì)算相關(guān)風(fēng)險(xiǎn)實(shí)際上是不是比當(dāng)前企業(yè)面臨的風(fēng)險(xiǎn)要大呢？當(dāng)在這方面進(jìn)行比較時(shí)，需要考慮現(xiàn)存的私有和公共的外聯(lián)網(wǎng)，同時(shí)也需要把合作伙伴的關(guān)系考慮進(jìn)來。對那些沒有豐富資源的大企業(yè)，或者是中小企業(yè)(SMB )，使用公共云的風(fēng)險(xiǎn)(假定這些企業(yè)缺乏建立私有云所需的資源)是否真的高于這些企業(yè)目前基礎(chǔ)設(shè)施中所存在的風(fēng)險(xiǎn)呢？在很多情況下，答案也許是否定的，云計(jì)算其實(shí)并不會(huì)帶來更高的風(fēng)險(xiǎn)。

表3-1 列出了在網(wǎng)絡(luò)層面的安全控制。

表3-1 ：網(wǎng)絡(luò)層面的安全控制

注意

由于各提供商的監(jiān)測手段各有不同，用戶需要對提供商已提供的功能進(jìn)行評(píng)估。（編選：免費(fèi)論文下載中心 來源：機(jī)械工業(yè)出版社）