雲安全：內部共享責任模型

• 2019 年 10 月 5 日
• 筆記

在最近發生的主要雲安全事件中，Capital One公司的數據泄露事件影響了美國的1億人和加拿大的600萬人。其實並不只有Capital One公司遭遇網路攻擊，黑客Paige A. Thompson與此同時竊取了其他三十多家公司、教育機構和其他實體的數TB的數據。

如今，很多組織遭遇網路攻擊，這表明雲計算安全是一個複雜的技術和合約問題。

在最近發生的主要雲安全事件中，Capital One公司的數據泄露事件影響了美國的1億人和加拿大的600萬人。其實並不只有Capital One公司遭遇網路攻擊，黑客Paige A. Thompson與此同時竊取了其他三十多家公司、教育機構和其他實體的數TB的數據。

正如這位被指控的網路攻擊者在談到AWS配置時所說，「很多組織在其安全方面都做錯了。」

那麼，只有這一家公司在安全方面嚴重失誤?並不是，這個事件與眾不同。首先需要了解一些事情。調查表明，Capital One公司的業務在很大程度上依賴亞馬遜網路服務(AWS)的雲計算服務。並且網路攻擊是在Amazon簡單存儲服務(S3存儲桶)中保存的數據上進行的。但是，由於防火牆配置錯誤，這次攻擊並不是在沒有任何安全措施的情況下對S3存儲桶進行的攻擊。

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

Capital One公司的ModSecurity Web應用程式防火牆(WAF)配置錯誤使得網路攻擊者(前AWS員工)能夠欺騙防火牆，並將請求轉發給關鍵的AWS後端資源。攻擊者使用伺服器端請求偽造(SSRF)攻擊來欺騙防火牆讓攻擊者進入。

人們今後將會看到更多此類攻擊。正如Cloudflare公司產品安全團隊經理Evan Johnson所說的那樣，「這個問題很常見，並且眾所周知，但很難預防，而且AWS平台沒有任何應對或緩解措施。」

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

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

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

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

雲安全的共享責任模型

客戶和雲計算提供商各自負責雲堆棧的不同部分。這個概念稱為共享責任模型(SRM)。快速思考此模型的方法是雲計算提供商負責雲平台的安全性，採用雲平台的用戶則需要負責在雲中的業務安全性。

AWS和Microsoft Azure公司都明確支援此模型。但是，所有公共雲都在某種程度上使用它，它是企業目前處理雲安全的技術和合約方式的基礎。

在最基本的層面上，它意味著企業負責管理程式級別以上的所有內容。其中包括客戶作業系統、應用程式軟體、雲計算實例的防火牆以及傳輸和空閑時的加密數據。雲計算提供商負責主機作業系統、虛擬化層及其設施的物理安全性。

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

AWS公司表示，「安全與合規是AWS與用戶之間的共同責任。這種共享模式可以幫助減輕用戶的運營負擔，因為AWS公司可以運行、管理和控制從主機作業系統和虛擬化層到組件的物理安全性的組件，以及服務運營的設施。客戶承擔作業系統的責任和管理(包括更新和安全修補程式)，其他相關的應用軟體以及AWS提供的安全組防火牆的配置。」

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

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

這並不奇怪。正如行業專家指出的那樣，將雲安全要求視為一種範圍。雲計算服務客戶將適用於其組織的所有監管法規、行業和業務要求(GDPR、PCI DSS、合約等)，其總和等於該組織的所有特定安全要求。這些安全要求將有助於確保數據的機密性、完整性、可用性。

安全要求範圍的一端是雲計算服務提供商，另一端是採用雲計算服務的用戶。提供商負責其中一些安全要求，用戶對其餘部分負責，但都應該滿足一些安全要求。雲計算服務提供商和採用雲服務的用戶都有義務保護數據。

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

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

基礎設施包括計算服務(如EC2)和支援服務，例如彈性塊存儲(EBS)、自動擴展和虛擬專用網路(VPC)。使用此模型，用戶可以像在本地部署或自己的數據中心一樣在AWS雲平台中安裝和配置作業系統和平台。除此之外，還可以安裝應用程式。最終，用戶可以將數據駐留在自己的應用程式中，並由自己進行應用程式管理。

容器服務與Docker和類似技術幾乎沒有關係，這些技術在用戶考慮容器時會浮現在腦海中。相反，這些服務通常在單獨的Amazon EC2或其他基礎設施實例上運行，但有時用戶不用管理作業系統或平台層。

