|
新聞中心
當前位置：網(wǎng)站首頁 > 新聞中心
云安全：內部共享責任模型
如今，很多組織遭遇網(wǎng)絡攻擊，這表明云計算安全是一個復雜的技術和合同問題。
在最近發(fā)生的主要云安全事件中，Capital One公司的數(shù)據(jù)泄露事件影響了美國的1億人和加拿大的600萬人。其實并不只有Capital One公司遭遇網(wǎng)絡攻擊，黑客Paige A. Thompson與此同時竊取了其他三十多家公司、教育機構和其他實體的數(shù)TB的數(shù)據(jù)。
正如這位被指控的網(wǎng)絡攻擊者在談到AWS配置時所說，“很多組織在其安全方面都做錯了?！?
那么，只有這一家公司在安全方面嚴重失誤?并不是，這個事件與眾不同。首先需要了解一些事情。調查表明，Capital One公司的業(yè)務在很大程度上依賴亞馬遜網(wǎng)絡服務(AWS)的云計算服務。并且網(wǎng)絡攻擊是在Amazon簡單存儲服務(S3存儲桶)中保存的數(shù)據(jù)上進行的。但是，由于防火墻配置錯誤，這次攻擊并不是在沒有任何安全措施的情況下對S3存儲桶進行的攻擊。
簡而言之，這些違規(guī)行為不是因為企業(yè)犯下了愚蠢的安全錯誤，而是因為在維護自身安全方面做得很差。Capital One公司的ModSecurity Web應用程序防火墻(WAF)配置錯誤使得網(wǎng)絡攻擊者(前AWS員工)能夠欺騙防火墻，并將請求轉發(fā)給關鍵的AWS后端資源。攻擊者使用服務器端請求偽造(SSRF)攻擊來欺騙防火墻讓攻擊者進入。
人們今后將會看到更多此類攻擊。正如Cloudflare公司產(chǎn)品安全團隊經(jīng)理Evan Johnson所說的那樣，“這個問題很常見，并且眾所周知，但很難預防，而且AWS平臺沒有任何應對或緩解措施。”
因此，顯然很多人可以將一些責任歸咎于AWS公司的公共云服務。但是，正如所謂的攻擊者自己對AWS的配置所說的那樣，很多公司在這方面做錯了。正如Gartner公司在調查報告中預測，“其實95%的云安全故障都是客戶的錯?！?
然而有些人(例如參議員Ron Wyden)卻將此次數(shù)據(jù)泄露的大部分責任推給AWS公司，AWS公司確實需要為此進行解釋，但真正的問題是如果企業(yè)的安全措施不佳，就會在遭遇攻擊時損失慘重。并且采用的云服務規(guī)模越大，損失越大。
正如安全專家Brian Krebs指出的那樣，這一漏洞并不是由先前未知的‘零日’缺陷或內部攻擊造成的，而是由使用眾所周知的錯誤進行攻擊造成的。
但是，在這一系列安全災難事件中，誰真正犯了安全錯誤呢?是云計算提供商還是使用云服務的公司?答案是他們都有責任。
云安全的共享責任模型?? 客戶和云計算提供商各自負責云堆棧的不同部分。這個概念稱為共享責任模型(SRM)?？焖偎伎即四Ｐ偷姆椒ㄊ窃朴嬎闾峁┥特撠熢破脚_的安全性，采用云平臺的用戶則需要負責在云中的業(yè)務安全性。
AWS和Microsoft Azure公司都明確支持此模型。但是，所有公共云都在某種程度上使用它，它是企業(yè)目前處理云安全的技術和合同方式的基礎。
在最基本的層面上，它意味著企業(yè)負責管理程序級別以上的所有內容。其中包括客戶操作系統(tǒng)、應用程序軟件、云計算實例的防火墻以及傳輸和空閑時的加密數(shù)據(jù)。云計算提供商負責主機操作系統(tǒng)、虛擬化層及其設施的物理安全性。 ? 當然在現(xiàn)實世界中，它從未如此簡單，人們需要了解一些最新的安全事件。
AWS公司表示，“安全與合規(guī)是AWS與用戶之間的共同責任。這種共享模式可以幫助減輕用戶的運營負擔，因為AWS公司可以運行、管理和控制從主機操作系統(tǒng)和虛擬化層到組件的物理安全性的組件，以及服務運營的設施?？蛻舫袚僮飨到y(tǒng)的責任和管理(包括更新和安全補丁)，其他相關的應用軟件以及AWS提供的安全組防火墻的配置。” ? 對于Capital One公司來說，他們沒有正確設置防火墻。但是，獲得AWS身份和訪問管理(IAM)角色臨時憑據(jù)變得更容易。有了這些臨時憑證，進行服務端請求偽造(SSRF)攻擊相對容易。
Johnson聲稱有幾種方法可以減少臨時憑證的使用。Netflix公司還表明，企業(yè)可以在AWS云平臺中發(fā)現(xiàn)臨時安全憑證的使用。所以AWS公司可以更好地鎖定防火墻，但是，Capital One公司首先設置防火墻。簡而言之，這一切都變得相當混亂。
這并不奇怪。正如行業(yè)專家指出的那樣，將云安全要求視為一種范圍。云計算服務客戶將適用于其組織的所有監(jiān)管法規(guī)、行業(yè)和業(yè)務要求(GDPR、PCI DSS、合同等)，其總和等于該組織的所有特定安全要求。這些安全要求將有助于確保數(shù)據(jù)的機密性、完整性、可用性。
安全要求范圍的一端是云計算服務提供商，另一端是采用云計算服務的用戶。提供商負責其中一些安全要求，用戶對其余部分負責，但都應該滿足一些安全要求。云計算服務提供商和采用云服務的用戶都有義務保護數(shù)據(jù)。
但是，在誰負責什么之間劃清界限也不容易。沒有一種適合所有云平臺安全性的解決方案。例如，如果使用軟件即服務(SaaS)辦公套件，例如谷歌的GSuite，顯然是由谷歌負責而不是由用戶負責。如果在平臺即服務(PaaS)上運行自己的應用程序，那么可以同時承擔該程序運行的信譽和責任。 ? 如果仔細觀察，人們會發(fā)現(xiàn)AWS公司提供三種不同的共享責任模型(SRM)。這些是基礎設施服務、容器服務、抽象服務。Azure和其他公共云服務商也具有類似的安全策略設置。
基礎設施包括計算服務(如EC2)和支持服務，例如彈性塊存儲(EBS)、自動擴展和虛擬專用網(wǎng)絡(VPC)。使用此模型，用戶可以像在本地部署或自己的數(shù)據(jù)中心一樣在AWS云平臺中安裝和配置操作系統(tǒng)和平臺。除此之外，還可以安裝應用程序。最終，用戶可以將數(shù)據(jù)駐留在自己的應用程序中，并由自己進行應用程序管理。
容器服務與Docker和類似技術幾乎沒有關系，這些技術在用戶考慮容器時會浮現(xiàn)在腦海中。相反，這些服務通常在單獨的Amazon EC2或其他基礎設施實例上運行，但有時用戶不用管理操作系統(tǒng)或平臺層。
AWS提供托管服務，但用戶負責設置和管理網(wǎng)絡控制(例如防火墻規(guī)則)，以及與身份和訪問管理(IAM)分開管理平臺級別身份和訪問管理。容器服務的示例包括Amazon 關系數(shù)據(jù)庫服務(Amazon RDS)、Amazon 彈性映射還原(Amazon EMR)和AWS Elastic Beanstalk。
在這里，AWS公司管理底層基礎設施和基礎服務、操作系統(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。這些抽象了用戶可以構建和運行云應用程序的平臺或管理層?？梢允褂盟麄兊腁WS API執(zhí)行此操作。AWS公司來管理底層服務組件或操作系統(tǒng)。
在這里，用戶的安全工作是使用身份和訪問管理(IAM)工具管理數(shù)據(jù)，以便對平臺級別的各個資源應用訪問控制列表(ACL)樣式權限，或者在身份和訪問管理(IAM)用戶/組級別應用用戶身份或用戶責任權限。
以下了解一個簡單的例子。亞馬遜公司將Amazon Elastic Compute Cloud(Amazon EC2)歸類為基礎設施即服務(IaaS)云平臺。有了它，用戶負責管理客戶操作系統(tǒng)(包括更新和安全補丁)，在實例上安裝的任何應用程序軟件或實用程序，以及AWS每個實例提供的防火墻(也稱為安全組)的配置。但是，需要使用Amazon S3運行基礎設施層、操作系統(tǒng)和平臺，客戶訪問端點以存儲和檢索數(shù)據(jù)。用戶負責管理其數(shù)據(jù)(包括加密選項)，對其資產(chǎn)進行分類以及使用身份和訪問管理(IAM)應用適當權限的工具。
了解其重點了嗎?這兩者都是基礎設施即服務(IaaS)，但它們有不同的規(guī)則。
這個故事的寓意是，用戶必須仔細研究每一個云計算存儲資源管理服務(SRM)服務協(xié)議。不過，盡管必須準確地了解其使用的每項服務的內容以及誰負責每項服務，但基本概念并不太復雜。云計算提供商負責云平臺的安全，而用戶負責其云平臺業(yè)務的安全。
未來的云計算復雜度更高?? 云原生計算已經(jīng)混淆了共享責任模型(SRM)中的內容。例如，AWS公司現(xiàn)在提供AWS Lambda。這是一種無服務器云計算方法，可讓用戶在不配置或管理服務器的情況下運行代碼。因此，如果沒有服務器，那么誰為服務器負責? ? 亞馬遜公司表示，采用Lambda，AWS公司管理底層基礎設施和基礎服務、操作系統(tǒng)和應用程序平臺。用戶負責代碼的安全性、敏感數(shù)據(jù)的存儲和可訪問性以及身份和訪問管理(IAM)。
這就留下了問題。例如，既然用戶正在使用Lambda來運行代碼，那么代碼的責任在哪里結束，Lambda的責任從哪里開始? ? 正如Gadi Naor公司首席技術官和全棧云原生安全平臺提供商Alcide公司聯(lián)合創(chuàng)始人司所說，“使用無服務器架構意味著組織有新的盲點，只是因為他們不再能夠訪問架構的操作系統(tǒng)，防止他們在這些工作負載中添加防火墻，基于主機的入侵防護或工作負載保護工具?！?
這只是個開始。例如，Kuberrnetes正在使混合云同時在多個云平臺上運行。那么，如果用戶正在運行一個跨越新的基于Red Hat的IBM云平臺和AWS的程序，那么誰負責保護整個項目?當出現(xiàn)問題時誰負責?而且，最后但并非最不重要的是，當最終用戶起訴時誰來支付費用? ? 這是一個很好的問題。對于人們正在進入的這個新的復雜云世界，仍然沒有很好的答案。
那么，用戶可以做些什么?首先，確保了解自己的云安全需求。用戶不能選擇云計算服務提供商并制定云安全協(xié)議，直到知道什么對自己有用。這些不僅僅是技術問題。它們也是需要關注的法律問題。
有了這些信息，用戶就可以與云計算提供商制定安全協(xié)議。這應該在其服務級別協(xié)議中明確規(guī)定。
最后，無論合同中有什么內容，用戶和其安全人員都必須確保基于云計算的數(shù)據(jù)和服務盡可能安全。畢竟，這是自己的數(shù)據(jù)和工作，如果出了問題，將需要承擔不可推托的責任。
來源：企業(yè)網(wǎng)D1Net
|
