資料蔓延:雲資料挑戰

NEW

資料蔓延:雲資料挑戰

用於儲存和管理資料的傳統安全方法已經不足以滿足當今雲世界的需求。為什麼?雲與敏捷雲開發勢不可擋的力量正在推動企業構建、部署和執行應用程式的方式發生重大變化。因此,當今的運營需求要求對資料的管理和保護方式進行正規化轉變。

資料蔓延(也稱為資料傳播/分散)是利用雲服務的組織面臨的最大挑戰之一。事實上,根據CSC 的一項研究,只有 33% 的組織能夠在所有云中維護其資料的單一檢視,並且只有 60% 可以安全地在雲提供商之間共享資料。

為了應對雲資料蔓延的挑戰,組織必須實施一種資料控制策略,以幫助從一個地方管理多個應用程式和雲端儲存提供商。在雲環境中,制定資料管理計劃尤為必要,以便在所有云環境中擁有單一的資料檢視,並確保只有經過授權的身份才能檢視和使用特定資訊。

在資料得到控制之前,企業可能會花費大量時間和金錢來減輕負面後果。事實上,他們平均可以在五年內花費 1600 萬美元來管理資料蔓延。為了降低這種風險,IT 領導者應該瞭解四個非常重要的注意事項。

傳統資料中心幾乎消亡

Gartner 假設,到 2025 年,80% 的企業將關閉其傳統資料中心。事實上,10% 的組織已經擁有其雲資料中心。許多組織正在根據網路延遲、客戶群和地緣政治限制重新考慮應用程式的放置——例如,歐盟的通用資料保護條例 (GDPR) 或監管限制。

由於高資本成本,擁有舊資料中心的企業不想重建或建立新的資料中心。他們寧願讓其他人管理物理基礎設施。Gartner 的 IT Key Metrics 資料顯示,過去幾年,用於資料中心的 IT 預算佔 IT 預算的百分比有所下降,現在僅佔總數的 17%。

根據2020 IDG 雲計算研究,92% 的公司已經採用了雲技術。IDG 分析預測,雲技術將繼續積極轉變,並預測在 18 個月內,SaaS 將有 95% 的公司使用,IaaS 為 83%,PaaS 為 73%。還預測雲計算預算正在增加,因為預計未來 12 個月內將有 32% 的 IT 預算分配給雲計算。

如今,基礎設施和運營 (I&O) 領導者面臨著艱鉅的挑戰。他們已經瞭解了幾十年的 IT 正在發生根本性的變化。在本地工作的傳統安全方法不再適用於雲。

雲和雲帳戶將成倍增加

RightScale表示,80% 的雲公司都採用了多雲戰略,使用多個供應商,如亞馬遜、微軟、谷歌、IBM、甲骨文和阿里巴巴。此外,建立雲帳戶的便捷性和優勢確保擁有多個 AWS 或 GCP 雲帳戶或 Azure 訂閱成為常態。企業擁有數百個甚至數千個雲帳戶並不罕見。

我們還不知道每個企業在這麼多不同的雲上執行多少計算能力,但讓我們做一些粗略的數學計算:

大多數企業擁有數百個 AWS 賬戶,許多企業擁有超過 1000 個(甚至 10,000 個)。我看到的數字表明,財富 500 強公司中有 83% 是公共雲的消費者。如果是這樣,那麼這意味著截至今天,全球大約有 130,000 個企業規模的 AWS 雲帳戶,這些帳戶僅在 AWS 中執行就構成了大量例項。

每個公司也有至少一個 Google VM 或 Compute Engine 例項的可能性也很大。我看到的數字表明,財富 500 強中有 49% 也是 Google Cloud Platform (GCP) 的使用者。我認為可以安全地假設,如果企業擁有 AWS 賬戶,那麼他們就有一個 GCP 賬戶。能夠使用多個雲是公司在需要時擴充套件其容量的同時利用一些冗餘的一種方式。

