Steven J.

在最近發(fā)生的主要云安全事件中，Capital One公司的數(shù)據(jù)泄露事件影響了美國的1億人和加拿大的600萬人。其實并不只有Capital One公司遭遇網(wǎng)絡攻擊，黑客Paige A. Thompson與此同時竊取了其他三十多家公司、教育機構(gòu)和其他實體的數(shù)TB的數(shù)據(jù)。正如這位被指控的網(wǎng)絡攻擊者在談到AWS配置時所說，“很多組織在其安全方面都做錯了”。

調(diào)查表明，Capital One公司的業(yè)務在很大程度上依賴亞馬遜網(wǎng)絡服務（AWS）的云計算服務。并且網(wǎng)絡攻擊是在Amazon簡單存儲服務（S3存儲桶）中保存的數(shù)據(jù)上進行的。但是，由于防火墻配置錯誤，這次攻擊并不是在沒有任何安全措施的情況下對S3存儲桶進行的攻擊。簡而言之，這些違規(guī)行為不是因為企業(yè)犯下了安全錯誤，而是因為在維護自身安全方面做得很差。

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

正如Cloudflare公司產(chǎn)品安全團隊經(jīng)理Evan Johnson所說的那樣，“這個問題很常見，并且眾所周知，但很難預防，而且AWS平臺沒有任何應對或緩解措施”。因此，顯然很多人可以將一些責任歸咎于AWS公司的公共云服務。但是，正如所謂的攻擊者自己對AWS的配置所說的那樣，很多公司在這方面做錯了。正如Gartner公司在調(diào)查報告中預測，“其實95%的云安全故障都是客戶的錯”。

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

云安全的共享責任模型

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

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

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

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

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

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

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

但是，在誰負責什么之間劃清界限也不容易。沒有一種適合所有云平臺安全性的解決方案。如果在平臺即服務（PaaS）上運行自己的應用程序，那么可以同時承擔該程序運行的信譽和責任。如果仔細觀察，人們會發(fā)現(xiàn)AWS公司提供三種不同的共享責任模型（SRM）。這些是基礎(chǔ)設施服務、容器服務、抽象服務。Azure和其他公共云服務商也具有類似的安全策略設置。

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

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

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

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

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

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

未來的云計算復雜度更高

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

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

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

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

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

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

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

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