譯者 | 布加迪
審校 | 重樓?
這幾年，微服務革命席卷整個IT界，71%的組織聲稱2021年之前采用了這種架構。在討論微服務時，我們常聽到其優勢在于可以靈活地向客戶交付創新成果。但有一個方面卻很少被人提及，那就是企業安全問題。?
在單體式應用程序時代，單單一個安全問題就可能意味著要花成百上千個小時從頭重新構建應用程序。除了必須修補安全漏洞本身外，這還意味著DevOps團隊和安全團隊將不得不審查和重構應用程序以調整依賴項，有時不得不有效地對整個應用程序進行逆向工程處理。?
微服務顛覆了這種模式。它允許DevOps團隊在不用擔心破壞整個應用程序架構的情況下隔離安全漏洞或問題，并解決它們。這不僅意味著可以更迅速地開發出安全補丁，還意味著DevOps團隊和IT架構整體上更有彈性、更高效。?
微服務如何幫助隔離安全漏洞？?
先有必要提醒一下什么是微服務架構：這是一組可以獨立部署的服務，通過API等中介系統松散地聯系在一起。這些單獨的服務通常反映了應用程序最基本的構建模塊。?
實際上，容器是用于交付微服務架構的技術。這些輕量級獨立軟件包將應用程序代碼與輕量級操作系統、運行時環境、庫和配置數據捆綁在一起。通過使用像Kube.NETes這樣的編排系統，各個容器可以彼此交換輸出內容，使它們能夠執行曾經通過單體式應用程序才能實現的總體任務。?
微服務架構通常由容器提供，通過設計來隔離許多安全風險。由于單個微服務僅通過編排它們的中介系統交換輸出，單個微服務被破壞或攻擊很難影響整個應用程序。?
以日歷為例?
在實踐中，上述表述又意味著什么呢？以下是一個推演案例。?
幾年前制造商發現，如果將日期改為1/1/1970，許多消費級設備就無法使用。想象一下：如果我們將該缺陷引入到用于企業環境中的日歷應用程序?，F在假設黑帽攻擊者搶在安全團隊之前發現了這個問題，隨后進而獲取某人的憑據，并將日歷應用程序中的當前日期更改為1/1/1970。?
如果企業的DevOps團隊在處理單體式應用程序，他們不得不做以下工作：?
首先，他們將不得不應對由攻擊引起的一系列廣泛的系統故障，除非解決了這個缺陷，否則他們無法修復這些問題。?
其次，假設他們發現了缺陷出在日歷應用程序上，將不得不檢查該應用程序的完整源代碼，并手動找到問題所在。?
最后，他們將不得不檢查整個日歷應用程序的源代碼，以更改引用與有漏洞的代碼行相關的變量或語句的任何地方。?
如果同一個DevOps團隊處理微服務架構，情況又會怎樣呢？?
首先，一旦黑帽攻擊者更改了日期，他們會注意到含有缺陷的特定微服務出現了故障。?
其次，假設他們在使用容器，他們的Kubernetes發行版會標記特定的容器并沒有發送有效的輸出數據。?
最后，團隊只需將有問題的容器的設置恢復到惡意日期更改之前即可。?
一旦團隊完成了最初的診斷并通過設置回滾來解決問題，他們可以修復導致漏洞的底層缺陷。綜觀整個過程，更廣泛的日歷應用程序以及依賴它的一切都保持在線狀態。?
微服務有助于提高效率和主動性?
從上面的故事中可以得出一大啟示：在微服務架構中，只需要替換或更新有缺陷的組件，而不是替換或更新整個應用程序。這意味著果真出現問題或漏洞時，停運時間更短，因為團隊可以識別并恢復受損的單個微服務。此外，這為DevOps團隊和安全團隊減少了解決缺陷的工作量，因為他們只需要改動單個微服務，需要改動的應用程序代碼必然比完整的單體式應用程序更少。?
此外，微服務讓團隊可以更積極主動。微服務通過防止攻擊或級聯漏洞的隔離機制來實現這種主動性。這種隔離機制讓團隊能夠不斷地改進單個微服務，不必考慮應用程序的其余部分。?
這意味著DevSecOps專業人員可以致力于留意漏洞或推出安全更新。不需要管理或后勤工作來阻止安全更新破壞應用程序中的另一個微服務。說到修復零日漏洞或保護應用程序免受新出現的威脅，這種靈活性和自由度大有益處。?
由于微服務，團隊可以比以往任何時候更快速、更有效地響應安全威脅。說到主動性方面，微服務使團隊能夠以極快的速度加固系統?？傊?，這就是為什么說微服務已改變了企業IT安全界的面貌：它們讓開發團隊、運營團隊和安全團隊能夠以前所未有的靈活性更快速地工作。?
原文標題：??How microservices have transformed enterprise security??，作者：Simon Wright