AWS提供託管服務，但用戶負責設置和管理網路控制(例如防火牆規則)，以及與身份和訪問管理(IAM)分開管理平台級別身份和訪問管理。容器服務的示例包括Amazon 關係資料庫服務(Amazon RDS)、Amazon 彈性映射還原(Amazon EMR)和AWS Elastic Beanstalk。

在這裡，AWS公司管理底層基礎設施和基礎服務、作業系統和應用程式平台。例如，使用Amazon RDS AWS管理容器的所有層，包括Oracle資料庫平台。但是，AWS平台提供數據備份和恢復工具;用戶的工作是維護其業務連續性和災難恢復政策。還負責數據和防火牆規則。因此，雖然Amazon RDS提供防火牆軟體，但其工作是管理防火牆。

抽象服務是高級存儲、資料庫和消息傳遞服務。它們包括Amazon 簡單存儲服務(Amazon S3)、Amazon DynamoDB、Amazon Simple Email Service。這些抽象了用戶可以構建和運行雲應用程式的平台或管理層。可以使用他們的AWS API執行此操作。AWS公司來管理底層服務組件或作業系統。

在這裡，用戶的安全工作是使用身份和訪問管理(IAM)工具管理數據，以便對平台級別的各個資源應用訪問控制列表(ACL)樣式許可權，或者在身份和訪問管理(IAM)用戶/組級別應用用戶身份或用戶責任許可權。

以下了解一個簡單的例子。亞馬遜公司將Amazon Elastic Compute Cloud(Amazon EC2)歸類為基礎設施即服務(IaaS)雲平台。有了它，用戶負責管理客戶作業系統(包括更新和安全修補程式)，在實例上安裝的任何應用程式軟體或實用程式，以及AWS每個實例提供的防火牆(也稱為安全組)的配置。但是，需要使用Amazon S3運行基礎設施層、作業系統和平台，客戶訪問端點以存儲和檢索數據。用戶負責管理其數據(包括加密選項)，對其資產進行分類以及使用身份和訪問管理(IAM)應用適當許可權的工具。

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

這個故事的寓意是，用戶必須仔細研究每一個雲計算存儲資源管理服務(SRM)服務協議。不過，儘管必須準確地了解其使用的每項服務的內容以及誰負責每項服務，但基本概念並不太複雜。雲計算提供商負責雲平台的安全，而用戶負責其雲平台業務的安全。

未來的雲計算複雜度更高

雲原生計算已經混淆了共享責任模型(SRM)中的內容。例如，AWS公司現在提供AWS Lambda。這是一種無伺服器雲計算方法，可讓用戶在不配置或管理伺服器的情況下運行程式碼。因此，如果沒有伺服器，那麼誰為伺服器負責?

亞馬遜公司表示，採用Lambda，AWS公司管理底層基礎設施和基礎服務、作業系統和應用程式平台。用戶負責程式碼的安全性、敏感數據的存儲和可訪問性以及身份和訪問管理(IAM)。

這就留下了問題。例如，既然用戶正在使用Lambda來運行程式碼，那麼程式碼的責任在哪裡結束，Lambda的責任從哪裡開始?

正如Gadi Naor公司首席技術官和全棧雲原生安全平台提供商Alcide公司聯合創始人司所說，「使用無伺服器架構意味著組織有新的盲點，只是因為他們不再能夠訪問架構的作業系統，防止他們在這些工作負載中添加防火牆，基於主機的入侵防護或工作負載保護工具。」

這只是個開始。例如，Kuberrnetes正在使混合雲同時在多個雲平台上運行。那麼，如果用戶正在運行一個跨越新的基於Red Hat的IBM雲平台和AWS的程式，那麼誰負責保護整個項目?當出現問題時誰負責?而且，最後但並非最不重要的是，當最終用戶起訴時誰來支付費用?

這是一個很好的問題。對於人們正在進入的這個新的複雜雲世界，仍然沒有很好的答案。

那麼，用戶可以做些什麼?首先，確保了解自己的雲安全需求。用戶不能選擇雲計算服務提供商並制定雲安全協議，直到知道什麼對自己有用。這些不僅僅是技術問題。它們也是需要關注的法律問題。

有了這些資訊，用戶就可以與雲計算提供商制定安全協議。這應該在其服務級別協議中明確規定。

最後，無論合約中有什麼內容，用戶和其安全人員都必須確保基於雲計算的數據和服務儘可能安全。畢竟，這是自己的數據和工作，如果出了問題，將需要承擔不可推託的責任。

(來源：企業網D1Net)

如果您在企業IT、網路、通訊行業的某一領域工作，並希望分享觀點，歡迎給企業網D1Net投稿