標題：11 種微服務和容器安全最佳實踐（上）

在Statista 2021 年的一項調查中，34% 的受訪者表示他們已經採用了微服務，37% 的受訪者表示他們部分使用了微服務，證明了這種開發方式的流行。

儘管微服務方法具有許多好處，包括易於擴展和管理，但它也隱藏了一些安全問題，例如可能的漏洞和通信風險。在開始開發過程之前了解預期的網絡安全風險以及如何解決這些風險將幫助您創建可靠且安全的產品。

在本文中，我們觀察了在開發應用程序時可能出現的基於容器和微服務的架構中的安全挑戰。我們還提供11 種微服務和容器安全最佳實踐。本文對那些想要有效提高產品安全性的人以及對容器和微服務不熟悉的人很有用。

什麼是容器和微服務？容器和微服務是應用程序開發的流行方法，尤其是對於復雜的解決方案。 O'Reilly 的2020 年微服務採用報告顯示，77% 的受訪者採用了微服務，其中92% 的人通過這種方法獲得了成功。此外，使用容器部署微服務的受訪者比不使用容器的受訪者更有可能報告成功。

在我們討論如何在微服務和容器中實現安全性之前，讓我們確切地探討一下這些方法是什麼以及它們為應用程序開發過程帶來了什麼好處。

容器化是一種虛擬化形式，使您能夠在稱為容器的隔離空間中運行應用程序，這些容器使用相同的共享操作系統(OS)。虛擬化允許在單個物理服務器的硬件上運行多個操作系統，而容器化允許您在單個虛擬機或服務器上使用相同的操作系統部署多個應用程序。

容器，也稱為應用程序容器或服務器應用程序容器，是包含應用程序代碼及其庫和依賴項的可執行軟件單元。根據美國國家標準與技術研究院(NIST) 的說法，應用程序容器相互隔離但仍共享底層操作系統的資源這一事實使開發人員更容易跨云有效地擴展應用程序。

開發人員更喜歡使用基於容器的架構，因為容器輕量級、可移植且易於維護和擴展。由於這些品質，容器可用於現代開發方法，如DevOps、無服務器和微服務。此外，開發人員可以精細控制每個容器可以使用多少資源，從而提高物理機的CPU 和內存利用率。

容器的好處

微服務架構，或簡稱微服務，是一種應用程序開發的架構方法，其中單個應用程序由許多小型自治服務組成。

微服務是可獨立部署的，與單體架構相比，它允許您改進應用程序代碼、添加新功能和擴展每個服務。使用微服務，您可以更新現有服務，而無需重建和重新部署整個應用程序。

每個服務代表一個單獨的代碼庫，因此可以由一個小型開發團隊管理。微服務架構簡化了創建和維護複雜應用程序的過程，但不適合小型應用程序。

微服務是松耦合的，所以如果一個服務發生故障，其餘的繼續工作，提高了整個應用程序的容錯能力。此外，它們支持多語言編程，這意味著服務不需要共享相同的技術堆棧、庫或框架。

微服務的好處

您可以單獨或一起使用容器和微服務。由於在本文中我們討論了使用這兩種方法開發應用程序的安全實踐，因此讓我們簡要探討如何將容器和微服務結合起來。

簡單來說，容器為應用程序封裝了一個輕量級的運行時環境。因此，當在容器中開發微服務時，它繼承了容器化的好處，例如可移植性、可擴展性和額外的安全層。容器為每個容器化應用程序或微服務提供隔離。因此，它們降低了安全漏洞傳播的風險。

通過在單獨的容器中運行微服務，您可以獨立部署它們，而不管每個微服務是用什麼語言編寫的。通過這種方式，容器化消除了語言、庫和框架之間任何摩擦或衝突的風險。

在服務發現方面，容器化使微服務之間的定位和通信變得更加簡單，因為它們都運行在位於同一平台上的容器中。出於同樣的原因，開發人員編排微服務也更容易。

容器微服務方案

儘管有這些優勢，但容器和微服務都有其細微差別和挑戰，包括網絡安全問題。讓我們討論一些最重要的安全問題。

基於容器和微服務的應用程序的安全挑戰與任何其他方法一樣，容器和微服務都可能給應用程序開髮帶來某些安全挑戰。為了確保產品的良好網絡安全，了解最常見的安全風險併計劃如何預防和減輕它們至關重要。

具有微服務架構的容器化應用程序的安全挑戰

1、可被利用的漏洞一般來說，與微服務和容器相關的安全問題的討論已經轉移到編排平台的安全要求上。但是，並非所有安全風險都可以在編排級別處理。例如，必須密切關注可能被利用的漏洞。

