隨著云原生進入快速發展期，越來越多的企業步入云原生化進程，但傳統基于邊界的防護模型已不能完全滿足云原生安全的需求，基于安全“左移”原則的DevSecOps應運而生，將從DevOps全流程為企業的業務系統注入安全風險免疫能力。

云原生時代的安全新機遇

云原生技術實踐聯盟（CNBPA）在近日發布的《第四期（2021-2022）傳統行業云原生技術落地調研報告——金融篇》中指出：安全“左移”——云原生安全策略成 2022 金融科技新焦點。

?發送關鍵詞【金融云原生落地調研】至靈雀云公眾號，立即下載完整報告

以容器、微服務、服務網格為代表的云原生技術正在被廣泛使用，重塑了云端應用的設計、開發、部署和運行模式，實現了自動化、易管理、可觀測的全新DevOps體系，使開發者和運維人員能夠最大限度地提高生產力，更敏捷、更高效、更安全地進行應用迭代。

然而，云原生給業務帶來敏捷積極影響的同時，也帶來了全新的安全挑戰：

·?以容器為載體的云原生應用實例極大地縮短了應用生命周期；

·?微服務化拆分帶來應用間交互式端口的指數級增長以及組件間設計復雜度的陡升；

·?多服務實例共享操作系統帶來了單個漏洞的集群化擴散風險；

談及云原生安全，不少人還停留在傳統安全意識和觀念，關注Web攻防、系統攻防、密碼暴力破解等。然而，安全總是具有“短板效應”，有時，一個簡單的端口暴露、未授權訪問沒及時處理就為攻擊者提供了不費吹灰之力長驅直入的機會。

此外，云原生技術架構帶來的風險，在未來數年內，可能會成為攻擊者關注和利用的重點，進而發動針對云原生系統的攻擊。傳統基于邊界的防護模型已不能完全滿足云原生的安全需求，這就要求我們必須探索出一條更適合云原生時代的持續安全之路。

避坑指南：云原生安全風險一覽

眾所周知，只有通過全面了解云原生面臨的安全風險，才能夠更精準、更快速地搭建更可靠的云原生安全防護模型。以下就是備受大家關注的六大云原生安全風險，來看看你入坑了嗎？

1. 容器網絡安全風險

網絡的細粒度劃分增加了訪問控制和分離管控難度。

云原生環境下，服務細粒度劃分，業務依賴關系復雜，如果容器網絡層不能跟隨業務關系實現細粒度訪問控制策略，就會帶來權限放大風險。比如：無需被外網訪問的業務被默認設置了外網訪問權限、容器網絡可以無限制的訪問宿主機節點的下層網絡等，攻擊者將利用這些漏洞，獲取權限外甚至核心系統的訪問控制權限，實現越權甚至提權攻擊。

此外，云原生網絡既有東西向流量、又有南北向流量，服務間流量訪問頻繁；且多服務實例共享操作系統，一個存在漏洞的服務被黑客攻陷將會導致同一宿主機上的其他服務受影響，如果Pod、ns之間、沒有做好網絡隔離策略，外部攻擊就能從高風險實例逃逸，伴隨東西向流量在集群網絡內部的實例間進行橫向攻擊，致使威脅在集群內擴散。比如：有些容器平臺采用underlay模式網絡插件，使得容器IP與節點IP共享同一網絡平面，在業務IP最終暴露給最終用戶同時，管理控制臺會面臨被入侵的風險。

2. 編排及組件安全風險

云原生編排組件存在漏洞及管控風險增加入侵概率。

首先，非法提權暗含潛在安全隱患，如果普通用戶獲得管理員權限或者Web用戶直接提權成管理員用戶，編排工具可能存在多種漏洞導致此類攻擊。比如：如果系統中存在一個K8s的提權漏洞，允許攻擊者在擁有集群內低權限的情況下提升至K8s api server的權限；通過構造一個對K8s api server的特殊請求，攻擊者就能以K8s api server身份向后端服務器發送任意請求，實現權限提升。

其次，編排工具組件眾多、各組件配置復雜，配置復雜度的提升增加了不安全配置的概率，而不安全配置引起的風險不容小覷，可能會導致編排工具中賬戶管理薄弱，或部分賬戶在編排工具中享有很高特權，入侵這些賬戶可能會導致整個系統遭到入侵。