如果我們做一些簡單的數學計算:根據一組估計,來自兩個提供商的 130,000 x 2 = 260,000 個雲帳戶總數可能比這個數字多得多。這些只是帳戶,我們甚至還沒有觸及雲中身份數量的表面層級。

任何閱讀本文的人也可能很好地猜測有多少雲帳戶來自他們自己的公司,因此我們甚至不要嘗試估計單個組織的員工可能有權訪問的身份數量。我們只會說“讓它成為一百萬”。

創新催生了許多新的資料儲

選擇有限的可管理資料儲存(例如 Oracle、IBM 和 MS SQL)的日子已經一去不復返了。敏捷雲開發方面的創新導致新資料儲存選項激增,團隊使用 Amazon MongoDB、Elasticsearch、CouchDB、Cassandra、Dynamo DB、HashiCorp Vault 等等。將這些新增到 AWS S3 和 Azure Blob 等物件儲存中,不言而喻,新的企業基礎設施沒有“資料中心”的物理或邏輯概念。

臨時計算會覆蓋您的資料

對於容器編排,

容器的典型生命週期為12小時

。無伺服器功能——已經被22%的公司採用

——在幾秒鐘內來去匆匆。資料是數字時代的石油,但在這個時代,石油鑽井平臺

轉瞬即逝,數不勝數。

EC2

例項、

Spot

例項、容器、無伺服器功能、管理員和敏捷開發團隊是數不清的鑽探資料轉瞬即逝的裝置。

我們的新世界存在資料控制問題

難怪53% 的使用雲的組織都線上公開了資料?雖然所有這些靈活性和敏捷性都有利於創新和靈活性,但它也帶來了新的挑戰。特別是,我們有一個跟蹤和控制雲資料以及可以訪問它的內容。

我們的 Breach Watch 頁面上列出了一小部分廣為人知的雲資料丟失事件示例,但我們可以確信,隨著雲平臺的快速採用和新開發技術的持續有增無減,資料控制問題將會加劇。

當然,我們不僅僅有安全問題。PCI、HIPAA、歐洲的 GDPR、加利福尼亞的 CCPA、巴西的 LDPD、加拿大的 PIPEDA 等合規性要求要求對資料和這些控制的審計/報告進行廣泛的安全控制。

現有工具無法管理雲資料蔓延

隨著雲和敏捷成為主流,傳統的資料中心和網路管理工具都停留在過去。以從業者為中心的雲提供商工具也無法勝任這項任務。AWS、Azure、GCP 和其他雲提供商中存在明顯不同的身份和資料模型。訪問控制列表、內聯策略、組內聯策略、角色內聯策略、代入角色、切換角色聯合和託管策略都會影響訪問資源的內容。

我們必須瞭解多個雲提供商身份和資料模型,並跟蹤對主要 AWS、GCP 和 Azure 雲平臺中使用的第三方資料儲存的訪問。當公司需要跟蹤跨多個雲、大量雲帳戶和數千個數據儲存的資料訪問和移動時,該公司該何去何從?

技術可以提供幫助

目前已有需要的雲技術為跨雲帳戶、雲提供商和第三方資料儲存的所有身份和資料關係、活動和資料移動提供完整的風險模型。服務重點是所有有權訪問資料的實體的資料+身份——跨雲提供商和第三方資料儲存。最後,雲技術在 DevOps 和安全團隊之間架起了橋樑,以:

1、提高資料安全性並降低風險。使用者配置風險和公共資料暴露風險都是跨雲提供商、賬戶、國家、團隊和應用程式報告的。

2、確保合規。資料主權、資料移動和身份關係都受到監控,以確保符合主權、GDPR、HIPAA和其他合規性要求。

3、提高 DevOps效率。雲提供商管理模型透過數百個AWS和Google Cloud帳戶以及Azure 訂閱/資源組的集中分析和檢視進行標準化。

相關文章