原來局限在私有網絡的資源和數據現在暴露在互聯網上，并且這些資源和數據放到了第三方云計算提供商所有的共享公共網絡上。

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

注1：這個問題于2008 年12 月18 日報告在Colin Percival 的博客“Daemonic Dispatches ”上，參見“AWS signature version 1 is insecure”。在亞馬遜Web 服務網站上并沒有公開承認這個問題，也沒有對Percival 的博客文章做公開回應。

圖3-1 ：私有云計算的一般拓撲圖

確保適當的訪問控制

由于資源的一部分(也可能是資源的全部)現在暴露在互聯網上，公共云使用機構的數據將面臨日益增長的風險。對云計算提供商的網絡運行進行審計(更不用說基于自身網絡進行實時監控)基本上是不太可能的，哪怕是事后審計也很困難。能夠獲取的網絡層面的日志和數據不多，而且全面進行調查并收集取證數據的能力也是相當有限的。

與第二個風險因素相關的例子是IP 地址再使用(再分配)的問題。一般來說，當用戶不再需要已分配的IP 地址時，云計算提供商不再保留用戶的IP 地址。當地址變為可用后，地址通常再分配給其他用戶使用。從云計算提供商的角度看，這么做是有道理的。IP 地址數量有限，同時也是用于收費的資產。然而從用戶安全的角度出發，IP 地址再分配使用可能會帶來問題。用戶無法確信他們對資源的網絡訪問能隨著IP 地址的釋放一并終止，從DNS 中的IP 地址改變到DNS 緩存清理，這之間顯然存在一段時間延遲。從ARP 表中改變物理地址(例如MAC )到將ARP 地址從緩存中清除也會有一定的滯后時間，因此在老的地址被清除之前，還是會一直存在于ARP 緩存中。這意味著即使地址可能已經變化，原先的地址在緩存中依舊有效，因此用戶還是可以訪問到那些理應不存在的資源。近期，最大的云計算提供商之一接到了許多與未失效IP 地址相關的問題報告。這極有可能是2008 年3月亞馬遜網絡極力宣揚其彈性IP 地址能力的一個推動因素注2。(使用彈性IP 地址，分配給用戶5個可路由的IP 地址，而這些地址由用戶控制分派。)此外，根據Simson Garfinkel：

現有負載均衡系統中所存在一個問題導致任何超過231 字節內容的TCP/IP 連接都會終止。這就意味著超過2GB 的目標內容必須在亞馬遜簡單存儲服務(S3 )中分幾次執行，每次執行都對應著相同目標內容的不同字節區域注3。

然而，未失效IP 地址以及對資源的未授權網絡訪問等問題并不僅僅出現在可路由的IP 地址上(例如那些提供互聯網直接訪問的資源)。這個問題也存在于提供商為用戶提供的內部網絡以及非可路由IP 地址的分配上注4。雖然資源可能無法通過互聯網直接獲得，但出于管理的目的，這些資源必須可通過專用地址在提供商網絡上進行訪問。(每個公共的或者面向互聯網的資源都有其私有地址。)你的云計算提供商的其他用戶有可能從內部通過云計算提供商的網絡獲得你的資源，雖然他們未必會故意這么做注5。正如在《華盛頓郵報》中報道的，亞馬遜Web 服務存在著對其資源濫用的問題，危及公眾及其他用戶注6。

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

確保面向互聯網資源的可用性

越來越多的數據以及越來越多的機構人員都依賴外部托管以確保云計算提供的資源的可用性，人們對網絡安全的依賴程度在逐漸上升。因此你的機構一定可以接受我們在之前部分列舉的三個風險因素。

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

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

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

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

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

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

用域替換已建立的網絡區域及層面模型

在基礎設施即服務(IaaS )和平臺即服務(PaaS )中，已有的網絡區域及層面不再存在。這些年來，網絡安全往往依賴于域進行構建，例如內聯網與外聯網，開發與生產，為了改善安全隔離網絡流量等。這種模式是基于排他性的，只有具有特定角色的個人和系統才可以訪問特定的區域。類似地，特定層面內的系統往往只可以訪問特定層面。例如，表示層的系統不允許直接與數據庫層的系統進行通信，而只能與在應用域內授權的系統進行通信。建立在公共IaaS 和PaaS 上的軟件即服務(SaaS )云計算也有類似的特征。然而，在私有IaaS 上建立的公共SaaS (例如Salesforce.com )可按照傳統的隔離模式，但通常不與用戶分享拓撲信息。

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

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

網絡層減災

基于前面部分對風險因素的討論，我們可以做些什么以降低這些不斷增長的風險因素呢？首先要注意到，網絡層面風險的存在與使用哪方面的云計算服務是無關的。因此風險等級的確定并不取決于使用哪種服務，而是取決于你的機構是否打算或者正在使用公共云、私有云還是混合云。雖然有些IaaS 云計算提供虛擬的網絡域，這還是無法與內部私有云計算環境相比的，后者可以執行全面的狀態監視以及其他網絡安全監測。

如果你的機構足夠大以至于可以承擔私有云計算所需的資源開銷，就可以在網絡內部使用真正的私有云，那么所面臨的風險會大大降低。在某些情況下，位于云計算提供商處的私有云可以幫助你滿足安全需求，但這也取決于提供商的能力和成熟度。

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

云計算在網絡層的可用性風險是很難降低的，除非機構在網絡拓撲內部使用私有云。即使私有云是在云計算提供商設施內的私有(非共享的)外部網絡，在網絡層面上也會面臨不斷增加的風險，公共云則會面臨更大的風險。我們在這里先保留些觀點。

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

表3-1 列出了在網絡層面的安全控制。

表3-1 ：網絡層面的安全控制

注意

由于各提供商的監測手段各有不同，用戶需要對提供商已提供的功能進行評估。（編選：免費論文下載中心 來源：機械工業出版社）