如今，企業(yè)上云的數(shù)量已經(jīng)穩(wěn)步增加，中小企業(yè)青睞于其物理基礎設施的經(jīng)濟性選擇，而大企業(yè)則喜歡充分利用云服務的靈活性。然而，現(xiàn)在他們也都面臨了一個挑戰(zhàn)，尤其是那些剛剛上云的企業(yè)，他們還并不熟悉云上業(yè)務的運作方式、與純本地系統(tǒng)的的差異。云設置經(jīng)常不僅僅只涉及一個設施，經(jīng)常要和物理數(shù)據(jù)中心想結合。

因此，這個挑戰(zhàn)會延伸到安全層面，當云安全部署不充分或者對于配置參數(shù)不熟悉時，會存在許多風險。許多因素會導致工作負載和應用程序暴露在網(wǎng)絡上招致攻擊，包括錯誤的配置、技術的合理使用、運營經(jīng)驗和云系統(tǒng)防護，甚至是對于部分研發(fā)人員和云工程師的風險忽視。云系統(tǒng)的組成因素在很多方面是相互交織的，這會導致潛在攻擊媒介難以追蹤。對于剛開始使用云平臺和服務的IT安全人員來說，安全這個任務十分艱巨。

不管是云平臺還是云服務，結果發(fā)現(xiàn)配置錯誤一直是云安全主要的陷阱之一，而且還會對訂閱云服務的企業(yè)和托管在云上的軟件用戶有所影響。

全域可寫的亞馬遜S3存儲桶

AWS憑借其多種產(chǎn)品，現(xiàn)在已經(jīng)成為云行業(yè)的主要參與者。在AWS穩(wěn)定版的產(chǎn)品中，Amazon S3或許是最受歡迎的，像Netflix、Reddit和Pinterest這些企業(yè)都在用它的基礎設施。

我們在研究Amazon S3存儲桶時看到的一貫趨勢是，許多組織將它們放置在全域可寫中，這是一種錯誤配置，允許未經(jīng)授權的用戶寫入存儲桶。比較知名的例子比如《洛杉磯時報》，該雜志之前有一個網(wǎng)絡控制列表（ACL），該列表配置允許公眾將訪問路徑寫入存儲桶中，該存儲桶托管在其一個兇殺報告的網(wǎng)站上。攻擊者可以在JavaScript代碼中注入加密挖礦程序。

遙測數(shù)據(jù)還表明，對一些全域可寫的存儲桶網(wǎng)站攻擊大部分發(fā)生在2019年間，同時還涉及一些惡意代碼注入攻擊，最終以網(wǎng)站表單形式提取數(shù)據(jù)。我們遇到的另一個問題是存儲在Amazon S3存儲桶中的惡意文件歸類。大部分惡意文件使用舊的路徑尋址方案。這意味著存儲桶使用通用的Amazon S3主機名，而不是虛擬存儲方案，在虛擬托管方案中，存儲桶的名稱包含在主機名中。這會給安全篩選器帶來問題，因為阻止使用路徑方案的惡意網(wǎng)站的主機名也同樣會阻止其他非惡意站點。

云上可用的第二項主要服務是計算，目前這些服務主要集中于容器技術。在過去幾年中，像一般的云細分市場一樣，容器的采用率也很高。Docker、Kubernetes和AWS Lambda之類的軟件推動了容器技術的發(fā)展，為希望簡化其開發(fā)操作的企業(yè)提供了輕便高效的云部署。但是，配置失誤或錯誤很常見，這些錯誤配置的系統(tǒng)有受到攻擊的風險。

1. Docker

交付加密貨幣挖礦不斷增加，一直困擾著Docker用戶，這也是因為暴露在網(wǎng)絡上的Docker容器所致。挖礦會嚴重影響用戶的計算機，并且因自動擴展的云部署的CPU利用率過高而造成金錢損失。

攻擊者有多種技術將挖礦代碼注入未加密的Docker服務器。最簡單的方法是直接在包含代碼的映像中安裝加密挖礦程序。另一種方法就是在啟動過程中使用類似Ubuntu的常用基礎映像來安裝挖礦軟件。

