在2000年代初期，隨著更強大的處理器出現，計算革命開始了，這也導致了我們現在所稱的雲端技術的誕生。單一的硬體設備能夠同時運行數十個，甚至數百個虛擬機器，這讓企業能夠為用戶提供多種服務和應用程式，這在過去是非常不切實際的，甚至是不可能的。
不過，虛擬機器（VMs）也有一些缺點。對於許多應用來說，整個虛擬化的作業系統可能過於繁瑣，雖然它比一整套實體伺服器更具彈性、可擴展性和靈活性，但虛擬機器仍然需要更多的記憶體和處理能力，並且比這類技術的下一個進化版本——容器要少一些靈活性。容器化的應用程式只包含應用程式及其支援依賴的必要部分，因此基於微服務的應用程式通常更輕便且更容易配置。
虛擬機器面臨的安全問題與實體伺服器相似，容器的安全問題在某種程度上也反映了其組成部分的問題：例如，某個版本的上游應用程式中的 mySQL 錯誤也會影響到容器化版本。關於虛擬機器、實體安裝和容器，網路安全的問題和活動非常相似。但是，容器的部署及其工具為負責運行應用程式和服務的人帶來了特定的安全挑戰，無論是手動將應用程式與選擇的容器拼湊在一起，還是以大規模的編排方式運行。
容器特有的安全風險
錯誤配置：複雜的應用程式由多個容器組成，錯誤配置——通常只是一行 .yaml 檔案中的錯誤，可能會授予不必要的權限並增加攻擊面。例如，雖然攻擊者從容器獲得主機的根存取權限並不簡單，但仍然有很多人習慣以根權限運行 Docker，且沒有用戶命名空間的重新映射。
易受攻擊的容器映像：在2022年，Sysdig 發現 Docker Hub 上有超過1,600個被標記為惡意的映像，此外還有許多存儲在庫中的容器包含硬編碼的雲端憑證、ssh 金鑰和 NPM 令牌。從公共註冊表中提取映像的過程並不透明，容器部署的便利性（加上開發者快速產出的壓力）可能意味著應用程式很容易構建出本質上不安全，甚至是惡意的組件。
編排層：對於較大的專案，像是 Kubernetes 這樣的編排工具可能會增加攻擊面，通常是由於錯誤配置和高複雜度。2022年 D2iQ 的調查發現，只有42%的在 Kubernetes 上運行的應用程式進入了生產階段，部分原因是管理大型叢集的難度和陡峭的學習曲線。
根據 Akamai 的 Ari Weil 的說法，「Kubernetes 已經成熟，但大多數公司和開發者並不知道它實際運行到規模時的複雜性。」
使用機器學習的容器安全
容器安全的特定挑戰可以透過機器學習算法來解決，這些算法會觀察應用程式在「正常運行」時的組件。透過建立正常行為的基準，機器學習可以識別異常情況，這些情況可能表明來自不尋常流量的潛在威脅、未經授權的配置變更、奇怪的用戶訪問模式和意外的系統調用。
基於機器學習的容器安全平台可以掃描映像庫，並將每個映像與已知漏洞和問題的數據庫進行比較。掃描可以自動觸發和排程，幫助防止在開發和生產過程中添加有害元素。自動生成的審計報告可以與標準基準進行跟蹤，或組織可以設定自己的安全標準——這在處理高度敏感數據的環境中特別有用。
專業容器安全功能與編排軟體之間的連接意味著，懷疑的容器可以立即被隔離或關閉，不安全的權限被撤銷，用戶訪問被暫停。透過與本地防火牆和 VPN 端點的 API 連接，整個環境或子網可以被隔離，或在網路邊界停止流量。
最後的話
機器學習可以通過多個層面降低容器環境中數據洩露的風險。異常檢測、資產掃描和標記潛在的錯誤配置都是可能的，任何程度的自動警報或改善措施都相對容易實施。
基於容器的應用程式的變革性可能性可以在不面臨安全問題的情況下進行探索，這些安全問題曾經阻止一些人開發和運行基於微服務的應用程式。即使在高風險行業中，也可以在不妥協現有安全標準的情況下獲得雲原生技術的優勢。
(圖片來源)
本文由 AI 台灣 運用 AI 技術編撰，內容僅供參考，請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團，
隨時掌握最新 AI 動態與實用資訊！
