盡管企業消費技術的途徑不斷在發展，但是相比之下最近兩種趨勢引人注目。首先是云用例持續激增。其次是新數據外泄不斷占據頭條。可以理解，這兩個事實讓很多組織機構擔心與其云部署相關的可能的泄露。這種恐懼是復合的，因為很多時候，在提及安全操作時，使用云計算就假設放棄了部分控制。換句話說，采用云計算——無論是通過內網還是外網云服務提供商交付——意味著有目的的“抽取”應用堆棧的基礎部分。

需要指出的是這并非暗指云必然要比替代交付模型更加充滿風險、缺少安全或者更易于產生數據泄露。相反，一些數據顯示了截然相反的事實。但是事實上，云用戶在提及安全時仍會感到一機靈。部分原因是缺少控制：就像一個飛機上的乘客可能(根據統計)要比開車的乘客更安全，缺少直接的操作控制也更讓人感到恐懼。

這也就是說云服務提供商(CSP)的數據泄露可能且會發生。當數據泄露發生時，如果企業的事件響應計劃由于云的功效做出不適合的響應，那這就是一次不幸的意外了。比如，當你對技術基礎只有很少或者沒有操作控制時，整個計劃包含具體的技術活動(比如禁用一個網絡端口來壓制惡意軟件主機)可能不可行。

在很多企業的云環境中這是可能發生的，不管是基礎架構即服務(IaaS)、平臺即服務(PaaS)還是軟件即服務(SaaS)。除非你已經為這個做好了一些計劃，有可能很好地響應云端的事件，可能你的遺留應急響應計劃并不包含在內。比如，你如何獲得通知?誰來授權實現來自提供商技術服務請求(他們是否在IR環中)?這個請求的機制是什么?是一個特定的服務控制面板還是電話?響應團隊的曾遠知道如何獲得工具嗎?他們能否分配來進行訪問?

就像是一個傳統的IT環境，找出這些問題是如何回答的并不是一蹴而就的事情：現在開始準備就已經晚了。在這篇技巧中，我們將回顧如何為一次涉及云服務提供商的事件計劃數據泄露應急響應。

做好基礎工作

企業應該做的第一件事情就是根據云回顧通知的途徑：什么意思呢?如果發生泄露，(是否)CSP如何向你的企業機構報告數據泄露或者其他的安全事件。這些聽起來相當直接，直到你真正開始操作，也就是說由于不同的用例和交付模型–以及不同的服務提供商–可能會改變通知客戶的方式。

比如，考慮一種大規模的IaaS部署，比如虛擬化數據中心。在這個場景中，可能合約性的口述需求，泄露通知怎樣和在什么時候會出現，可能通過合同規定的渠道來通知你具體的技術事件。相比之下，SaaS業務應用可能在合同中規定通知，但是不要求共享技術細節。其他的，比如面向消費者的服務，比如DropBox,可能沒有一個合同，更不必說具體的泄露通知了。

問題在于，可能并沒有一個針對所有云服務的跨面板的統一的通知位置。因此，“你怎么知道什么時候發生泄漏呢?”就像用例不能用同樣的筆刷圖畫，通知也同樣。相反，企業必須就事論事地評估CSP關系、用例和通知選項。(需要指出的是這也意味著企業知道什么用例在第一位。如果不知道，就應該從這里開始。)

在用這種方式評估每一個云用例時，確保考慮到CSP被要求做什么(或者對于內部提供商達成協議)，告知你事件的機制，以及你同其交互的選擇是什么等。在評估期間尤其要注意三件事：你如何使用這個服務(比如，存儲的數據類型、支持的業務類型等)、主要員工(你的員工和提供商的員工)以及你在查找泄露時的責任是什么(比如報告基于你的評估，比如入侵檢測或者應用日志)。這個數據在隨后的計劃階段很重要。

開始更大的部署很有幫助，比如集中化IaaS和PaaS,因為他們更易于處理。應用(比如SaaS)也很重要，但是記住追蹤他們是重要的責任，比如來自Netskope的最近的數據，建議組織架構平均采用397個云應用。因此獨立分析每一個很可能會花費一點時間和精力。

這里的關鍵點在于從容易的開始并構建它。文檔時刻伴隨是個好主意，因為隨著時間的推移會變得越來越復雜。

為運營響應做計劃

一旦你收集了要求的數據，directadmin安裝，是時候進入計劃的第二階段了：分類以及一個操作的響應藍圖。如果這個聽起來非常像“傳統的”泄露響應，其實的確如此。實際上，云泄露響應可以作為更為廣泛的響應計劃工作的擴展，從而更好地實現。的確，云服務器租用，由于環境不同，比如優先次序不同，技術響應選項和警報/通知路徑不同，但是記得大多數用例都會在云和傳統IT元素之間有一個交互點。這意味著為云組件嘗試隔離維護單獨的響應流程不可避免的導向更加的復雜性，缺乏透明度(比如，運營責任)和事件中產生的額外開支。