盡管企業(yè)消費技術(shù)的途徑不斷在發(fā)展，但是相比之下最近兩種趨勢引人注目。首先是云用例持續(xù)激增。其次是新數(shù)據(jù)外泄不斷占據(jù)頭條?？梢岳斫?，這兩個事實讓很多組織機構(gòu)擔(dān)心與其云部署相關(guān)的可能的泄露。這種恐懼是復(fù)合的，因為很多時候，在提及安全操作時，使用云計算就假設(shè)放棄了部分控制。換句話說，采用云計算——無論是通過內(nèi)網(wǎng)還是外網(wǎng)云服務(wù)提供商交付——意味著有目的的“抽取”應(yīng)用堆棧的基礎(chǔ)部分。
需要指出的是這并非暗指云必然要比替代交付模型更加充滿風(fēng)險、缺少安全或者更易于產(chǎn)生數(shù)據(jù)泄露。相反，一些數(shù)據(jù)顯示了截然相反的事實。但是事實上，云用戶在提及安全時仍會感到一機靈。部分原因是缺少控制：就像一個飛機上的乘客可能(根據(jù)統(tǒng)計)要比開車的乘客更安全，缺少直接的操作控制也更讓人感到恐懼。
這也就是說云服務(wù)提供商(CSP)的數(shù)據(jù)泄露可能且會發(fā)生。當(dāng)數(shù)據(jù)泄露發(fā)生時，如果企業(yè)的事件響應(yīng)計劃由于云的功效做出不適合的響應(yīng)，那這就是一次不幸的意外了。比如，當(dāng)你對技術(shù)基礎(chǔ)只有很少或者沒有操作控制時，整個計劃包含具體的技術(shù)活動(比如禁用一個網(wǎng)絡(luò)端口來壓制惡意軟件主機)可能不可行。
在很多企業(yè)的云環(huán)境中這是可能發(fā)生的，不管是基礎(chǔ)架構(gòu)即服務(wù)(IaaS)、平臺即服務(wù)(PaaS)還是軟件即服務(wù)(SaaS)。除非你已經(jīng)為這個做好了一些計劃，有可能很好地響應(yīng)云端的事件，可能你的遺留應(yīng)急響應(yīng)計劃并不包含在內(nèi)。比如，你如何獲得通知?誰來授權(quán)實現(xiàn)來自提供商技術(shù)服務(wù)請求(他們是否在IR環(huán)中)?這個請求的機制是什么?是一個特定的服務(wù)控制面板還是電話?響應(yīng)團隊的曾遠知道如何獲得工具嗎?他們能否分配來進行訪問?
就像是一個傳統(tǒng)的IT環(huán)境，找出這些問題是如何回答的并不是一蹴而就的事情：現(xiàn)在開始準(zhǔn)備就已經(jīng)晚了。在這篇技巧中，我們將回顧如何為一次涉及云服務(wù)提供商的事件計劃數(shù)據(jù)泄露應(yīng)急響應(yīng)。
做好基礎(chǔ)工作
企業(yè)應(yīng)該做的第一件事情就是根據(jù)云回顧通知的途徑：什么意思呢?如果發(fā)生泄露，(是否)CSP如何向你的企業(yè)機構(gòu)報告數(shù)據(jù)泄露或者其他的安全事件。這些聽起來相當(dāng)直接，直到你真正開始操作，也就是說由于不同的用例和交付模型–以及不同的服務(wù)提供商–可能會改變通知客戶的方式。
比如，考慮一種大規(guī)模的IaaS部署，比如虛擬化數(shù)據(jù)中心。在這個場景中，可能合約性的口述需求，泄露通知怎樣和在什么時候會出現(xiàn)，可能通過合同規(guī)定的渠道來通知你具體的技術(shù)事件。相比之下，SaaS業(yè)務(wù)應(yīng)用可能在合同中規(guī)定通知，但是不要求共享技術(shù)細節(jié)。其他的，比如面向消費者的服務(wù)，比如DropBox,可能沒有一個合同，更不必說具體的泄露通知了。
問題在于，可能并沒有一個針對所有云服務(wù)的跨面板的統(tǒng)一的通知位置。因此，“你怎么知道什么時候發(fā)生泄漏呢?”就像用例不能用同樣的筆刷圖畫，通知也同樣。相反，企業(yè)必須就事論事地評估CSP關(guān)系、用例和通知選項。(需要指出的是這也意味著企業(yè)知道什么用例在第一位。如果不知道，就應(yīng)該從這里開始。)
在用這種方式評估每一個云用例時，確保考慮到CSP被要求做什么(或者對于內(nèi)部提供商達成協(xié)議)，告知你事件的機制，以及你同其交互的選擇是什么等。在評估期間尤其要注意三件事：你如何使用這個服務(wù)(比如，存儲的數(shù)據(jù)類型、支持的業(yè)務(wù)類型等)、主要員工(你的員工和提供商的員工)以及你在查找泄露時的責(zé)任是什么(比如報告基于你的評估，比如入侵檢測或者應(yīng)用日志)。這個數(shù)據(jù)在隨后的計劃階段很重要。
開始更大的部署很有幫助，比如集中化IaaS和PaaS,因為他們更易于處理。應(yīng)用(比如SaaS)也很重要，但是記住追蹤他們是重要的責(zé)任，比如來自Netskope的最近的數(shù)據(jù)，建議組織架構(gòu)平均采用397個云應(yīng)用。因此獨立分析每一個很可能會花費一點時間和精力。
這里的關(guān)鍵點在于從容易的開始并構(gòu)建它。文檔時刻伴隨是個好主意，因為隨著時間的推移會變得越來越復(fù)雜。
為運營響應(yīng)做計劃
一旦你收集了要求的數(shù)據(jù)，是時候進入計劃的第二階段了：分類以及一個操作的響應(yīng)藍圖。如果這個聽起來非常像“傳統(tǒng)的”泄露響應(yīng)，其實的確如此。實際上，云泄露響應(yīng)可以作為更為廣泛的響應(yīng)計劃工作的擴展，從而更好地實現(xiàn)。的確，由于環(huán)境不同，比如優(yōu)先次序不同，技術(shù)響應(yīng)選項和警報/通知路徑不同，但是記得大多數(shù)用例都會在云和傳統(tǒng)IT元素之間有一個交互點。這意味著為云組件嘗試隔離維護單獨的響應(yīng)流程不可避免的導(dǎo)向更加的復(fù)雜性，缺乏透明度(比如，運營責(zé)任)和事件中產(chǎn)生的額外開支。
正如傳統(tǒng)的災(zāi)難恢復(fù)和事故相應(yīng)計劃，優(yōu)先級應(yīng)該基于影響，反映了數(shù)據(jù)類型的功能以及業(yè)務(wù)危險程度。這兩個因素也允許你了解是否或者什么時候或者其他的流程如何，比如外部公開的規(guī)程，都應(yīng)該算在內(nèi)。對比現(xiàn)有的事故響應(yīng)流程額一個不同就在于，有助于基于關(guān)系自定制響應(yīng)習(xí)慣，因為一些動作你可能系統(tǒng)包含在同CSP的交互中。比如，你可能要求你的CSP影響技術(shù)改變或者提供額外的信息。在這樣的情況下，你可能會選擇記錄下來這些同CSP的經(jīng)驗。
問題在于，收集足夠的信息可以為實際的策略活動構(gòu)建你要完成的“響應(yīng)藍圖”.因為響應(yīng)的細節(jié)因環(huán)境、用例和關(guān)系而多變，加上其他的一些變量，你可能希望更加具體的技術(shù)活動；比如，事件響應(yīng)計劃和技術(shù)清單。為什么?因為你可能希望給予提供商所做的以及技術(shù)上不允許你做的等內(nèi)容自定制技術(shù)響應(yīng)活動。
需要牢記的是在做云端響應(yīng)的時候并沒有任何不同，首先要做的就是詳細規(guī)劃，在技術(shù)計劃中為你的組織機構(gòu)如何對這些不同做出說明是非常有用的第一步。
