隨著業(yè)界持續(xù)向云端遷移，安全實踐者不僅僅需要保護云實現(xiàn)的安全，還需要在上線后能夠做出應急響應和取證。很多企業(yè)已經(jīng)在以一種或者另外的格式使用云，這取決于服務模型——基礎架構(gòu)即服務，軟件即服務或者平臺即服務——需要按需采用對應的應急響應和取證調(diào)查流程來支持云計算服務。本文調(diào)研了實現(xiàn)云應急響應和取證的注意點和好處。

[[170725]]

　　云應急響應：讓我們開始吧

　　遷移到某個云服務供應商的時候，需要做的第一件事情是評估企業(yè)當前擁有的東西，以及遷移到云端將如何改變自己的應急響應和取證流程。在云上執(zhí)行這些流程是一個全新的領域，需要在轉(zhuǎn)變開始之前就完整地理解所有東西。這樣過程中的核心因素是決定實現(xiàn)云的所有系統(tǒng)的服務模型，以及數(shù)據(jù)會存儲在哪里。這有助于指導決策，如果企業(yè)已經(jīng)知道數(shù)據(jù)存儲在哪里，那么在事件發(fā)生時就能夠更快地處理整個流程。

　　另外，企業(yè)通常會減慢向云端遷移的速度，并且仍然在本地數(shù)據(jù)中心保留一個實例。使用這樣的混合架構(gòu)時，企業(yè)需要更加小心，因為當前的應急響應和取證工具并非為云而設計或者實現(xiàn)的。這會在網(wǎng)絡上留下安全盲區(qū)，使得發(fā)現(xiàn)不了攻擊，并且沒有能力執(zhí)行云取證。比如，登錄進云系統(tǒng)是否就能夠獲得登入本地日志管理存儲的能力?既然流量并沒有離開云實例，那么企業(yè)如何處理入侵防御系統(tǒng)的檢查?如果不從這個角度徹底設計，那么既處在云端又鏈接到物理世界的架構(gòu)可能就是危險的。

　　進行針對企業(yè)內(nèi)已有應急響應/取證工具和流程是如何使用的，以及它們?nèi)绾卧谠贫耸褂玫牟罹喾治鲋陵P重要。這決定了遷移到云端是否會造成流程里的限制，或者可能會有什么改進。進程的所有改動需要基于以后將如何工作來決定。在這期間，需要進行對云里的應急響應和取證流程的CSP角色和職責的審核，這樣企業(yè)能夠理解如何在云上在合作模型下運行。

　　CSP支持和數(shù)據(jù)管理

　　取決于服務模型，CSP支持在流程里扮演的角色有所不同，這點必須在遷移上云之前了解清楚。CSP支持團隊會成為應急響應團隊的重要且活躍的成員，并且需要知道如何在runbook里工作。這些流程必須在遷移之前就制定出來，并且在集成階段進行測試，在云端和本地都要進行驗證。企業(yè)從IaaS服務模型里得到的越多，供應商通常需要負責的就越少;這對于應急響應和取證評估也是一樣的。必須理解每個部門負責什么，以及在真正的事件發(fā)生時該如何處理。

　　執(zhí)行應急響應和取證需要考慮到的另一個因素是事件中如何收集并保存數(shù)據(jù)。完成這些時，產(chǎn)銷監(jiān)管鏈很重要，并且現(xiàn)在會包含一個輔助流程的第三方工具。非常有可能系統(tǒng)會作為共享基礎架構(gòu)的一部分來實現(xiàn)，之前也去所擁有的日志源現(xiàn)在都不可用了。比如，如果針對某個托管在公有云上的網(wǎng)站發(fā)起拒絕服務攻擊，因為基于其他客戶的隱私考慮，很可能不會接受到NetFlow數(shù)據(jù)。即使在IaaS模型里，請求日志時還不可用這樣的情況也會經(jīng)常發(fā)生。只要有內(nèi)置的共享基礎架構(gòu)，那么就有可能丟失日志和可見性。

　　很多CSP都在全面地提供擴展的安全產(chǎn)品或者功能，幫助云上的安全服務盡可能得不出問題。如果整個基礎架構(gòu)都是基于云的，那么本質(zhì)上你需要按需管理所有在一個供應商里的系統(tǒng)?？梢詢鼋Y(jié)，停用鏈接，或者甚至為應急響應和取證所需而在安全地域隔離虛擬機。

　　應急響應和取證：問題列表

　　當選擇提供很好的應急響應和取證框架的云供應商/應用程序時，可以查看如下列表：

　　開放API使得企業(yè)可以直達CSP產(chǎn)品，并且直接接入到企業(yè)已有的產(chǎn)品和服務里。如果往云上的遷移最終是混合狀態(tài)的話，這一點至關重要。

　　決定系統(tǒng)如何記錄日志，以及會存儲哪些類型的日志。產(chǎn)品不同時這一點會有所區(qū)別，但是CSP是否能提供這樣的功能或者你是否需要云上的日志管理產(chǎn)品，或者需要發(fā)送日志的單獨的系統(tǒng)?

　　檢查CSP和你的安全軟件如何是處理云上的彈性的。當新系統(tǒng)出現(xiàn)，或者摧毀時，日志，端點安全和網(wǎng)絡安全如何處理?從應急響應和取證的角度來看，這些團隊都需要了解這些系統(tǒng)是如何遷移的，以及它們的軟件能否被部署。另外，還需要了解系統(tǒng)退役時，如何處理數(shù)據(jù)。

　　決定是否現(xiàn)有的安全服務也能夠在云上實現(xiàn)。如何執(zhí)行IPS?大部分情況下，是在網(wǎng)絡上完成的，但是現(xiàn)在在云上，那么很多情況下會在主機級別完成這件事情。在云上是否有當前在本地使用的東西的虛擬副本?這一點在進行調(diào)查時很重要。

　　你的數(shù)據(jù)，系統(tǒng)，應用程序和日志是否可能需要移動到別的國家?如果那個國家的隱私法規(guī)限制應急響應和取證團隊完成他們的工作的話，就有可能讓調(diào)查停滯不前。

　　提前審查CSP，SOC 2以及其他合規(guī)相關的文檔。這會讓你充分了解CSP是什么，以及填補云上的應急響應和取證流程還有哪些缺失的地方。

　　總結(jié)

　　進行應急響應和取證有很多好處;并不總是很難進行。企業(yè)在開始完全向云上遷移時就能夠最大地體會到這些好處，但是要知道服務模型在這上面起著很大的作用。如果企業(yè)是從IaaS角度進入云世界的話，就需要首先從安全的角度調(diào)研CSP能夠提供什么。