在最近發(fā)生的主要云安全事件中，Capital One公司的數(shù)據(jù)泄露事件影響了美國的1億人和加拿大的600萬人。其實并不只有Capital One公司遭遇網(wǎng)絡(luò)攻擊，黑客Paige A. Thompson與此同時竊取了其他三十多家公司、教育機構(gòu)和其他實體的數(shù)TB的數(shù)據(jù)。

 

正如這位被指控的網(wǎng)絡(luò)攻擊者在談到AWS配置時所說，“很多組織在其安全方面都做錯了。”

 

那么，只有這一家公司在安全方面嚴重失誤?并不是，這個事件與眾不同。首先需要了解一些事情。調(diào)查表明，Capital One公司的業(yè)務(wù)在很大程度上依賴亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)的云計算服務(wù)。并且網(wǎng)絡(luò)攻擊是在Amazon簡單存儲服務(wù)(S3存儲桶)中保存的數(shù)據(jù)上進行的。但是，由于防火墻配置錯誤，這次攻擊并不是在沒有任何安全措施的情況下對S3存儲桶進行的攻擊。

 

簡而言之，這些違規(guī)行為不是因為企業(yè)犯下了愚蠢的安全錯誤，而是因為在維護自身安全方面做得很差。

 

Capital One公司的ModSecurity Web應(yīng)用程序防火墻(WAF)配置錯誤使得網(wǎng)絡(luò)攻擊者(前AWS員工)能夠欺騙防火墻，并將請求轉(zhuǎn)發(fā)給關(guān)鍵的AWS后端資源。攻擊者使用服務(wù)器端請求偽造(SSRF)攻擊來欺騙防火墻讓攻擊者進入。

 

人們今后將會看到更多此類攻擊。正如Cloudflare公司產(chǎn)品安全團隊經(jīng)理Evan Johnson所說的那樣，“這個問題很常見，并且眾所周知，但很難預(yù)防，而且AWS平臺沒有任何應(yīng)對或緩解措施。”

 

因此，顯然很多人可以將一些責任歸咎于AWS公司的公共云服務(wù)。但是，正如所謂的攻擊者自己對AWS的配置所說的那樣，很多公司在這方面做錯了。正如Gartner公司在調(diào)查報告中預(yù)測，“其實95%的云安全故障都是客戶的錯。”

 

然而有些人(例如參議員Ron Wyden)卻將此次數(shù)據(jù)泄露的大部分責任推給AWS公司，AWS公司確實需要為此進行解釋，但真正的問題是如果企業(yè)的安全措施不佳，就會在遭遇攻擊時損失慘重。并且采用的云服務(wù)規(guī)模越大，損失越大。

 

正如安全專家Brian Krebs指出的那樣，這一漏洞并不是由先前未知的‘零日’缺陷或內(nèi)部攻擊造成的，而是由使用眾所周知的錯誤進行攻擊造成的。

 

但是，在這一系列安全災(zāi)難事件中，誰真正犯了安全錯誤呢?是云計算提供商還是使用云服務(wù)的公司?答案是他們都有責任。

 

 

客戶和云計算提供商各自負責云堆棧的不同部分。這個概念稱為共享責任模型(SRM)?？焖偎伎即四Ｐ偷姆椒ㄊ窃朴嬎闾峁┥特撠熢破脚_的安全性，采用云平臺的用戶則需要負責在云中的業(yè)務(wù)安全性。

 

AWS和Microsoft Azure公司都明確支持此模型。但是，所有公共云都在某種程度上使用它，它是企業(yè)目前處理云安全的技術(shù)和合同方式的基礎(chǔ)。

 

在最基本的層面上，它意味著企業(yè)負責管理程序級別以上的所有內(nèi)容。其中包括客戶操作系統(tǒng)、應(yīng)用程序軟件、云計算實例的防火墻以及傳輸和空閑時的加密數(shù)據(jù)。云計算提供商負責主機操作系統(tǒng)、虛擬化層及其設(shè)施的物理安全性。

 

當然在現(xiàn)實世界中，它從未如此簡單，人們需要了解一些最新的安全事件。

 

AWS公司表示，“安全與合規(guī)是AWS與用戶之間的共同責任。這種共享模式可以幫助減輕用戶的運營負擔，因為AWS公司可以運行、管理和控制從主機操作系統(tǒng)和虛擬化層到組件的物理安全性的組件，以及服務(wù)運營的設(shè)施?？蛻舫袚僮飨到y(tǒng)的責任和管理(包括更新和安全補丁)，其他相關(guān)的應(yīng)用軟件以及AWS提供的安全組防火墻的配置。”

 