2. AWS Lambda

AWS Lambdas是無服務器事件驅(qū)動平臺，可為應用程序提供輕量級且經(jīng)濟高效的解決方案，無需設置使用模式。一個常見的誤解是Lambda受白帽保護，不能直接檢索函數(shù)名。這種誤解通常會導致未經(jīng)適當身份驗證的情況下執(zhí)行功能。

但是，攻擊者可以使用多種方法找到Lambda，例如，使用嗅探器偵聽網(wǎng)絡流量，或者通過檢查Lambda使用并運行API網(wǎng)關站點的源代碼。如果沒有安全的Lambda身份驗證，敏感信息有暴露的危險。

另外，由于開發(fā)人員的編碼方式不同，在給定不正確的參數(shù)時，許多基于Python的Lambda函數(shù)會打印堆棧跟蹤，這可能導致攻擊者了解Lambda配置的基礎信息。

3. Kubernetes

Kubernetes是一個用于管理容器工作負載的開源容器編排平臺。我們使用Shodan發(fā)現(xiàn)2019年1月有32000臺Kubernetes服務器暴露在網(wǎng)絡上。與其他配置錯誤的例子一樣，惡意分子可以利用網(wǎng)絡公開訪問Kubernetes服務或其任何組件。

（1） Kubeletes

Kubernetes使用其Kubeletes子組件的API來管理每個節(jié)點中的容器。在舊版本1.10之前的Kubernetes中，Kubelet公開了數(shù)據(jù)端口10255和控制端口10250，這兩個端口均可被利用。濫用控制端口更為明顯，比如可用于安裝加密貨幣挖礦軟件，且端口10255可能包含潛在的敏感信息。

（2） etcd

Etcd是一個分布式和復制的鍵值存儲，充當Kubernetes的主要數(shù)據(jù)存儲。它負責存儲Kubernetes安裝配置，并提供服務發(fā)現(xiàn)的存儲后端。除了Kubernetes，其他應用程序（例如CoreDNS和Rook）都使用etcd。如果將其用作數(shù)據(jù)存儲，則公開暴露的etcd可能會泄漏敏感數(shù)據(jù)，包括用于服務器和應用程序的憑據(jù)。我們使用Shodan發(fā)現(xiàn)了2400多個暴露的etcd服務器，包含Kubernetes和其他軟件的混合。

憑證管理不當

盡管憑據(jù)使用經(jīng)常被忽略，但卻是云計算最重要的方面之一。由于企業(yè)無法像數(shù)據(jù)中心一樣在物理上保護云系統(tǒng)，因此對憑證安全性的需求就變得更大。在保護憑據(jù)方面面臨的一個挑戰(zhàn)是許多流程通常需要訪問身份驗證數(shù)據(jù)和其他資源，這意味著用戶需要保護數(shù)據(jù)和憑據(jù)免受泄露。

程序員經(jīng)常犯的一個錯誤是，他們會無意間在GitHub等公共存儲庫上泄露憑證信息。有時會在網(wǎng)上發(fā)布的代碼段中找到諸如API密鑰之類的敏感數(shù)據(jù)，然后攻擊者就可以使用這些代碼片段來接管憑據(jù)使用的帳戶，隨后再進行犯罪活動，例如盜竊客戶數(shù)據(jù)，在暗網(wǎng)出售這些數(shù)據(jù)。

我們發(fā)現(xiàn)的另一個問題是，許多經(jīng)驗不足的程序員經(jīng)常遵循錯誤的云教程，其中許多教程鼓勵在代碼本身內(nèi)部對憑證進行硬編碼。如果代碼發(fā)布到任何人都可以訪問的存儲庫中，這將成為一個問題。

隨著云服務采用率的增長，企業(yè)需要充分了解其面臨的威脅，并做好適當?shù)臏蕚洌Ｗo其云系統(tǒng)。如果沒有可靠的安全實施措施，云技術的好處就無法實現(xiàn)。本文研究分析的威脅并未涵蓋云中所有潛在的威脅和風險，包括一些最重要的威脅。對于需要了解云的結構以及保護云的策略的IT和安全人員而言，這尤其重要。