容器徹底改變了開發過程，是DevOps行動的基石，但容器帶來了複雜的安全風險，而這些風險並不總是那麼明顯。不降低這些風險的組織很容易受到攻擊。

本文概述了容器是如何促進敏捷開發的，容器帶來了那些獨特的安全風險，以及企業可以怎麼做來保護容器的工作負載，超越DevOps來實現DevSecOps。

容器在很多方面都是虛擬化的演進，用來加快開發過程，建立從開發到測試和實施的更敏捷的路線，這種方法比使用成熟的虛擬機器更輕量級。

這個問題的核心是應用程式相容性，因為應用程式需要某些版本的庫，可能與其他應用程式的要求發生衝突。容器解決了這個問題，並且恰好可以與開發流程和驅動這些流程的管理基礎設施很好地聯絡起來。

容器透過將虛擬化提升到一個新的層次來完成它們的工作。虛擬化抽象了硬體層，而容器抽象了作業系統層，本質上虛擬化了作業系統的角色。容器化的工作原理是將應用程式打包到“容器”中，其中包含了使應用程式執行所需的所有庫，同時使應用程式之間互不知曉，因為每個應用程式都認為它擁有自己的作業系統。

從功能上講，容器非常簡單。容器只是一個文字檔案，其概述了例項中包含哪些元件。容器的這種簡單性和更輕量級的特性使得在整個開發生命週期中進行部署和使用自動化(編制)工具變得容易。

容器有能力顯著提高開發效率，這可能是容器如此廣泛流行的主要原因之一。據Gartner估計，到2023年，70%的組織將執行容器化工作負載。

過去，開發、測試和部署應用程式的過程充滿了障礙，開發人員和負責基礎設施的團隊之間經常來回反覆。今天，透過使用容器，開發人員可以在一個有效的環境中構建和測試，並且只需將完成的程式碼與定義該環境的規範一起釋出。

在操作方面，團隊只需執行此規範即可建立一個可供使用的匹配環境。

所以，DevOps意味著快速發展。但是缺少一個元件：安全性。這就是為什麼我們越來越多地聽到DevSecOps從DevOps演變而來的原因，因為開發人員已經注意到，僅憑DevOps模型不足以解決安全問題。

容器簡化了開發過程，但在安全性方面引入了複雜性。當您將整個操作環境緊密地封裝到一個容器中，只是為了廣泛地分發它時，同時也會增加攻擊面併為不同的攻擊向量開啟了大門。與容器一起打包的任何易受攻擊的庫都會將這些漏洞傳播到無數工作負載中。其中的風險包括：

1. 供應鏈攻擊

惡意攻擊者不是透過影響應用程式，而是透過修改與應用程式一起提供的包或元件來發起攻擊。因此負責開發的團隊需要檢測其正在開發的應用程式及容器配置作為依賴項引入的庫的安全性。可以用到的自動化工具如SAST、SCA等，可以協助開發人員及時發現程式碼安全漏洞及開源元件成分中的風險隱患。

2. 啟用容器的其他工具

容器安全的風險還涉及啟用容器的工具，從 Docker到Kubernetes等編排工具。因為這些工具需要被監控和保護。例如，不允許系統管理員以root身份執行Docker容器。同樣，需要密切保護容器登錄檔，以確保它們不會受到損害。

與容器相關的一些安全風險比其他風險更不明顯。每個容器都需要訪問核心——畢竟，容器只是一種高階程式隔離。但是很容易忽略這樣一個事實:所有的容器都依賴於同一個核心——容器內的應用程式彼此隔離並不重要。

應用程式在容器中看到的核心與主機所依賴的核心是相同的。這帶來了一些問題。如果支援容器的主機上的核心容易被利用，則可以透過從容器內的應用程式啟動攻擊來利用此漏洞。

因此，意味著必須迅速修補有缺陷的核心，否則所有容器都可能很快受到漏洞的影響。

因此，使主機的核心保持最新是確保容器操作安全的重要一步。不僅需要修補核心，應該修補容器中引入的庫。但是，正如我們所知，持續修補說起來容易做起來難。這可能就是為什麼一項研究發現所分析的容器中有75%的缺陷被歸類為嚴重或高風險的漏洞。

例如，這些漏洞可能導致爆發攻擊，攻擊者依賴容器內有缺陷的庫來在容器外執行程式碼。透過破壞一個容器，攻擊者最終可以到達他們的預期目標，無論是主機系統還是容器中的其他應用程式。

在容器的上下文中，維護安全的庫可能是一件非常頭痛的事情，這需要有人跟蹤跟蹤新漏洞以及已修補和未修補的漏洞。

當涉及到資訊保安時，尖端技術通常會引入新的複雜性。新的工具通常會導致新的漏洞利用。對於容器也是如此，雖然它不會削弱在工作負載中使用容器的整體價值，但需要密切關注容器帶來的風險。

瞭解容器安全性中常見缺陷及緩解缺陷的實踐。除了打補丁，透過採取正確的方法來減少網路安全漏洞和缺陷有助於保護企業網路安全。

文章來源：

在DevOps中容器發揮很大作用，但也要注意安全風險

相關文章