DevSecOps：雲原生安全風險“避坑”指南
隨著雲原生進入快速發展期，越來越多的企業步入雲原生化程序，但傳統基於邊界的防護模型已不能完全滿足雲原生安全的需求，基於安全“左移”原則的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流程、零信任安全風險評估，大大提升了其業務系統的安全風險免疫能力，構築了強大的雲原生安全防線。