容器是目前應用系統(tǒng)運行的常用環(huán)境，特別是對于復雜的應用系統(tǒng)，開發(fā)人員更喜歡使用基于容器的開發(fā)架構(gòu)，因為容器是輕量級的、可移植的，并且易于維護和擴展。由于這些特性，容器非常適用于現(xiàn)代開發(fā)模式，如DevOps、無服務器和微服務等。

開發(fā)人員可在容器中封裝了應用程序的輕量級運行時環(huán)境。因此，當在容器中開發(fā)微服務時，它繼承了容器化的優(yōu)點，如可移植性、可伸縮性和額外安全層等。同時，在單獨的容器中運行微服務，用戶可以獨立地部署它們，消除了語言、庫和框架之間的兼容性風險。在服務監(jiān)測方面，容器化使微服務更容易定位和相互通信，因為它們都運行在位于同一平臺上的容器中，開發(fā)人員將更容易編排微服務。

微服務和容器應用的安全挑戰(zhàn)

雖然基于容器的微服務開發(fā)應用方法有諸多好處，包括易于擴展和管理，但它們也同樣存在一些的安全問題。在服務開發(fā)之前，企業(yè)應該了解可能出現(xiàn)的網(wǎng)絡安全風險以及如何消除這些風險，將有助于創(chuàng)建可靠又安全的產(chǎn)品。

1. 可被利用的漏洞

一般來說，與微服務和容器相關的安全問題屬于應用編排平臺的整體安全需求中。但是，并非所有的安全風險都可以在業(yè)務流程中處理。比如說可能被利用的漏洞。

映像漏洞是基于微服務和容器的應用程序內(nèi)最常見的安全威脅。它們通常來自不安全的庫或其他依賴項。當容器基于不安全的映像時，就會將該漏洞威脅引入整個應用環(huán)境；

應用程序漏洞主要指應用程序的源代碼缺陷。比如某個應用程序中存在一個緩沖區(qū)溢出漏洞，攻擊者可能會利用它來執(zhí)行惡意代碼并接管容器；

網(wǎng)絡攻擊的漏洞?；谖⒎盏膽贸绦虮葌鹘y(tǒng)應用程序更復雜，因為它們由許多獨立部件組成。一個應用程序可以包括部署在數(shù)千個容器中的數(shù)百個微服務，這使得基于微服務的應用程序非常容易受到網(wǎng)絡攻擊，因為很難同時確保這么多組件的整體安全性。

2. 惡意軟件風險

惡意軟件的危害在于，如果企業(yè)在啟動容器之前沒有檢測到它，惡意軟件將感染此容器內(nèi)的微服務以及整個環(huán)境。惡意軟件攻擊帶來的安全風險主要包括：

黑客可以訪問一個容器并向其中注入惡意代碼，通過惡意代碼可以攻擊該容器、其他容器或主機操作系統(tǒng)中的微服務；

惡意攻擊者會危害企業(yè)的CI/CD環(huán)境，并將惡意軟件注入用于構(gòu)建容器映像的源代碼存儲庫；

攻擊者會破壞容器注冊表并替換包含惡意軟件的圖像；

攻擊者欺騙開發(fā)人員從外部來源下載惡意容器映像。

3. 與代碼訪問相關的風險

訪問和修改代碼的人越多，安全風險就越大，最常見的情況是：

訪問權(quán)限過大。許多開發(fā)公司選擇DevOps方法來使用微服務和容器構(gòu)建應用程序，這可能導致訪問權(quán)限過于寬泛，增加了在分布式工作環(huán)境中惡意修改代碼的風險。

機密管理薄弱。在安全實踐不佳或違反安全規(guī)則的情況下，很多人可以訪問容器。例如，開發(fā)人員可能將腳本中編碼的憑證放入容器中，或者將憑證存儲在配置不安全的密鑰管理系統(tǒng)中。

4. 容器間的通信不受限制

通常情況下，容器不能訪問外部任何資源，這被稱為非特權(quán)模式。工程師應該只允許保障應用系統(tǒng)正常工作所必需的容器間通信。每當容器的通信權(quán)限超過嚴格要求時，它可能會導致額外的安全風險。由于缺乏經(jīng)驗或管理不當而導致的錯誤配置，會讓容器獲得過多的特權(quán)。

5. 不安全的數(shù)據(jù)管理

