微服務如何改變企業網絡安全?
微服務帶來了敏捷和韌性,但是其安全價值卻常被忽視。微服務技術革命在過去幾年席卷了全球的企業IT市場,根據statista 2021年的調查,71%的企業報告稱將采用該架構。但是,當我們討論微服務時,更多關注的是微服務給企業IT帶來的敏捷性和靈活性優勢,對企業安全的影響卻鮮有提及。
在單體應用程序時代,一個安全問題可能意味著要花費數百甚至數千個工時重構應用程序。除了修補安全漏洞,安全團隊往往還需要審查和重新構建應用程序依賴關系,有時還需要對整個應用程序進行逆向工程。
微服務的出現顛覆了這種范式,DevOps可以隔離并解決安全漏洞,而不必擔心破壞整個應用程序堆棧,企業可以大幅縮短安全補丁周期,同時整個DevOps團隊和IT堆棧更具彈性和效率。
自帶風險隔離
微服務為什么能夠隔離風險?首先我們簡單回顧一下微服務架構的定義:微服務架構是將單個的整體應用程序分割成更小的項目關聯的獨立的服務,可獨立部署并通過API等輕量中介松散綁定在一起。這些獨立的微服務不需要部署在同一個虛擬機,同一個系統和同一個應用服務器中。
實際上,容器是用于交付微服務架構的技術。這些輕量級獨立包將應用程序代碼與輕量級操作系統、運行時、庫和配置數據捆綁在一起。通過像Kubernetes這樣的編排系統,各個容器可以相互交換輸出,執行以前需要通過單體應用程序實現的總體任務。
由容器交付的微服務架構“先天”能夠隔離許多安全風險。由于各個微服務僅通過協調它們的中介交換信息,因此對單個微服務的入侵或破壞很難影響到整個應用程序。
提高安全彈性和效率
微服務自帶的“風險隔離”在實踐中意味著什么呢?以下是一個假想實驗:
幾年前產品制造商們發現,如果設備日期更改為1970年1月1日,會導致許多消費端設備將無法使用。假設企業環境中的日歷應用程序也存在類似的漏洞,而且有黑帽攻擊者在安全團隊之前發現了這個漏洞,通過獲取某位員工的憑證,成功將日歷應用程序中的日期更改為1970年1月1日。
如果企業的DevOps團隊使用單體應用程序,他們將必須執行以下操作:
- 首先,他們將不得不應對攻擊引起的大面積系統故障,只有解決漏洞才能修復這些故障。
- 其次,假設DevOps團隊發現漏洞位于日歷應用程序中,將不得不檢查該應用程序的整個源代碼并手動查找問題所在。
- 最后,團隊將不得不審查整個日歷應用程序的源代碼,以更改對與錯誤代碼行相關的變量或語句的任何引用。
如果同一個DevOps團隊使用了微服務架構,情況會是怎樣?
- 首先,一旦黑帽攻擊者更改了日期,DevSecOps就會注意到包含該漏洞的特定微服務出現故障。
- 其次,假設團隊正在使用容器,他們的Kubernetes發行版將標記特定容器未發送有效的輸出數據。
- 最后,團隊將失陷容器的設置恢復到惡意日期更改之前是一件簡單的事情。
一旦他們通過設置回滾完成了初始診斷和解決方法,團隊就可以著手修復導致漏洞的潛在缺陷。在整個過程中,日歷應用程序主體——以及依賴它的所有東西——都保持在線可用。
提高主動安全能力
上面的“案例”表明,微服務能極大提升企業系統的安全彈性和主動安全能力。
因為在微服務架構中,只有存在缺陷或漏洞的組件需要更換或更新,而不是整個應用程序。系統故障或漏洞導致的停機時間會減少,因為團隊可以識別并恢復受損的單個微服務。此外,微服務還能大大減少DevOps和安全團隊緩解漏洞的工作量,因為他們只需要重新設計一個單獨的微服務,這比重構一個完整的單體應用程序需要編寫的代碼量少很多。
通過隔離風險和漏洞的“防護欄”,微服務能提高團隊的主動性。團隊能夠不斷改進單個微服務,而無需考慮應用程序的其余部分。
這意味著DevSecOps專業人員可以專注于注意漏洞或推出安全更新。無需管理或后勤工作來阻止安全更新破壞應用程序中的另一個微服務。在修復零日漏洞或保護您的應用程序免受新出現的威脅時,這種靈活性和自由度是無價的。
微服務使DevSecOps團隊能比以往更快、更有效地響應安全威脅。在主動安全方面,微服務可以大幅提升團隊強化系統的速度。
總而言之,微服務改變企業IT安全的根本原因是:能夠極大提高開發人員、運維人員和安全團隊的工作效率,并且提供前所未有的靈活性。
GoUpSec點評
微服務是企業IT架構的一次重大變革,同時也對企業網絡安全演進產生重大影響。微服務架構采用獨立部署、松散綁定的服務,通過容器隔離安全風險。在緩解安全漏洞時,微服務架構使DevOps團隊能更快定位并解決問題,減少停機時間。此外,微服務讓團隊更加主動,可以專注于處理漏洞或推出安全更新,而無需擔心更新會破壞或影響應用程序的其他部分。總的來說,微服務架構讓開發人員、運維人員和安全團隊的工作速度更快,并且具有前所未有的主動性、靈活性和彈性。