集中化是多云安全策略的關鍵

山東 姜建華 李文竹

在企業構建多云的安全策略時，集中化是安全團隊重點關注的最為關鍵的領域之一。對于多云系統，運營和安全團隊可能面臨碎片化或分散的安全訪問控制和監視工具，如果這些控制和工具在每個獨立的供應商環境中設計和實施，企業往往面臨著不少挑戰。

有些云運營團隊尋求多云代理商并將所有的云管理集中和整合到一個地方，還有的企業選擇一種獨立的產品或平臺，使其與所有必要的供應商環境相集成，從而可以對安全策略和訪問管理進行集中控制，而不管其底層的云基礎架構是什么。

在部署多云安全策略時，安全團隊應當評估當前所有的云控制，并判斷是否實施了集中化，其中包括：

端點安全工具：許多反惡意軟件、端點檢測的工具能夠在多云的環境中運行。

配置和打補丁工具：如果可能的話，構建云負載鏡像應當實現集中化，這要比傳統的鏡像工具更多地依賴基礎架構。配置管理的自動化平臺可用于維護所有已部署實例的配置的連續性。

漏洞掃描：多數企業的漏洞掃描器已經成功地集成到當今主要云供應商的環境中，所以，為這種類型的控制實施一種分散性的方法已不太可能，云“控制面”掃描和評估工具可以對云賬戶的配置和環境自身形成報告，這種操作應當對云的覆蓋范圍進行評估。

事件收集和SIEM/分析：將所有的日志從云環境遷移到一個用于評估的中心源已經變得相對簡單，因為主要的SIEM 企業已經與多數云供應商進行集成。此外，在這方面還有一些新的SaaS產品。

基于模板的“基礎設施即代碼”：云運營團隊應當將基礎架構用作代碼工具，其可以與本地云的模板技術（如AWS Cloud Formation 及Azure Resource Manager 模板）相整合，用以定義基礎架構配置和云賬戶的其他要素，很多安全控制如身份策略、網絡配置、鏡像模板等也可用這種方法配置。

而有些控制是不容易集中化的，其中包括三個方面：首先是加密，多數企業最終使用的是特定的云供應商的密鑰管理工具；其次是所有的身份和訪問管理；第三是自動化，常見的就是環境中的API 和特定腳本的編寫。

務必關注跨平臺的廠商。理想情況下，如果企業可以在功能基本相同的廠商和成本之間進行選擇，應優先考慮在多云環境中覆蓋范圍更大的廠商。對于事件響應、取證、SOC 團隊所使用的取證和響應工具而言，也應如此考慮。這些工具需要盡可能地簡化流程和操作手冊，以使用統一的證據收集和調查策略。

集中化并不是在遷移到多云架構時唯一考慮的重點。安全團隊還應當在多層上實施控制，并考慮如何應用在每種環境中。對于在多云以及在本地環境中實施一種深度防御的控制架構來說，企業有著比以往更多的選項。安全和運營團隊應當真正關注幾個問題。

首先就是可以為策略的構建和總體管理而集中實施的工具。這些工具的管理越簡單，網絡設計的結果就越成功。

其次，安全和運營團隊還應當優先考慮使用“基礎架構即代碼”之類的工具。

最后，安全團隊應當考慮實施多層網絡分段策略。傳統的防火墻在支持本地和云環境的網絡連接方面仍有其地位，這種防火墻還可以提供入侵防御和許多企業今天仍需要的其他控制。當然，企業還要實施本地的云訪問和分段控制。

對于大型的云部署而言，有些本地云控制的基準實施可以證明是有價值的，但是擁有大量資產的多云設計，可能真正地從更深層次的應用程序的可見性中獲益。這種做法還有助于監視和報告的集中化。當今沒有哪種本地云的工具提供這種水平的檢查和動態的策略評估，這意味著需要實施傳統的工具，目的是為確定檢查了哪些類型的應用程序通信，并且還是為了對多云環境和本地數據中心內部的負載傳輸而實施一種集中化的策略。這往往要求某種類型的終端代理來提供必要的檢查和執行。

大型企業遷移到多云環境是一種趨勢，但仍有關于集中化利弊的一些爭論。可證明的是，集中化的系統有益于協調和通信效率，并可確保一致性。與之形成對比的是，在大型企業中很難實施和維護一種非集中化的、非分級的系統。