微服務體系的分布式框架使得數(shù)據(jù)安全管理更具挑戰(zhàn)性，因為很難控制對單個服務的訪問和安全授權(quán)。因此，工程師必須更加關注如何確保每個服務內(nèi)數(shù)據(jù)的機密性、隱私性和完整性。另一個問題是，微服務中的數(shù)據(jù)不斷地移動、更改，并在不同的服務中用于不同的目的，這為攻擊者創(chuàng)建了更多的數(shù)據(jù)竊取攻擊點。

6. 錯誤配置工具

在開發(fā)和維護微服務架構(gòu)時，DevOps團隊需要使用大量工具，包括開源和第三方工具。雖然這類工具幫助工程師實現(xiàn)DevOps管道所需的效率，但它們很難保證所需要的安全性。

如果不能準確評估開源工具的安全功能，企業(yè)就有可能在微服務和容器中創(chuàng)建漏洞。即使一個工具本身是安全，如果沒有正確設置，也會出現(xiàn)很多安全問題。

微服務和容器安全防護最佳實踐

如何選擇適當?shù)陌踩胧﹣響獙ι厦嫣岬降娘L險可能是一個挑戰(zhàn)。究其原因，容器和微服務都是因為它們應用的簡潔性和快捷性而對開發(fā)人員具有如此大的吸引力。如果安全措施使開發(fā)流程變得緩慢和復雜，那么就很可能會被開發(fā)人員所抵觸或故意忽視。為了幫助企業(yè)在安全的情況下高效利用容器和微服務進行應用系統(tǒng)開發(fā)，本文收集整理了10種有用的最佳實踐。

1. 創(chuàng)建不可變?nèi)萜?/p>

開發(fā)人員往往保留通過shell訪問映像的途徑，以便修復生產(chǎn)環(huán)境中的映像。然而，攻擊者常利用這條途徑來注入惡意代碼。要避免這種情況，可以創(chuàng)建不可變?nèi)萜?。不可變?nèi)萜鳠o法被改動。如果用戶需要更新應用程序代碼、打補丁或更改配置，可以重新構(gòu)建映像并重新部署容器。如果用戶需要撤回更改，只需重新部署舊映像。需要注意的是，容器的不可變特性會影響到數(shù)據(jù)持久性。開發(fā)人員應該將數(shù)據(jù)存儲在容器外面，這樣容器被替換時，所有數(shù)據(jù)仍可供新版本使用。

2. 將自動安全測試集成到CI/CD過程中

有各種工具可以在CI/CD過程中自動測試容器。比如說，HP Fortify和IBM AppScan提供動態(tài)和靜態(tài)應用程序安全測試。還可以使用JFrog Xray和Black Duck等掃描器實時檢查容器中已知的漏洞。一旦這類工具發(fā)現(xiàn)了漏洞，就會將檢測到有問題的部分標注出來，以便檢查和修復。

3. 避免使用特權(quán)容器

如果容器在特權(quán)模式下運行，它就可以訪問主機上的所有組件。如果這種容器被破壞，攻擊者可以全面訪問服務器。因此，應該考慮盡量避免使用特權(quán)容器。比如在Kubernetes中，可以使用策略控制器（Policy Controller）禁止特權(quán)容器。

如果出于某種原因需要使用特權(quán)容器，谷歌云架構(gòu)中心提供了幾個替代方案：

通過Kubernetes的securityContext選項為容器提供特定的功能

在sidecar容器或init容器中修改應用程序設置

使用專用注釋修改Kubernetes中的sysctls接口

4. 建立可信映像庫

開源社區(qū)會為開發(fā)人員提供許多具有容器的開源軟件包。但是出于安全目的，開發(fā)者需要知道容器的來源、更新時間以及它們是否含有漏洞和惡意代碼。最好建立可信映像庫，只從這個可信源運行映像。如果想使用其他來源的映像，建議首先使用掃描工具掃描映像。此外，在將容器部署到生產(chǎn)環(huán)境之前，開發(fā)人員應檢查腳本中的應用程序簽名。如果在多個云環(huán)境中運行容器，需要建立多個安全映像存儲庫。

5. 使用注冊中心管理映像

Docker Hub、Amazon EC2 Container Registry和Quay Container Registry等注冊中心可以幫助開發(fā)人員存儲和管理已創(chuàng)建的映像?？梢允褂眠@些注冊中心執(zhí)行以下操作：

提供基于角色的訪問控制

指定容器的可信源

創(chuàng)建和更新已知漏洞列表

標注易受攻擊的映像