再者，容器在默認狀態下并未對容器內進程的資源使用國值做限制，以Pod為單位的容器編排管理工具也是如此。資源使用限制的缺失，導致環境面臨資源耗盡的攻擊風險，攻擊者可以通過在容器內運行惡意程序，或對容器服務發起拒絕服務攻擊占用大量宿主機資源，從而影響宿主機和宿主機上其他容器的正常運行。

3. 鏡像安全風險

鏡像構建部署過程不規范引入安全風險。

首先，在傳統模式中，部署的軟件在其運行的主機上“現場”更新；與此不同，容器則必須在上游的鏡像中進行更新，然后重新部署。因此，容器化環境的常見風險之一就是用于創建容器的鏡像版本存在漏洞，從而導致所部署的容器存在漏洞。

其次，鏡像配置不當可能會讓系統面臨攻擊危險，例如，鏡像未使用特定用戶賬號進行配置導致運行時擁有的權限過高；鏡像含SSH守護進程導致容器面臨不必要的網絡風險等。

此外，鏡像及容器技術一個主要的特點就是方便移植和部署，云原生用戶可以將符合OCI標準的第三方鏡像輕松部署到自己的生產環境中。因此，攻擊者可將含有惡意程序的鏡像上傳至公共鏡像庫，誘導用戶下載并在生產環境中部署運行，從而實現其攻擊目的。

4. 鏡像倉庫安全風險

鏡像倉庫模式增加云原生軟件供應鏈風險來源。

首先，鏡像倉庫安全風險主要涉及倉庫賬號及其權限的安全管理、鏡像存儲備份，傳輸加密、倉庫訪問記錄與審計等，這些方面如果存在加固或配置策略不足的問題，就可能導致鏡像倉庫面臨鏡像泄露、篡改、破壞等風險。例如，垂直越權漏洞，因注冊模塊對參數校驗不嚴格，導致攻擊者可以通過注冊管理員賬號來接管Harbor 鏡像倉庫，從而寫入惡意鏡像。實際使用中，用戶往往會將鏡像倉庫作為有效且獲得批準的軟件源，因此，鏡像倉庫遭到入侵將極大增加下游容器和主機的被入侵風險。

除此之外，鏡像倉庫面臨的另一個重要安全問題就是保證容器鏡像從鏡像倉庫到用戶端的完整性。如果用戶以明文形式拉取鏡像，在與鏡像倉庫交互的過程中極易遭遇中間人攻擊，導致拉取的鏡像在傳輸過程中被篡改或被冒名發布惡意鏡像，則會造成鏡像倉庫和用戶雙方的安全風險。

5. 運行時安全風險

容器特性增加了容器運行時逃逸風險和威脅范圍。

首先，用戶可以通過修改容器環境配置或在運行容器時指定參數來縮小或擴大約束。如果用戶為不完全受控的容器提供了某些危險的配置參數，就為攻擊者提供了一定程度的逃逸可能性，包括未授權訪問帶來的容器逃逸風險，特權模式運行帶來的容器逃逸風險。

其次，將宿主機上的敏感文件或目錄掛載到容器內部，尤其是那些不完全受控的容器內部，往往會帶來安全問題。在某些特定場景下，為了實現特定功能或方便操作，人們會選擇將外部敏感卷掛載入容器。隨著應用的逐漸深化，掛載操作變得愈加廣泛，由此而來的安全問題也呈現上升趨勢。例如：掛載Docker Socket、掛載宿主機進程文件系統引入的容器逃逸風險等。

再者，相關程序漏洞，指的是那些參與到容器生態中的服務端、客戶端程序自身存在的漏洞。例如 CVE-2019-5736 正是這樣一個存在于runC 的容器逃逸漏洞。

更重要的一點是，容器的內核和宿主機共享，且容器技術本身建立在Linux Namespace和Linux Cgroups兩項關鍵技術之上，所以Linux內核本身所產生的漏洞會導致容器逃逸。Linux 內核漏洞危害極大、影響范圍極廣，是各種攻防話題下不可忽視的一環。近年來，Linux 系統曝出過不少存在提權隱患的內核漏洞，典型的就是臟牛漏洞（DirtyCOWCVE-2016-5195）。

