隨著云計算技術的蓬勃發展,傳統上云實踐中的應用升級緩慢、架構臃腫、無法快速迭代等“痛點”日益明顯。能夠有效解決這些“痛點”的云原生技術正蓬勃發展,成為賦能業務創新的重要推動力,并已經應用到企業核心業務。然而,云原生技術在創造效益的同時,卻也面臨著嚴峻的安全問題,本文的主要內容是對云原生安全問題及防御技術做淺析。
注:CNCF對云原生的定義是“云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中,構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段,云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。”云原生技術正在蓬勃發展中,CNCF的云原生全景圖如圖1所示。
圖1 CNCF云原生全景圖
云原生環境面臨著嚴峻的安全風險問題。攻擊者可能利用的重要攻擊面包括但不限于:容器運行時、容器編排平臺、微服務架構Web應用、服務網格、Serverless。下面對這些重要的攻擊面進行梳理。
1.1 容器運行時
首先來看市場情況,據2020年的數據統計,Docker的市場占有率為50%(同比2019年下降逾29%),而CRI-O的市場占有率從4%上升到17%。
接著進行安全問題分析,以Docker為例進行容器運行時的安全問題分析,如表1所示。
表 1?容器運行時安全問題分析表
類別 | 案例 | 備注 |
針對容器鏡像的供應鏈攻擊 | 鏡像漏洞利用 | 如CVE-2019-5021,Alpine Docker鏡像漏洞 |
鏡像投毒 | 如惡意EXP鏡像、木馬鏡像 | |
容器逃逸 | 危險配置導致的容器逃逸 |
如利用特權容器逃逸 |
危險掛載導致的容器逃逸 | 如果容器或Pod在啟動時將宿主機的核心目錄以寫權限掛載(如/root, /proc, /etc等),則攻擊者進入容器后可修改敏感文件并逃逸 | |
相關程序漏洞導致的容器逃逸 |
攻擊者可能利用的Docker漏洞包括但不僅限于: (1)CVE-2019-5736(Docker runC容器逃逸漏洞) (2)CVE-2019-14271(Docker cp容器逃逸漏洞) (3)CVE-2019-15752(Docker host模式容器逃逸漏洞) |
|
內核漏洞導致的容器逃逸 |
攻擊者可能利用的Linux內核漏洞包括但不僅限于: (1)CVE-2016-5195(“臟牛”漏洞) (2)CVE-2018-18955(Linux user namespace內核提權漏洞) |
|
DDoS攻擊 | 未使用Linux的cgroups限制容器資源,致使DDoS攻擊生效 | 容器運行時在默認情況下未對容器內進程的資源使用進行限制,當同一個宿主環境下同時運行多個容器時,如果一個服務特別耗資源或者負載突然陡增時,其對資源的搶占往往會影響到同一個環境中其他服務的正常運行。 |
有研究團隊為了在輕量化和安全性之間達到較好的平衡,在“傳統容器”的基礎上,為“容器-主機”或“容器-容器”之間提供額外的保護,落地了“安全容器”。典型的“安全容器”技術包括了Kata、gVisor、Firecracker,但它們仍面臨著已知或未知的容器逃逸攻擊的風險。
1.2 容器編排平臺安全問題分析
首先來看市場情況,據2020年的數據統計,Kubernetes(簡稱K8s)的市場占有率為75%,而OpenShift從前一年的9%份額,提升到15%的份額(OpenShift以Docker作為容器引擎驅動,以K8s作為容器編排引擎組件)。由此可見,K8s已經成為目前業界容器編排的事實標準。
接著進行安全問題分析,以K8s為例進行容器編排平臺的安全問題分析,圖2為阿里云提出的“云上容器ATT&CK攻防矩陣”。由圖可知,黑客在攻擊K8s集群的過程中有很多手段,K8s集群的攻擊面較大。
圖 2 阿里云云上容器ATT&CK攻防矩陣
1.3 微服務架構Web應用安全問題分析
微服務Web應用在解決傳統單體應用不足之處的同時放大了攻擊面(如端口和東西流量均顯著增多),引入了安全隱患。比如,對于微服務Web應用,傳統單體應用所面臨的OWASP Top10等安全漏洞依舊存在,并且受到架構特點的影響,敏感信息泄露、失效的身份認證、失效的訪問控制等漏洞類型的風險愈加突出。
1.4 服務網格平臺安全問題
服務網格作為一種云原生應用的體系結構模式,應對了微服務架構在網絡和管理上的挑戰,也推動了技術堆棧分層架構的發展。從分布式負載均衡、防火墻的服務的可見性,服務網格通過在各個架構層提供通信層來避免服務碎片化,以安全隔離的方式解決了跨集群的工作負載問題,并超越了Kubernetes容器集群,拓展到運行在裸機上的服務。服務網格與微服務在云原生技術棧中是相輔相成的兩部分,前者更關注應用的交付和運行時,后者更關注應用的設計與開發。若未在服務網格中采用雙向TLS認證,服務間容易受到中間人攻擊。若未做東西向、南北向的認證鑒權,服務間容易受到越權攻擊。
1.5 Serverless安全問題
Serverless(無服務器運算)又被稱為函數即服務(Function-as-a-Service,縮寫為 FaaS),是云計算的一種模型。以平臺即服務(PaaS)為基礎,無服務器運算提供一個微型的架構,終端客戶不需要部署、配置或管理服務器服務,代碼運行所需要的服務器服務皆由云端平臺來提供,Serverless 使得底層運維工作量進一步降低,業務上線后,也無需擔憂服務器運維,而是全部交給了云平臺或云廠商。Serverless應用的示意圖如圖3所示。
圖 3 Serverless應用示意圖
與傳統的單體應用相似,Serverless應用容易受到典型的Web攻擊;此外,在這特殊的應用場景下,Serverless用戶可能會遭受DoW(Denial of Wallet)這類平臺賬戶的拒絕服務攻擊,從而蒙受經濟損失。
對于云原生安全問題的防御,業界提出了不同的實踐方法。例如,綠盟的安全研究人員認為應該踐行以下三項原則:
(1)安全左移:在云原生建設初期將安全投資更多地放到開發安全、包括安全編碼供應鏈(軟件庫、開源軟件)安全、鏡像安全;
(2)聚焦“不變”:容器對應的鏡像、文件系統都是不變的,由相同或繼承的鏡像啟動的容器進程及其行為是相似的,用于微服務的容器進程是少數且其行為是可預測的,可以通過學習進行畫像;
(3)業務安全:保護最貼近最終價值且處于最頂層的業務。
亦有字節跳動的安全研究人員指出應該重點通過互聯網的三大核心要素:計算、存儲、網絡開展防御工作,其觀點如下:
(1)容器安全的本質是對Linux Kernel安全機制的充分利用;
(2)eBPF技術將蓬勃發展,在syscall和網絡監控領域廣泛使用;
(3)動態防御的重點是采集、可視化、關聯分析和響應的全流程建設。
目前,騰訊安全已搭建了包含安全治理、數據安全、應用安全、計算安全、網絡安全等五個領域的完備云原生安全防護體系。
經過上述分析,可以發現“云原生安全”的治理需要綜合的解決方案。筆者認為在云原生安全防護體系的建設過程中應做好以下幾項工作:
(1)結合云原生技術的具體落地情況開展并落實最小權限、縱深防御工作
對于云原生環境中的各種組成部分,均可貫徹落實“安全左移”的原則,進行安全基線配置,防范于未然。而對于微服務架構Web應用以及Serverless應用的防護而言,其重點是應用安全問題,如表2所示。
表 2 云原生環境各組成部分防御方法梳理
安全問題來源 | 防御方法 |
容器運行時 |
代碼審計 鏡像掃描 鏡像加固 安全基線配置 |
容器編排平臺 | 安全基線配置 |
微服務架構Web應用 |
應用安全 微隔離(云原生防火墻、云原生應用防火墻模式) |
服務網格平臺 |
與WAF、API網關等機制進行聯動 安全基線配置 |
Serverless |
應用安全 安全基線配置 |
(2)圍繞云原生應用的生命周期來進行DevSecOps建設
以當前的云原生環境的關鍵技術棧“K8S + Docker”舉例進行分析,如圖4所示。應該在容器的全生命周期注重“配置安全”,在項目構建時注重“鏡像安全”,在項目部署時注重“容器準入”,在容器的運行環境注重云計算的三要素“計算”“網絡”以及“存儲”等方面的安全問題。
圖 4 圍繞云原生應用的生命周期構建安全防護體系
(3)圍繞攻擊前、中、后的安全實施準則進行構建
在實際落地時,可依據安全實施準則對攻擊前、中、后這三個階段開展檢測與防御工作。
表 3 對攻擊前、中、后這三個階段開展檢測與防御工作
攻擊前 | 攻擊時 | 攻擊后 |
資產清點 鏡像安全 基線合規 資產加固 |
鏡像運行控制 容器安全 網絡安全 運用K8S集群的安全機制 主機安全 |
日志審計 |
“攻擊前”階段工作
在檢測方面應注重的工作包括了資產清點和鏡像安全工作。資產清點的核心工作是資產版本比對。資產版本比對工作有助于防御工作的開展;在防御方面應注重的工作包括了基線合規工作和資產加固工作。基線合規工作有助于收斂暴露給外部的攻擊面。
“攻擊時”階段工作
在檢測方面應關注的檢測項可包括宿主機上與容器內的異常行為監控(Docker容器、微服務的功能一般是較為固化的,若發現文件、網絡、進程等方面的異常行為,應予以警惕;為了檢測這類異常行為,可運用現階段較為成熟的主機入侵檢測技術經驗并選擇合適的算法對宿主機與容器進行異常行為監控)以及容器準入工作的合規性;在防御方面應注重的工作可包括:在宿主機上以及容器內做文件權限控制以及在Docker宿主機充分利用Linux內核的安全能力(可選用的安全技術包括了:可做資源隔離的Namespace、可用黑白名單限定進程調用的Seccomp、可限定容器能力的Capability、可限定應用程序訪問控制權限的Apparmor)。
“攻擊后”階段工作
在檢測方面應注重操作日志審計。在具體實踐時,可通過日志收集容器將業務容器的日志統一發送到大數據平臺,進行分析、告警;在防御方面應注重應急響應。在具體實踐時,若發現生產環境受到了攻擊,應及時進行應急響應,提防危害擴大化。
(4)改造并綜合運用現有云安全技術
不應將“云原生安全”視為一個獨立的命題,為云原生環境提供更多支持的主機安全、微隔離等技術可賦能于云原生安全,如圖5所示。
圖 5 容器安全、主機安全與微隔離賦能云原生安全
云原生技術正逐步成熟,容器、微服務、聲明式API等代表技術的應用正逐步落地,生態正逐步健全。但云原生環境面臨著嚴峻的安全問題,安全技術亟待發展。預計在未來24-36個月內云原生安全技術將高速發展。
本文介紹了云原生安全問題及防御技術方法。經過比較可以發現,云原生安全技術與傳統的云安全技術有著異同。“云原生安全”的治理需要綜合的解決方案。在落地云原生安全技術時,可從以下幾個方面做考慮:單位的具體落地情況、云原生應用的生命周期、安全運維準則、對現有云安全技術的改造與綜合運用。
安全必須為業務服務。當業務需要現代化時,安全也要順勢而為進行變革,不要淪為業務的阻礙。在云原生時代,DevSecOps理念及產品將逐漸落地應用。云原生安全與信息基礎設施將深度融合,提供SECaaS 也將成為一大發展趨勢。
[1]?[綠盟 云原生安全技術報告]
https://www.nsfocus.com.cn/html/2021/92_0113/146.html
[2]?[字節跳動安全范兒沙龍——業務安全攻與防 / 容器安全與動態防御]
https://mp.weixin.qq.com/s/tdTDlZIftrI6xYoJl5fSlA
[3]?[騰訊 除了云原生,2021 年還有這八大趨勢值得關注]
https://xw.qq.com/cmsid/20201026A09M7B00
[4]?云上容器 ATT&CK 矩陣詳解,阿里云助力企業容器化安全落地
https://blog.csdn.net/csdnnews/article/details/106821667
[5]?《云原生服務網格Istio 原理、實踐、架構與源碼解析》(張超盟、章鑫、徐中虎、徐飛編著)
來源:FreeBuf.COM