隨著業界持續向云端遷移，安全實踐者不僅僅需要保護云實現的安全，還需要在上線后能夠做出應急響應和取證。很多企業已經在以一種或者另外的格式使用云，這取決于服務模型——基礎架構即服務，軟件即服務或者平臺即服務——需要按需采用對應的應急響應和取證調查流程來支持云計算服務。本文調研了實現云應急響應和取證的注意點和好處。
云應急響應：讓我們開始吧
遷移到某個云服務供應商的時候，需要做的第一件事情是評估企業當前擁有的東西，以及遷移到云端將如何改變自己的應急響應和取證流程。在云上執行這些流程是一個全新的領域，需要在轉變開始之前就完整地理解所有東西。這樣過程中的核心因素是決定實現云的所有系統的服務模型，以及數據會存儲在哪里。這有助于指導決策，如果企業已經知道數據存儲在哪里，那么在事件發生時就能夠更快地處理整個流程。
另外，企業通常會減慢向云端遷移的速度，并且仍然在本地數據中心保留一個實例。使用這樣的混合架構時，企業需要更加小心，因為當前的應急響應和取證工具并非為云而設計或者實現的。這會在網絡上留下安全盲區，使得發現不了攻擊，并且沒有能力執行云取證。比如，登錄進云系統是否就能夠獲得登入本地日志管理存儲的能力?既然流量并沒有離開云實例，那么企業如何處理入侵防御系統的檢查?如果不從這個角度徹底設計，那么既處在云端又鏈接到物理世界的架構可能就是危險的。
進行針對企業內已有應急響應/取證工具和流程是如何使用的，以及它們如何在云端使用的差距分析至關重要。這決定了遷移到云端是否會造成流程里的限制，或者可能會有什么改進。進程的所有改動需要基于以后將如何工作來決定。在這期間，需要進行對云里的應急響應和取證流程的CSP角色和職責的審核，這樣企業能夠理解如何在云上在合作模型下運行。
CSP支持和數據管理
取決于服務模型，CSP支持在流程里扮演的角色有所不同，這點必須在遷移上云之前了解清楚。CSP支持團隊會成為應急響應團隊的重要且活躍的成員，并且需要知道如何在runbook里工作。這些流程必須在遷移之前就制定出來，并且在集成階段進行測試，在云端和本地都要進行驗證。企業從IaaS服務模型里得到的越多，供應商通常需要負責的就越少;這對于應急響應和取證評估也是一樣的。必須理解每個部門負責什么，以及在真正的事件發生時該如何處理。
執行應急響應和取證需要考慮到的另一個因素是事件中如何收集并保存數據。完成這些時，產銷監管鏈很重要，并且現在會包含一個輔助流程的第三方工具。非常有可能系統會作為共享基礎架構的一部分來實現，之前也去所擁有的日志源現在都不可用了。比如，如果針對某個托管在公有云上的網站發起拒絕服務攻擊，因為基于其他客戶的隱私考慮，很可能不會接受到NetFlow數據。即使在IaaS模型里，請求日志時還不可用這樣的情況也會經常發生。只要有內置的共享基礎架構，那么就有可能丟失日志和可見性。
很多CSP都在全面地提供擴展的安全產品或者功能，幫助云上的安全服務盡可能得不出問題。如果整個基礎架構都是基于云的，那么本質上你需要按需管理所有在一個供應商里的系統。可以凍結，停用鏈接，或者甚至為應急響應和取證所需而在安全地域隔離虛擬機。
應急響應和取證：問題列表
當選擇提供很好的應急響應和取證框架的云供應商/應用程序時，可以查看如下列表：
開放API使得企業可以直達CSP產品，并且直接接入到企業已有的產品和服務里。如果往云上的遷移最終是混合狀態的話，這一點至關重要。
決定系統如何記錄日志，以及會存儲哪些類型的日志。產品不同時這一點會有所區別，但是CSP是否能提供這樣的功能或者你是否需要云上的日志管理產品，或者需要發送日志的單獨的系統?
檢查CSP和你的安全軟件如何是處理云上的彈性的。當新系統出現，或者摧毀時，日志，端點安全和網絡安全如何處理?從應急響應和取證的角度來看，這些團隊都需要了解這些系統是如何遷移的，以及它們的軟件能否被部署。另外，還需要了解系統退役時，如何處理數據。
決定是否現有的安全服務也能夠在云上實現。如何執行IPS?大部分情況下，是在網絡上完成的，但是現在在云上，那么很多情況下會在主機級別完成這件事情。在云上是否有當前在本地使用的東西的虛擬副本?這一點在進行調查時很重要。
你的數據，系統，應用程序和日志是否可能需要移動到別的國家?如果那個國家的隱私法規限制應急響應和取證團隊完成他們的工作的話，就有可能讓調查停滯不前。
提前審查CSP，SOC 2以及其他合規相關的文檔。這會讓你充分了解CSP是什么，以及填補云上的應急響應和取證流程還有哪些缺失的地方。
總結
進行應急響應和取證有很多好處;并不總是很難進行。企業在開始完全向云上遷移時就能夠最大地體會到這些好處，但是要知道服務模型在這上面起著很大的作用。如果企業是從IaaS角度進入云世界的話，就需要首先從安全的角度調研CSP能夠提供什么。
京公網安備 11010502049343號