山東 趙長林
基于云的補丁管理系統和應用可能不同于傳統的內部程序。這些不同點將擴展到不同的部署類型,例如,對SaaS 部署的補丁相對直接而簡單,因為消費者無法控制補丁過程。如果供應商不能實時地對軟件和組件打補丁,就會帶來巨大的風險。
所有的企業都應當驗證其SaaS 或PaaS 供應商的補丁周期。服務供應商還應當將打補丁的方式傳達給企業,從而使企業知道潛在的性能或可能性問題。
要確保供應商有能力快速地對所有設備、應用和系統的漏洞打上補丁。應考慮供應商是否與客戶共享其基于風險的打補丁的時間。最終,企業應當尋求這樣一種云服務供應商:其服務要與企業的內部管理實踐和標準保持一致。
對于PaaS 環境來說,企業將擁有對補丁和配置的更多控制,尤其是對于應用和開發環境的組件和庫來說。企業應尋求將任何已用的平臺(ASP .NET、PHP、Java 等)和運行在其上的應用程序都集成到現有的測試和質量保證周期中,將在同一時間或在相同的周期內實施的修復作為內部應用。
補丁管理是PaaS 環境中的一個巨大挑戰。在應用這些補丁時,基礎架構團隊需要與開發和測試團隊密切協作。改變窗口還需要提前計劃,以適應云供應商的認可。如果要使用PaaS 的部署容器,容器的鏡像在被部署到一個安全存儲庫之前,可以打上補丁和實施測試。
所有后端的基礎架構,包括操作系統和網絡組件,仍由供應商打補丁。針對SaaS環境所涉及的問題也應當適用于這種模型。
對于IaaS 供應商,團隊可以安裝供應商的傳統的補丁管理代理。這些代理可以向位于中央數據中心或位于相同的云基礎架構中的補丁管理系統報告,當然,這要依賴部署的具體情況。
對于云負載來說,新的基于云的補丁管理選項正在出現,例如微軟的Azure 更新管理服務。這些工具可能更加高效,并且在本地就可以與運行在云基礎架構中的任何實例相集成。這些工具還包括腳本和調度等選擇。
新的和正在出現的本地云服務使得修復云負載的過程更加便捷,但是還有一些企業仍選擇使用已經擁有的工具實施IaaS 部署,用以簡化運營管理。
激進的云工程團隊和運營團隊正從傳統的補丁模型轉移。開發運營團隊不再花費需為應用程序打補丁以使系統運行的更長時間運行負載,而是轉向可被應用到新系統鏡像的補丁和更新。然后,推出這些補丁和更新,用以替換老舊的負載。
這就要求考慮到在部署過程中的大量測試。隨著自動化配置管理工具的使用,補丁和配置被大量地自動化。通過配置模板和配置管理工具而應用補丁,團隊就可以更容易地在負載鏡像上部署補丁和測試結果,然后再將部署了所有更新的新鏡像推送到生產云中。
或者,在“藍綠部署”中,測試環境被驗證,然后再投入生產,而老的生產環境成了測試區域。
不管所使用的云模式是什么,企業都應當正式地評估所有的供應商,以用于內部的補丁和漏洞管理控制。至少,供應商也應當能夠提供獨立的經驗證的控制證明,例如,一份SSAE 18 SOC報告。