基于角色的訪問控制非常重要，因為需要控制誰可以改變?nèi)萜?。最好將訪問權(quán)限分開到不同的管理帳戶：一個負責系統(tǒng)管理，另一個負責操作和編排容器。要記住的另一點是，應該確保注冊中心驗證每個容器的簽名，只接受來自可信源的容器。此外，需要充分利用幫助不斷檢查映像內(nèi)容查找已知漏洞，并報告安全問題的功能。

6. 加固主機操作系統(tǒng)

保障微服務和容器的應用安全，有必要確保主機操作系統(tǒng)的安全。

首先，建議企業(yè)使用針對特定容器的主機操作系統(tǒng)（明確旨在只運行容器的簡版主機操作系統(tǒng)），因為它們沒有不必要的功能，因而攻擊面比通用主機系統(tǒng)小很多。

其次，CIS Docker Benchmark提供了加固系統(tǒng)的核對列表，主要的建議如下：

建立用戶身份驗證

設置訪問角色

指定二進制文件訪問權(quán)限

收集詳細的審計日志

為了避免數(shù)據(jù)泄露，應該限制容器對底層操作系統(tǒng)資源的訪問，并將容器彼此隔離。一個好的做法是在內(nèi)核模式下運行容器引擎，同時在用戶模式下運行容器。比如說，Linux提供了Linux命名空間、seccomp、cgroups和SELinux等技術(shù)，從而安全地構(gòu)建和運行容器。

7. 用縱深防御方法保護微服務

縱深防御可以結(jié)合多種安全機制和控制措施，比如殺毒軟件、防火墻和補丁管理，以保護網(wǎng)絡和數(shù)據(jù)的機密性、完整性和可用性。

縱深防御方法的三大層是：

物理控制——用于物理限制用戶訪問IT系統(tǒng)，比如安保系統(tǒng)和閉路電視系統(tǒng)

技術(shù)控制——旨在保護系統(tǒng)和資源的軟硬件

管理控制——通過各種策略和程序，以確保組織關鍵基礎設施的網(wǎng)絡安全性

縱深防御方法是確保微服務安全的最重要原則之一，因為它創(chuàng)建了多層安全以防止攻擊。它包括下列安全措施：過濾傳輸?shù)臄?shù)據(jù)流、驗證和授權(quán)對微服務的訪問以及使用加密技術(shù)等。要確保內(nèi)部環(huán)境不受任何外部連接的影響，因為這是安全防護的基礎。

8. 嚴格控制API訪問

API是微服務應用程序的關鍵，很多軟件都會有多個獨立的API服務。因此，確保安全身份驗證和授權(quán)的API訪問控制對于微服務安全至關重要。當API服務訪問敏感數(shù)據(jù)時，應該需要提供驗證令牌，令牌要經(jīng)過數(shù)字簽名或得到權(quán)威來源的驗證。開發(fā)人員和管理員可以使用OAuth/OAuth2服務器來獲取令牌，以便通過API訪問應用程序。出于安全考慮，還應該使用傳輸層安全（TLS）加密來保護所有客戶機/服務器通信。

9. 原生化容器檢測工具

持續(xù)性監(jiān)測容器的運行很有必要，因為它可以幫助用戶：

深入了解容器度量指標和日志

了解集群、主機以及容器內(nèi)部正在發(fā)生的情況

做出更明智的安全運營決策

然而要確保有效的監(jiān)視，最好使用容器原生監(jiān)視工具。比如在使用Docker時，開發(fā)人員通常使用Docker Security Scanner或其他專門設計的工具來檢測任何潛在威脅。監(jiān)視工具會先收集事件，然后對照設置好的安全策略加以對比分析和檢查。

10. 使用服務編排管理器

服務編排是個復雜的過程，可使微服務和容器的部署、管理、擴展和連接實現(xiàn)自動化。編排器負責從注冊中心提取映像，將這些映像部署到容器，并管理容器運行。編排器提供的抽象讓用戶可以指定運行某個映像所必需的容器數(shù)量，以及需要為它們分配哪些主機資源。

如果使用編排管理器，不僅可以自動部署微服務，還可以確保一定級別的安全。比如說，編排器便于管理容器集群、隔離工作負載、限制對元數(shù)據(jù)的訪問以及收集日志。許多編排管理器還有內(nèi)置的機密數(shù)據(jù)管理工具，允許開發(fā)人員安全地存儲和共享機密數(shù)據(jù)，比如API和SSL證書、加密密鑰、身份令牌和密碼。

更多信息可以來這里獲取==>>電子技術(shù)應用-AET<<