1. 鏡像漏洞是基於微服務和容器的應用程序中最常見的安全威脅。它們通常來自不安全的庫或其他依賴項。易受攻擊的圖像本身不會構成主動威脅。但是，當容器基於易受攻擊的鏡像時，會將漏洞引入整個環境。

2. 應用程序漏洞可能來自應用程序源代碼中的缺陷。例如，如果您的某個應用程序存在緩衝區溢出漏洞，攻擊者可能會利用它執行惡意代碼並接管您的容器。

3. 網絡攻擊的脆弱性。基於微服務的應用程序比單體應用程序更複雜，因為它們由許多移動部件組成。一個應用程序可以包含數百個部署在數千個容器中的微服務。對於開發人員來說，這意味著具有1,000 個動態鏈接庫(DLL) 的單體代碼應該被分解為相同數量的微服務。它使基於微服務的應用程序很容易受到網絡攻擊，因為很難確保這麼多組件的適當安全性。

2、惡意軟件風險惡意軟件攻擊的可能場景包括：

马云惹不起马云 黑客可以訪問容器並向其中註入惡意代碼，這些代碼還可以攻擊該容器、其他容器或主機操作系統中的微服務。

马云惹不起马云惡意行為者會破壞您的CI/CD 環境並將惡意軟件注入用於構建容器映像的源代碼存儲庫中。

马云惹不起马云攻擊者破壞容器註冊表並用包含惡意軟件的圖像替換圖像。

马云惹不起马云黑客誘使開發人員從外部來源下載惡意容器映像。

惡意軟件的問題在於，如果您在啟動容器之前沒有檢測到它，惡意軟件將感染您在該容器內的微服務以及整個環境。例如，它可以收集敏感數據、阻止進程或中斷其他容器的工作。

3、代碼訪問風險可以訪問和更改代碼的人越多，出現的安全風險就越大。最常見的兩種是：

1.訪問權限太寬泛。許多開發公司選擇使用微服務和容器構建應用程序的DevOps 方法，因為它打破了團隊之間的障礙並確保了持續集成和持續部署(CI/CD)。但是，DevOps 可能會導致訪問權限過於寬泛，從而增加有人在分佈式工作環境中更改代碼的風險。

2.保密管理薄弱。如果安全實踐不佳或違反安全規則，更多人可以訪問容器。例如，開發人員可能會將腳本中的硬編碼憑證放入容器中，或者他們可能將機密存儲在配置不安全的密鑰管理系統中。

4、容器間無限制通信通常，容器不能訪問它們直接控制的環境之外的任何資源——這稱為非特權模式。工程師應該只允許容器之間正確的應用程序工作所必需的通信能力。例如，應用程序容器可能會連接到數據庫容器。

每當容器擁有比嚴格要求更多的權限時，它可能會導致額外的安全風險。由於缺乏經驗或編排器管理不善導致的錯誤配置，容器可能會獲得過多的權限。

5、安全地管理數據微服務架構的分佈式框架使得保護數據變得更具挑戰性，因為難以控制對單個服務的訪問和安全授權。因此，工程師必須更加關注他們的應用程序如何確保每個服務中的數據機密性、隱私性和完整性。

另一個問題是，微服務中的數據不斷移動、更改，並在不同的服務中用於不同的目的，這為惡意行為者創造了更多的數據入口點。

6、選擇和配置工具在開發和維護微服務架構時，DevOps 團隊使用了很多工具，包括開源和第三方。雖然此類工具可幫助工程師實現DevOps 管道所需的效率，但它們並不總是提供所需的安全性。

如果您不仔細評估計劃集成到環境中的開源工具的安全功能，您就有可能在微服務和容器中產生漏洞。即使一個工具看起來足夠安全，你在配置它的設置時仍然應該小心，並隨著時間的推移不斷評估工具的安全性。

選擇適當的安全措施來解決我們上面提到的風險可能具有挑戰性。原因是容器和微服務都對開發人員如此有吸引力，因為它們簡化和加速應用程序開發的方式。如果安全措施使開發方法變得更慢、更不直接，那麼它們很可能會被忽視或忽視。

為了幫助您在不犧牲網絡安全的情況下利用容器和微服務進行應用程序開發，我們收集了11 個有用的實踐。讓我們詳細探討如何保護微服務和容器。

本文介紹了基於容器和微服務的應用程序的安全挑戰，下一章節我們將講述保護微服務和容器的11 個最佳實踐。