對于Capital One公司來說，他們沒有正確設(shè)置防火墻。但是，獲得AWS身份和訪問管理(IAM)角色臨時憑據(jù)變得更容易。有了這些臨時憑證，進行服務(wù)端請求偽造(SSRF)攻擊相對容易。

 

Johnson聲稱有幾種方法可以減少臨時憑證的使用。Netflix公司還表明，企業(yè)可以在AWS云平臺中發(fā)現(xiàn)臨時安全憑證的使用。所以AWS公司可以更好地鎖定防火墻，但是，Capital One公司首先設(shè)置防火墻。簡而言之，這一切都變得相當混亂。

 

這并不奇怪。正如行業(yè)專家指出的那樣，將云安全要求視為一種范圍。云計算服務(wù)客戶將適用于其組織的所有監(jiān)管法規(guī)、行業(yè)和業(yè)務(wù)要求(GDPR、PCI DSS、合同等)，其總和等于該組織的所有特定安全要求。這些安全要求將有助于確保數(shù)據(jù)的機密性、完整性、可用性。

 

安全要求范圍的一端是云計算服務(wù)提供商，另一端是采用云計算服務(wù)的用戶。提供商負責其中一些安全要求，用戶對其余部分負責，但都應(yīng)該滿足一些安全要求。云計算服務(wù)提供商和采用云服務(wù)的用戶都有義務(wù)保護數(shù)據(jù)。

 

但是，在誰負責什么之間劃清界限也不容易。沒有一種適合所有云平臺安全性的解決方案。例如，如果使用軟件即服務(wù)(SaaS)辦公套件，例如谷歌的GSuite，顯然是由谷歌負責而不是由用戶負責。如果在平臺即服務(wù)(PaaS)上運行自己的應(yīng)用程序，那么可以同時承擔該程序運行的信譽和責任。

 

如果仔細觀察，人們會發(fā)現(xiàn)AWS公司提供三種不同的共享責任模型(SRM)。這些是基礎(chǔ)設(shè)施服務(wù)、容器服務(wù)、抽象服務(wù)。Azure和其他公共云服務(wù)商也具有類似的安全策略設(shè)置。

 

基礎(chǔ)設(shè)施包括計算服務(wù)(如EC2)和支持服務(wù)，例如彈性塊存儲(EBS)、自動擴展和虛擬專用網(wǎng)絡(luò)(VPC)。使用此模型，用戶可以像在本地部署或自己的數(shù)據(jù)中心一樣在AWS云平臺中安裝和配置操作系統(tǒng)和平臺。除此之外，還可以安裝應(yīng)用程序。最終，用戶可以將數(shù)據(jù)駐留在自己的應(yīng)用程序中，并由自己進行應(yīng)用程序管理。

 

容器服務(wù)與Docker和類似技術(shù)幾乎沒有關(guān)系，這些技術(shù)在用戶考慮容器時會浮現(xiàn)在腦海中。相反，這些服務(wù)通常在單獨的Amazon EC2或其他基礎(chǔ)設(shè)施實例上運行，但有時用戶不用管理操作系統(tǒng)或平臺層。

 

AWS提供托管服務(wù)，但用戶負責設(shè)置和管理網(wǎng)絡(luò)控制(例如防火墻規(guī)則)，以及與身份和訪問管理(IAM)分開管理平臺級別身份和訪問管理。容器服務(wù)的示例包括Amazon 關(guān)系數(shù)據(jù)庫服務(wù)(Amazon RDS)、Amazon 彈性映射還原(Amazon EMR)和AWS Elastic Beanstalk。

 

在這里，AWS公司管理底層基礎(chǔ)設(shè)施和基礎(chǔ)服務(wù)、操作系統(tǒng)和應(yīng)用程序平臺。例如，使用Amazon RDS AWS管理容器的所有層，包括Oracle數(shù)據(jù)庫平臺。但是，AWS平臺提供數(shù)據(jù)備份和恢復(fù)工具;用戶的工作是維護其業(yè)務(wù)連續(xù)性和災(zāi)難恢復(fù)政策。還負責數(shù)據(jù)和防火墻規(guī)則。因此，雖然Amazon RDS提供防火墻軟件，但其工作是管理防火墻。

 

