從重大漏洞應急看雲原生架構下的安全建設與安全運營（上）
前言
近年來，雲原生架構被廣泛的部署和使用，業務容器化部署的比例逐年提高，對於突發重大漏洞等0day安全事件，往往給安全的應急帶來重大的挑戰。例如前段時間廣受影響的重大漏洞的爆發，可以說是雲原生架構下安全建設和安全運營面臨的一次大考。
本文將以該高危任意程式碼執行漏洞作為案例，分享雲原生架構下的安全建設和安全運營的思考。
漏洞處置回顧
漏洞爆發後，第一時間關注的一定是攻擊者能否利用漏洞攻擊業務系統，可以通過哪些方式實施攻擊。對於容器環境，從攻擊視角來看，通常可以有以下幾種入侵途徑。
圖1
1）通過容器主機實施攻擊。這種通常是由於主機配置問題引起，例如對公網開放並且未開啟認證的Docker RemoteAPI，或者是未開啟認證的Kubernetes API Server。
2）通過脆弱的容器實施攻擊。這種類型攻擊主要以容器環境中部署應用程式的脆弱性作為攻擊突破口。
3）通過投毒的鏡像實施攻擊。主要通過對公共倉庫中的鏡像進行投毒，當鏡像被拉取運行時，即可執行相關的攻擊操作。
攻擊者可以做什麼？
本次log4j2漏洞的影響，主要是體現在第二種攻擊方式上，也就是攻擊者會通過受影響的應用程式，利用漏洞對容器化的應用實施攻擊。
一旦第一步漏洞利用成功，接下來就會按照通常的滲透攻擊邏輯，一方面在主機執行惡意程式；另一方面通過橫向移動，擴大攻擊範圍，這裡的橫向移動既會涉及主機層面的容器逃逸，也包括東西向網路層面的移動攻擊。
如何快速響應處置？
雲原生架構下，在漏洞的應急響應上，總體思路和傳統安全事件的應急是一致的。首先需要對漏洞的原理以及可能被利用的方式進行分析，確定修復和緩解方案，同時制定相關安全產品的防護規則，實現對漏洞利用的檢測和攔截，最後就是有條不紊的進行漏洞的修復和處置。
在容器環境中，具體可以梳理出如下的一些關鍵操作步驟：
-
首先，需要確定現有業務的受影響範圍。例如：確定倉庫中所有受漏洞影響的鏡像，確定受影響的線上業務；
-
其次，升級相關安全產品的防護策略。例如通過WAF規則以及防火牆規則等實現對漏洞利用的攻擊進行一定程度的暫時性攔截；必要時升級運行時檢測策略，一旦入侵成功，可以快速的發現並進行處置。
-
最後，就是修復漏洞，升級到官方發布的修復版本。
為什麼不容易
安全應急或者安全運營的效率，很大程度上依賴安全能力的建設。上述處置步驟，相對來說是理想情況下的一種處置流程，或者是需要在一套完善的安全能力建設基礎之上才可以輕鬆實施的處置流程。
根據騰訊雲在2021年11月份發布的《騰訊雲容器安全白皮書》顯示，當前雲原生用戶在安全能力的建設上可謂是參差不齊，像鏡像漏洞掃描、主機安全加固以及集群監控審計等基礎安全能力，落地部署的比例也僅僅只有50%左右，甚至有7%的用戶在雲原生的使用時沒有任何安全能力的部署。
圖2
因此，在這樣的現狀下，面對log4j2這樣的0day漏洞，在應急處置上，難免會出現各種捉襟見肘的問題。
控制影響範圍
對於漏洞的處置，首先就是控制漏洞影響範圍。因為漏洞的修復需要一定的時間周期，像log4j2這種使用範圍如此之廣的組件，甚至有預測，漏洞影響將會持續很長一段時間，因此控制新的影響資產增加也是十分重要的。
這裡主要體現在兩個方面：
（1）防止包含漏洞鏡像的入庫。CI集成以及鏡像入庫等階段，需要嚴格進行安全檢查，防止漏洞的引入。
（2）防止包含漏洞鏡像的運行。在新的服務啟動運行時，需要檢測相關鏡像是否包含漏洞，對於未通過安全檢測的鏡像，要嚴格阻止其啟動運行。
怎麼確定受影響範圍
1）識別所有受到漏洞影響的鏡像
在確定業務的受影響範圍時，如果部署了容器鏡像安全掃描的能力，安全廠商通常會在第一時間更新漏洞庫或檢測規則，用戶可以直接通過對鏡像倉庫的所有鏡像進行掃描發現受影響的鏡像。
如果沒有部署鏡像安全掃描，騰訊雲容器安全服務提供7天的免費試用，用戶可以通過其中的鏡像掃描功能，對鏡像資產進行排查。最差情況下，用戶可以使用開源的鏡像掃描工具（例如Clair/Anchore/Trivy等）進行問題排查，但是有一點需要注意，使用開源工具前，要確保漏洞庫或者檢測規則已經包含了對目標漏洞的檢測。
2）識別受影響的運行工作負載
當確定了受影響的鏡像後，就需要根據這個列表確定受影響的線上業務。假如我們的日常安全運營做的足夠完善，理論上這個列表跟受影響的業務列表應該是一致的。或者是我們需要部署相應的安全能力，實現鏡像資產到線上業務資產的映射。
假如這些都沒有的話，就需要逐個集群的檢索當前使用的鏡像，判斷其是否受到影響，例如可以使用「kubectl describe pods –all-namespaces| grep image」這種最粗暴的指令獲取集群運行業務所使用的所有鏡像。
到這裡我們發現，如果倉庫中鏡像的數量太多，其實也可以採用另一種思路，先使用類似「kubectl describe pods –all-namespaces| grep image」這樣的命令，逐個集群查詢到所有線上業務使用的鏡像，然後對於這些鏡像定向的進行漏洞檢測。
怎麼修復
面對漏洞的爆發，所有人都希望能充分了解這個漏洞，並在第一時間使用對應的修補程式解決問題。不幸的是：一方面，軟體開發和測試需要時間周期，漏洞的修復不會那麼快；另一方面，在微服務架構下，受影響的鏡像可能會非常多，這同樣給漏洞的修復帶來很大的挑戰。
因此，在漏洞修復的同時，我們可以通過建議的緩解措施進行緩解，例如，對於log4j2漏洞，可以添加jvm啟動參數：
-Dlog4j2.formatMsgNoLookups=true進行暫時的緩解。
但是，在雲原生架構下，應用程式的啟動命令以及運行參數等資訊，都是直接打包在鏡像中，這樣又回到前文提到的問題，如果受影響的鏡像數量非常龐大的時候，這種臨時的緩解措施在實施起來也將面臨重大的挑戰。
在雲原生架構下，我們看到可以有幾種針對漏洞的緩解性操作：
（1）修改線上運行環境
我們可以通過kubectl edit pod…命令，修改線上服務Pod的運行參數，實現漏洞的緩解。針對批量的運行參數修改，我們也推出了一個開源的工具 。
值得注意的是，上述處置方式在修改完參數之後，會自動重啟服務，用戶在使用時，需評估相應的重啟風險。
圖3
（2）利用漏洞特性緩解
以log4j2為例，這是個遠程任意程式碼執行的漏洞，簡單來說，就是在列印日誌時，如果發現日誌內容中包含關鍵詞 ${，那麼這個裡面包含的內容會當做變數來進行替換，導致攻擊者可以任意執行命令。
因此在進行漏洞緩解時，可以利用漏洞的這一特性，將緩解指令通過漏洞傳進去，實現利用漏洞來緩解漏洞的效果。
這種方法針對不同的漏洞，不具有普適性。
（3）漏洞利用的阻止
前面兩種操作，都是從漏洞本身出發，通過緩解方式，使得漏洞不能被利用。另外一種緩解措施就是一旦前述緩解措施失效或被繞過，可以在漏洞利用的關鍵路徑上，進行操作的攔截，從而達到漏洞緩解的效果。
這種操作對安全能力有一定的依賴，一方面，安全能力需要能夠檢測出漏洞利用的行為，另一方面，需要能夠精準的對進程行為進行阻斷。尤其是對於log4j2這種任意程式碼執行的漏洞，漏洞利用的檢測對安全能力有著較高的要求。
通過上述幾種臨時緩解措施後，接下來我們需要做的就是，結合線上環境使用的鏡像以及業務重要性和優先順序等因素，有條不紊的將受影響的組件升級至官方發布的穩定修復版本。
雲原生架構下安全運營的挑戰和優勢
從上述漏洞處置的過程我們可以發現，雲原生架構下在漏洞的處置修復上，容器環境既面臨一定的挑戰，同時也有著一定的優勢。
挑戰
1）鏡像數量大。一方面，由於log4j2本身就是應用範圍很廣的組件，而且在微服務架構下，應用又會進行很多細粒度的微服務拆分，因此在倉庫中會受影響的鏡像會涉及到很多個Repositories；另一方面，由於DevOps等敏捷開發流程的使用，鏡像倉庫中的每一個鏡像又會有很多個版本（每個Repository有很多個Tags）。因此，在漏洞處置的過程中會發現，掃描出來的受影響鏡像數量巨大。
2）殭屍鏡像。所謂的殭屍鏡像，其實可以理解為存儲在倉庫中的舊版本鏡像，或者過期鏡像，已經幾乎不會再被運行使用。如果對倉庫中的鏡像沒有很好的管理機制，這種殭屍鏡像的數量也會非常大。這種現象其實也很好理解，DevOps帶來業務快速的迭代，自然就會產生大量的過期鏡像。
在常規的安全運營中，這些殭屍鏡像原則上是應該及時被清除的（不需要考慮備份回滾的問題，程式碼倉庫會有），這種清除操作不僅僅是需要覆蓋鏡像倉庫，同樣適用於主機上的殭屍鏡像。
3）不可變基礎設施。雲原生架構的一個典型特徵就是不可變的基礎設施，所謂的不可變基礎設施，是指一旦部署了服務之後決不允許被修改。如果需要以任何方式更新、修復或修改某些內容，則需要修改相對應的鏡像，構建全新的服務鏡像來替換舊的需要改變的服務鏡像，經過驗證後，使用新的鏡像重新部署服務，而舊的則會被刪除。
這種特性，給我們針對線上業務在進行漏洞緩解的時候帶來了很大的不便。一方面體現在修改應用的運行參數和環境變數等資訊上；另一方面體現在這種緩解措施的修改，會引發運行時安全的再次告警，因為這種操作違背了不可變基礎設施的要求，不是正常的業務操作流程。
優勢
• 資產可視化，快速定位。資產問題一直是安全建設和安全運營中重要的問題，同時也是最讓人頭疼的問題。雲原生架構很好的解決了資產的問題，通過Kubernetes等編排平台以及鏡像倉庫等組件，可以讓我們快速的進行資產梳理、問題定位。
• 流程自動化，快速生效。Kubernetes等編排平台提供了一整套的業務自動化管理方案，包括配置管理、服務編排、任務管理等。因此，對於漏洞的修復可以實現快速分發和對應的灰度升級等。
• 安全左移，快速控制。能夠在CI/CD等多個環節進行安全左移檢測，鏡像入庫前的檢測，阻止包含漏洞鏡像推送到倉庫，降低增量風險；在運行時進行准入檢測，對於包含漏洞風險的鏡像，阻止其啟動運行，減小線上環境新增暴露面。
• 微服務架構。在微服務架構下，應用間相對獨立，這給漏洞修復帶來的好處，一方面，針對某個鏡像的漏洞修復，影響範圍小，提高漏洞修復效率；另一方面，微服務架構下，服務功能單一，很多重複的功能會形成獨立服務，這樣減小了修複數量。
這次漏洞的爆發，給我們在雲原生安全建設和運營上敲響了警鐘，以該事件作為切入點，企業在雲原生架構的落地過程中，需要系統全面的考慮安全能力的建設和運營了。我們將在下一篇文章中，結合自身實踐，系統的分享我們對於雲原生架構下安全建設和安全運營的思考。
關於騰訊容器安全服務（TCSS）
騰訊容器安全服務（Tencent Container SecurityService, TCSS）提供容器資產管理、鏡像安全、集群安全、運行時入侵檢測等安全服務，保障容器從鏡像構建、部署到運行時的全生命周期安全，幫助企業構建容器安全防護體系。
騰訊從2018年9月30日啟動全面雲原生上雲戰略，至今已經有數千萬核心規模。容器安全服務產品團隊結合業內最大規模容器集群安全治理運營經驗打磨產品，推動行業標準及規範的編寫制定，並首發《騰訊雲容器安全白皮書》，對中國容器環境安全現狀進行分析總結，助力雲原生安全生態的標準化和健康發展。
關於我們
即刻關注【騰訊雲原生】公眾號，回復「虎虎生威」，領取騰訊訂製紅包封面~
福利：
①公眾號後台回復【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~
②公眾號後台回復【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列。
③公眾號後台回復【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》
③公眾號後台回復【光速入門】，可獲得騰訊騰訊雲專家5萬字精華教程，光速入門Prometheus和Grafana。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！
