用于存儲和管理數(shù)據(jù)的傳統(tǒng)安全方法已經(jīng)不足以滿足當今云世界的需求,。為什么,？云與敏捷云開發(fā)勢不可擋的力量正在推動企業(yè)構建、部署和運行應用程序的方式發(fā)生重大變化,。因此,，當今的運營需求要求對數(shù)據(jù)的管理和保護方式進行范式轉變。

　　數(shù)據(jù)蔓延（也稱為數(shù)據(jù)傳播/分散）是利用云服務的組織面臨的最大挑戰(zhàn)之一,。事實上,，根據(jù)CSC 的一項研究，只有 33% 的組織能夠在所有云中維護其數(shù)據(jù)的單一視圖,，并且只有 60% 可以安全地在云提供商之間共享數(shù)據(jù),。

　　為了應對云數(shù)據(jù)蔓延的挑戰(zhàn)，組織必須實施一種數(shù)據(jù)控制策略,，以幫助從一個地方管理多個應用程序和云存儲提供商,。在云環(huán)境中，制定數(shù)據(jù)管理計劃尤為必要,，以便在所有云環(huán)境中擁有單一的數(shù)據(jù)視圖,，并確保只有經(jīng)過授權的身份才能查看和使用特定信息。

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

　　傳統(tǒng)數(shù)據(jù)中心幾乎消亡

　　Gartner 假設,，到 2025 年,，80% 的企業(yè)將關閉其傳統(tǒng)數(shù)據(jù)中心。事實上,，10% 的組織已經(jīng)擁有其云數(shù)據(jù)中心,。許多組織正在根據(jù)網(wǎng)絡延遲、客戶群和地緣政治限制重新考慮應用程序的放置——例如,，歐盟的通用數(shù)據(jù)保護條例 （GDPR） 或監(jiān)管限制,。

　　由于高資本成本，擁有舊數(shù)據(jù)中心的企業(yè)不想重建或建立新的數(shù)據(jù)中心,。他們寧愿讓其他人管理物理基礎設施,。Gartner 的 IT Key Metrics 數(shù)據(jù)顯示，過去幾年,，用于數(shù)據(jù)中心的 IT 預算占 IT 預算的百分比有所下降,，現(xiàn)在僅占總數(shù)的 17%。

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

　　如今,，基礎設施和運營 （I&O） 領導者面臨著艱巨的挑戰(zhàn)。他們已經(jīng)了解了幾十年的 IT 正在發(fā)生根本性的變化,。在本地工作的傳統(tǒng)安全方法不再適用于云,。

　　云和云帳戶將成倍增加

　　RightScale表示，80% 的云公司都采用了多云戰(zhàn)略,，使用多個供應商,，如亞馬遜、微軟,、谷歌,、IBM、甲骨文和阿里巴巴,。此外,，創(chuàng)建云帳戶的便捷性和優(yōu)勢確保擁有多個 AWS 或 GCP 云帳戶或 Azure 訂閱成為常態(tài)。企業(yè)擁有數(shù)百個甚至數(shù)千個云帳戶并不罕見,。

　　我們還不知道每個企業(yè)在這么多不同的云上運行多少計算能力,，但讓我們做一些粗略的數(shù)學計算：

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

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

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

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

　　創(chuàng)新催生了許多新的數(shù)據(jù)儲

　　選擇有限的可管理數(shù)據(jù)存儲（例如 Oracle、IBM 和 MS SQL）的日子已經(jīng)一去不復返了,。敏捷云開發(fā)方面的創(chuàng)新導致新數(shù)據(jù)存儲選項激增,，團隊使用 Amazon MongoDB、Elasticsearch,、CouchDB,、Cassandra、Dynamo DB,、HashiCorp Vault 等等,。將這些添加到 AWS S3 和 Azure Blob 等對象存儲中，不言而喻,，新的企業(yè)基礎設施沒有“數(shù)據(jù)中心”的物理或邏輯概念,。

　　臨時計算會覆蓋您的數(shù)據(jù)

　　對于容器編排，容器的典型生命周期為12小時,。無服務器功能——已經(jīng)被22%的公司采用——在幾秒鐘內來去匆匆,。數(shù)據(jù)是數(shù)字時代的石油，但在這個時代,，石油鉆井平臺轉瞬即逝,，數(shù)不勝數(shù)。EC2 實例,、Spot 實例,、容器、無服務器功能,、管理員和敏捷開發(fā)團隊是數(shù)不清的鉆探數(shù)據(jù)轉瞬即逝的設備,。

　　我們的新世界存在數(shù)據(jù)控制問題

　　難怪53% 的使用云的組織都在線公開了數(shù)據(jù)？雖然所有這些靈活性和敏捷性都有利于創(chuàng)新和靈活性,，但它也帶來了新的挑戰(zhàn),。特別是，我們有一個跟蹤和控制云數(shù)據(jù)以及可以訪問它的內容。

　　我們的 Breach Watch 頁面上列出了一小部分廣為人知的云數(shù)據(jù)丟失事件示例,，但我們可以確信,，隨著云平臺的快速采用和新開發(fā)技術的持續(xù)有增無減，數(shù)據(jù)控制問題將會加劇,。

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

　　現(xiàn)有工具無法管理云數(shù)據(jù)蔓延

　　隨著云和敏捷成為主流,，傳統(tǒng)的數(shù)據(jù)中心和網(wǎng)絡管理工具都停留在過去。以從業(yè)者為中心的云提供商工具也無法勝任這項任務,。AWS,、Azure、GCP 和其他云提供商中存在明顯不同的身份和數(shù)據(jù)模型,。訪問控制列表,、內聯(lián)策略、組內聯(lián)策略,、角色內聯(lián)策略,、代入角色、切換角色聯(lián)合和托管策略都會影響訪問資源的內容,。

　　我們必須了解多個云提供商身份和數(shù)據(jù)模型,，并跟蹤對主要 AWS、GCP 和 Azure 云平臺中使用的第三方數(shù)據(jù)存儲的訪問,。當公司需要跟蹤跨多個云,、大量云帳戶和數(shù)千個數(shù)據(jù)存儲的數(shù)據(jù)訪問和移動時，該公司該何去何從,？

　　技術可以提供幫助

　　目前已有需要的云技術為跨云帳戶,、云提供商和第三方數(shù)據(jù)存儲的所有身份和數(shù)據(jù)關系、活動和數(shù)據(jù)移動提供完整的風險模型,。服務重點是所有有權訪問數(shù)據(jù)的實體的數(shù)據(jù)+身份——跨云提供商和第三方數(shù)據(jù)存儲,。最后，云技術在 DevOps 和安全團隊之間架起了橋梁,，以：

　　1,、提高數(shù)據(jù)安全性并降低風險。用戶配置風險和公共數(shù)據(jù)暴露風險都是跨云提供商、賬戶,、國家,、團隊和應用程序報告的。

　　2,、確保合規(guī),。數(shù)據(jù)主權、數(shù)據(jù)移動和身份關系都受到監(jiān)控,，以確保符合主權,、GDPR、HIPAA和其他合規(guī)性要求,。

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