抽象服務(wù)是高級存儲、數(shù)據(jù)庫和消息傳遞服務(wù)。它們包括Amazon 簡單存儲服務(wù)(Amazon S3)、Amazon DynamoDB、Amazon Simple Email Service。這些抽象了用戶可以構(gòu)建和運行云應(yīng)用程序的平臺或管理層。可以使用他們的AWS API執(zhí)行此操作。AWS公司來管理底層服務(wù)組件或操作系統(tǒng)。

 

在這里，用戶的安全工作是使用身份和訪問管理(IAM)工具管理數(shù)據(jù)，以便對平臺級別的各個資源應(yīng)用訪問控制列表(ACL)樣式權(quán)限，或者在身份和訪問管理(IAM)用戶/組級別應(yīng)用用戶身份或用戶責任權(quán)限。

 

以下了解一個簡單的例子。亞馬遜公司將Amazon Elastic Compute Cloud(Amazon EC2)歸類為基礎(chǔ)設(shè)施即服務(wù)(IaaS)云平臺。有了它，用戶負責管理客戶操作系統(tǒng)(包括更新和安全補丁)，在實例上安裝的任何應(yīng)用程序軟件或?qū)嵱贸绦?，以及AWS每個實例提供的防火墻(也稱為安全組)的配置。但是，需要使用Amazon S3運行基礎(chǔ)設(shè)施層、操作系統(tǒng)和平臺，客戶訪問端點以存儲和檢索數(shù)據(jù)。用戶負責管理其數(shù)據(jù)(包括加密選項)，對其資產(chǎn)進行分類以及使用身份和訪問管理(IAM)應(yīng)用適當權(quán)限的工具。

 

了解其重點了嗎?這兩者都是基礎(chǔ)設(shè)施即服務(wù)(IaaS)，但它們有不同的規(guī)則。

 

這個故事的寓意是，用戶必須仔細研究每一個云計算存儲資源管理服務(wù)(SRM)服務(wù)協(xié)議。不過，盡管必須準確地了解其使用的每項服務(wù)的內(nèi)容以及誰負責每項服務(wù)，但基本概念并不太復(fù)雜。云計算提供商負責云平臺的安全，而用戶負責其云平臺業(yè)務(wù)的安全。

 

 

云原生計算已經(jīng)混淆了共享責任模型(SRM)中的內(nèi)容。例如，AWS公司現(xiàn)在提供AWS Lambda。這是一種無服務(wù)器云計算方法，可讓用戶在不配置或管理服務(wù)器的情況下運行代碼。因此，如果沒有服務(wù)器，那么誰為服務(wù)器負責?

 

亞馬遜公司表示，采用Lambda，AWS公司管理底層基礎(chǔ)設(shè)施和基礎(chǔ)服務(wù)、操作系統(tǒng)和應(yīng)用程序平臺。用戶負責代碼的安全性、敏感數(shù)據(jù)的存儲和可訪問性以及身份和訪問管理(IAM)。

 

這就留下了問題。例如，既然用戶正在使用Lambda來運行代碼，那么代碼的責任在哪里結(jié)束，Lambda的責任從哪里開始?

 

正如Gadi Naor公司首席技術(shù)官和全棧云原生安全平臺提供商Alcide公司聯(lián)合創(chuàng)始人司所說，“使用無服務(wù)器架構(gòu)意味著組織有新的盲點，只是因為他們不再能夠訪問架構(gòu)的操作系統(tǒng)，防止他們在這些工作負載中添加防火墻，基于主機的入侵防護或工作負載保護工具。”

 

這只是個開始。例如，Kuberrnetes正在使混合云同時在多個云平臺上運行。那么，如果用戶正在運行一個跨越新的基于Red Hat的IBM云平臺和AWS的程序，那么誰負責保護整個項目?當出現(xiàn)問題時誰負責?而且，最后但并非最不重要的是，當最終用戶起訴時誰來支付費用?

 

這是一個很好的問題。對于人們正在進入的這個新的復(fù)雜云世界，仍然沒有很好的答案。

 

那么，用戶可以做些什么?首先，確保了解自己的云安全需求。用戶不能選擇云計算服務(wù)提供商并制定云安全協(xié)議，直到知道什么對自己有用。這些不僅僅是技術(shù)問題。它們也是需要關(guān)注的法律問題。

 

有了這些信息，用戶就可以與云計算提供商制定安全協(xié)議。這應(yīng)該在其服務(wù)級別協(xié)議中明確規(guī)定。

 

最后，無論合同中有什么內(nèi)容，用戶和其安全人員都必須確保基于云計算的數(shù)據(jù)和服務(wù)盡可能安全。畢竟，這是自己的數(shù)據(jù)和工作，如果出了問題，將需要承擔不可推托的責任。