云計算既指的是服務在網絡上的應用程序也指的是在數據中心提供服務的硬件及軟件。云供應商使用虛擬技術通過網絡設施為計算資源提供各種自助服務。 在云環境中，各種各樣的虛擬設備被放置在同一個物理服務器上作為基礎設施來使用。 云計算發展到今天，共有三種云類型：公有云、私有云及混合云。 公有云是一種由供應商提供幾種資源的典型模型，這些資源包括有應用程序和數據的存儲給公眾使用。私有云指的是普通人無法獲得的企業內部的服務?；旌显茷槠髽I在內部提供和控制一些資源提供了一種環境，同時也為公眾提供資源供大家使用。因此，私有云與公共云的結合被稱為混合云。對于云計算這種新推出的技術而言，它也有自身存在的問題，其中一個問題就是隨機存?。≧AS）。
1 云中的隨機存?。≧AS）
當用戶的數據被轉移到云中就有了兩種變化。 第一，數據將會從用戶的本地計算機被轉移出去，第二數據將從單終端的環境中被轉移到多終端上。這些變化帶給人們對數據泄漏方面的關注。 因此，從安全的角度來考慮數據泄漏已經成為云計算機中最大的風險之一。
當前，為了減輕這些問題對云的影響，云供應商更愿意使用數據防泄漏保護程序（DLP）對敏感數據進行保護。 但是，如果數據被存儲在了共有云中，由于該云的特質所決定，使用數據保護應用程序的意義不大。 但在 SaaS 和 PaaS 中使用數據防泄漏保護程序（DLP）對用戶數據進行保護是不可能的，除非，云供應商把 DLP 放在服務里。而且，把 DLP 放入虛擬環境運行也是可以的。 與其它云類型不同，IaaS 本身就可以實現對相關數據的控制。
在私有云中，用戶對全部基礎設施享有直接的控制，是否把數據防泄漏保護程序（DLP）放置在 SaaS,PaaS 或 IaaS 中不是一個政策性問題。 然而，DLP 是否與你的 AaaS 或 PaaS 服務相互協作有可能是一個技術性的問題。 在混合云中，如果服務是IaaS,用戶可以通過設置 DLP 來控制數據。
2 云中的 IP 地址攻擊
因特網使用最著名的 TCP/IP 協議來定位每個 IP 地址在網絡中的位置，而網絡對于云供應商而言也只是用于交流的基礎設施。 與在 Inter 網中的物理計算機都有自己的 IP 地址一樣，網絡中的虛擬機同樣也有 IP 地址。 無論是外部還是內部的網絡，無論是非法用戶還是合法用戶，都一樣能找到他們的 IP地址。因此，在這種情況下，非法用戶能夠找到哪個物理服務器正在使用，并通過植入惡意的虛擬機的方式發動攻擊。 因為所有用戶都使用同樣的虛擬機作為基礎設施，如果攻擊者竊取或控制了虛擬機，他就可以訪問機器內所有用戶的數據。因此，黑客會在云供應商檢測到虛擬機失去控制之前就已經把數據復制到了他的機器中，然后通過數據分析，黑客就可以找到有價值的數據。
3 對云的分布式拒絕服務（DDoS）攻擊
分布式拒絕服務（DDoS）攻擊采用向特定的網絡入口發送大量的 IP 數據包的方式進行攻擊。 在黑名單模式下對任何形式的硬件進行操作都會很快出現癱瘓的狀態。 在云計算機中，由于基礎設施是被大量的用戶所共享的，所以 DDoS 攻擊有時會比單終端體系結構下所受的內在影響更大。如果云有很多的資源提供給用戶，很容易引起分布式拒絕服務（DDoS）的攻擊。
解決這個問題的一個常規性方法即增加重要資源的存儲數量。
但是當用戶蓄意使用“僵尸網絡”（bot-net）運行 DDoS 的話就會出現更嚴重的問題。
大多數的網絡措施不能阻止 DDoS 的攻擊。同它們沒有辦法阻止數據溢出一樣， 網絡同樣也不能區分有用的信息和有害的信息。 如果攻擊已經被識別并且具有已知的鮮明特征，那么入侵防御系統（IPS）還有比較有效的。反之，如果它們內容合法但懷有惡意攻擊的話，IPS 就會變的無效。 不幸的是，與 IPS 的解決方案類似，面對 DDoS 的攻擊，防火墻顯得即無效又容易受到攻擊，攻擊者會從云的服務器或是云中的網絡聯接點中蓄意發送大量的合法信息到服務器上，從而導致服務器不能處理這些信息，這時他們就可以很容易地穿越防火墻和 IPS 服務。 準確的來說，DDoS防護網絡虛擬層的一部分，而非服務器虛擬。 例如，云計算使用虛擬機可以防止來自網絡層的地址解析（ARP）欺騙。
4 結論
基于云的應用程序是以網絡應用軟件為基礎， 使用它的操作系統，在虛擬的環境下的虛擬機上運行的。 虛擬的應用程序使的企業從一些日常的維護、軟件升級、配置和其它的處理任務的管理事務中解脫出來。 但是云與其它的以網絡為基礎的其它技術一樣也會有風險。如強大的 DDoS 攻擊，作為解決方法，云供應商要增加更多的資源保護自己以避免類似的攻擊。 因此，向云中的轉移還需要考慮很多的參數并要慎重地考慮安全問題。
參考文獻：
[1] 王 旭 , 朱 慶財 . 淺 議云計算機環境下的信息安全問題 [J]. 信 息技術 ,2013,42:20-23.
[2]陳其云，陳志康?；?于模型分析的云安全風險與對策研究[J].現 代電信科技，2012（05）：68-71.