6. 新用云形態帶來新的安全風險

隨著企業數字化轉型進程的不斷深化，IT架構從以傳統數據中心為核心向以云計算為承載轉變，多云、混合云、分布式云成為主要形態，以數據中心內部和外部進行劃分的安全邊界被打破，IT架構面臨更多安全信任危機。

這方面的風險主要包括：資源暴露面增大，工作負載可信程度難以保證；分布式應用架構導致東西流量激增，默認可信的風險大；數字化工作空間擴展，終端和身份可信狀況都需要把控。

DevSecOps：更讓企業放心的云原生安全防護模型

在新技術、新生態、新業務、新市場需求的不斷沖擊下，企業對業務應用的要求變成了“更快的迭代速度、更高的服務質量、以及更強的安全性”，企業安全開發運維模式逐漸向更敏捷、更穩健、更安全的DevSecOps新模式轉型。在“Everything Shift Left”的大背景下，DevSecOps則完美地滿足了當前企業敏捷安全開發運維的需求趨勢，能夠有效防范上述安全風險，被廣泛認為是云原生時代更讓企業放心的安全防護模型。

首先，在進行云原生安全防護模型時，企業應該遵循安全“左移”設計原則。所謂安全“左移”，即盡量早地暴露安全問題從而減小被攻擊面，越早發現問題就能用越小的成本去規避安全風險，將云原生安全管控融入到 DevOps的全流程中，從開發到上線全生命周期覆蓋。

比如：在上線前的開發過程中，可以先進行代碼安全掃描、以及黑盒、灰盒測試；在構建鏡像倉庫后，進行鏡像深度掃描、鏡像簽名類工作；在上線后，進行容器配置檢查、監控容器運行時的異常行為；通過早期定位安全問題，提前進行排查，最終減少攻擊面和潛在的運行風險。

在安全“左移”原則基礎之上，我們可以從以下4個維度，進一步構建基于DevSecOps的云原生安全架構模型：

·?基礎設施安全：主要是IaaS層的安全，包括計算安全、網絡安全、存儲安全等。

·?云原生計算環境安全：在鏡像安全方面，針對鏡像安全風險可以進行鏡像掃描、鏡像簽名、敏感信息掃描，針對鏡像及鏡像傳輸過程中的安全，可以進行鏡像倉庫訪問控制、鏡像倉庫安全通信等；在運行時安全方面，可以進行容器運行時異常行為分析，如發生敏感掛載等問題時可以進行有效監控，并及時做出容器隔離等安全響應；在編排及組件安全方面，可以增加CIS等安全基線掃描、針對K8s集群的漏洞掃描、敏感信息加密、訪問控制、對命名空間之間、Pod之間的資源隔離與限制；在容器網絡安全方面，可以制定和主機或外部服務之間的訪問控制策略、更細粒度的網絡隔離、以及網絡入侵行為的監控。

·?云原生應用開發運營安全：在微服務安全方面，可以進行微服務的API安全治理、微服務之間的訪問控制和安全通信；在研發運營安全方面，要更關注安全設計、代碼安全、制品安全，同時可以進行靜態應用測試、動態應用測試、交互式應用測試，盡早規避安全風險，并進行運行時安全配置；在數據安全方面，可以通過數據加密、數據備份、數據脫敏，來保障安全性。

·?安全管理：在整體云原生平臺構建以及K8s集群管理過程中，企業還應該關注安全審計、用戶權限管理、安全策略、監控管理、密鑰管理等一系列相關配置。

在實踐方面，以某全國性大型銀行為例，該銀行全棧云容器平臺作為驅動金融數字基礎設施建設的重要引擎，通過建立上述安全“左移”的云原生安全防護模型，踐行安全可靠的DevSecOps理念，實現了企業級的全生命周期自適應安全、IT系統智能化檢測、可靠的容器安全管理、敏捷化DevSecOps流程、零信任安全風險評估，大大提升了其業務系統的安全風險免疫能力，構筑了強大的云原生安全防線。

點擊此處，詳細了解靈雀云如何幫助您的企業提升應對IT風險的免疫力，與靈雀云工程師一起規劃探討，云原生安全最佳實踐。

總結

以上是生活随笔為你收集整理的DevSecOps：云原生安全风险“避坑”指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。