從重大漏洞應急看云原生架構下的安全建設與安全運營（下）

前言：

前一篇文章“從重大漏洞應急看云原生架構下的安全建設與安全運營（上）”中，我們簡要分析了對于重大安全漏洞，在云原生架構下該如何快速進行應急和修復，以及云原生架構對于這種安全應急所帶來的挑戰和優勢。事件過后我們需要痛定思痛，系統的來思考下，面對云原生架構如何進行有效的安全建設和安全運營，使得我們在安全事件的處置上可以做到游刃有余。

騰訊云容器服務TKE目前擁有國內最大規模的Kubernetes集群，運行了包括游戲、支付、直播、金融等多個應用場景。而集群的穩定運行離不開安全能力的保駕護航，騰訊云容器安全服務TCSS掌握了業內最前沿的云原生安全視角，為TKE的安全治理提供持續指導并沉淀了豐富的思考和最佳實踐。

本文將結合我們的安全建設和安全運營實踐，系統的分享我們對于云原生架構下安全建設和安全運營的思考。

2、云原生架構下的安全建設與安全運營

安全運營是目標，安全能力是手段。安全能力的建設與安全運營有著緊密的關系，安全能力建設是安全運營的基礎，巧婦難為無米之炊，更好的安全能力建設可以使安全運營更加順暢，同樣安全運營也能給安全能力建設提供更好的輸入和反饋，使安全檢測和防護能力更加精準。

云原生架構下的安全能力建設和運營，其實是一個很大的命題，限于篇幅本文不會完全覆蓋。本文主要圍繞log4j2漏洞這個典型場景，從安全運營的視角，分析安全能力建設的必選項。

2.1傳統的安全能力建設必不可少

首先需要說明的是，不管是我們現在講的容器安全，還是云原生安全，都是一個相對狹義的概念，通常只包含了云原生架構下特有安全風險的檢測與防護。從安全風險角度來看，我們也一直強調，云原生架構下的安全風險是一個增量，因此在整體的安全建設上，一定是個縱深防御的體系，不是某個產品單打獨斗所能完成的。

例如南北向流量出入口的WAF、防火墻、抗D等，假如我們的云原生是建立在IaaS基礎之上的，那么VPC、甚至是underlay層面的網絡分級分域的隔離和入侵檢測，這些都是云原生安全建設的基礎。

在這次log4j2漏洞的應急處置中，我們也發現，即使是容器環境，通過升級WAF規則、更新防火墻出站策略等方式，也能在第一時間實現一定程度的漏洞緩解和阻斷。

騰訊云在2021年11月發布的《騰訊云容器安全白皮書》中，也提出了層次化的容器安全體系框架，其中很重要的一部分就是基礎安全，這里的基礎安全就是包括了原有的數據中心安全以及云安全建設所覆蓋的內容。

2.2安全運營驅動安全能力建設

對于體系化的安全建設和安全運營，一些技術組織以及標準化組織，也提出過相關的標準框架，這些框架對于我們在安全建設上，都有著重要的指導和參考意義，這里我們以NIST提出的網絡安全框架 為例來作為我們云原生安全建設的參考。

參考NIST網絡安全框架，我們同樣將云原生安全建設劃分為五個并行并且連續的步驟，分別是識別、防護、檢測、響應和恢復。

2.2.1安全識別

（1）集群資產識別

安全識別最主要是體現在資產識別上。這里的資產既包括cluster、node、namespace、pod、service、container等Kubernetes資源層面的資產，同樣還包括鏡像倉庫、容器鏡像等維度的應用資產信息。

云原生架構下，除了基本的資產識別盤點之外，還需要能夠發現這些資產之間潛在的資源和業務之間的邏輯關系。這樣一旦檢測到某個鏡像包含新的漏洞，或者檢測到相應的入侵行為，需要能夠快速進行所有資產和人員的自動化關聯定位，發現影響范圍，以及定位安全責任人，進而快速進行處置。

（2）自建容器識別

除了對于標準集群層面的資產具備上述識別能力外，對于研發系統等相對復雜的環境同樣需要有一定的適配能力。例如，在研發環境中，除了標準集群層面的資產外，還會出現自建的資產，例如用戶用Docker run等命令直接拉起運行的容器。

（3）業務風險識別

從安全運營角度看，安全識別還體現在業務風險識別上。我們需要對集群、應用進行清晰的安全風險級別劃分，對于高風險應用，需要采用更高級別的安全策略。例如，對于核心業務系統，要有嚴格的網絡隔離以及訪問控制機制，對于直接暴露出去的服務，在容器維度要有更加嚴格的權限控制等。

2.2.2安全防護

具備資產以及業務風險信息后，接下來就需要依賴基本的安全防護能力，實現對已知威脅的安全防護。這里的安全防護主要包括兩個方面：

（1）系統加固

?  配置檢測與修復

系統加固可謂是個老生常談的話題了，尤其是配置檢查與安全配置加固，但是在云原生架構下，這一點是尤為重要的。因為從容器的設計理念來看，其與操作系統共享內核，給了容器用戶更大的可操作空間，因此，配置的安全與否將在很大程度上影響著整個系統的安全性。

從前文的容器環境主要入侵路徑可以看出，通過主機攻擊容器是其中重要的一種路徑，例如通過Docker Remote API。因此安全能力需要包括全面的配置檢查。

配置加固雖然說起來是個老問題，但是在云原生環境中，真正實現完整的安全能力還是比較復雜，這既包括Kubernetes、Docker、Istio等基礎平臺與組件的加固，還包括鏡像內應用軟件的配置加固，這個做起來就更復雜一些。我們在這里就不再展開。

從安全運營角度看，我們需要能夠根據配置檢查得到的信息，將基本的配置進行安全性加固。同時一個重要的點就是，安全配置與業務穩定運行之間的平衡，一方面需要保證充分實現了安全性，另一方面就是不會對業務的可用性和穩定性造成影響。這就需要在配置加固的同時，結合業務特性與安全配置要求，靈活對配置策略進行調整，這將會是一個持續的修正和完善的過程。

?  漏洞檢測與修復

已知漏洞修復同樣是個古老的話題，包括主機層面的漏洞和鏡像的漏洞，對于檢測出來的漏洞，需要根據漏洞的威脅等級以及利用難易程度等信息，確定是否需要修復以及修復的優先級。

?  鏡像安全評估與修復

容器鏡像作為云原生應用的源頭，除了漏洞之外，還需要進行更多維度的安全性評估。例如至少需要包含以下幾個方面：鏡像內敏感信息的檢測，確保不會發生敏感信息泄露；鏡像中病毒木馬等惡意文件檢測，這主要針對不確定來源的公開鏡像；鏡像構建的合規性檢測，比如COPY和ADD的使用區別等。

除了針對上述鏡像風險的檢測和修復之外，在安全運營上還需要考慮對僵尸鏡像清理，這既包括對鏡像倉庫的清理，也包括對集群node節點的清理，這對于減小攻擊面有著重要的作用。

同時，針對不同鏡像需要支持自定義的檢測規則，不同的組織用戶或者不同類型業務的鏡像，對安全的要求是不一樣的，因此在鏡像的安全評估上，除了基于一套通用的檢測評價規則之外，還需要支持用戶的自定義規則，這樣可以結合前文的業務風險識別，針對不同的鏡像，靈活采用不同的安全規則。

?  風險管理

在運營管理上，針對上述提及的配置、漏洞等風險信息，需要有一套完善的閉環風險管理流程，確保完全實現了風險的識別、修復以及確認。

（2）安全防護

除了系統加固外，在安全防護階段，還應該在不同層面，針對已知可能發生的入侵風險，通過相關的防護能力和防護策略進行攻擊的預防。

?  準入控制

準入控制顧名思義就是在云原生應用的全生命周期流程中，根據安全的要求，在不同的階段進行控制和阻斷，進而實現安全性的目標，這也是DevSecOps的一項基本要求。云原生架構憑借其靈活的資源管理與自動化的應用編排，給安全性的控制提供了充分的便利。準入控制的價值，一方面體現在安全風險的預防上，另一方面，一旦log4j等重大0day爆發后，可以通過準入控制，快速控制影響面，防止風險新增。

從生命周期流程看，準入控制需要分別從研發（dev）和運行時(ops)兩個階段來實施。研發階段的準入主要指在CI、入庫等階段，進行漏洞、敏感信息之類的安全風險的檢測，只有符合安全要求后，才允許進入流水線的下一個階段。這里的準入條件通常需要涵蓋前文講的各種加固內容。

運行時的準入控制，則主要體現在應用被部署運行的階段，只有符合安全要求的容器/pod，才允許被拉起運行，這里的準入條件通常包括對資源限制的檢測、對syscall/capability等權限限制的檢測等。

同樣，從運營的角度看，準入控制規則除了標準默認的之外，還需要能夠根據應用進行靈活則調整和完善。

?  運行時攔截

云原生架構下的容器內，承載的是微服務應用，因此理論上是不應該具備高權限指令的執行，這一點我們在準入控制雖然做了一定程度的預防。這里我們基于運行時安全能力，還需要實現對容器內高危操作的攔截，例如高危命令、高危系統調用等，在不同維度實現安全的縱深防御。

?  網絡隔離

橫向擴展是攻擊者在實現第一步攻擊之后的操作，也可以稱為后滲透階段。在云原生網絡的設計中，通常默認是不具備任何網絡隔離能力的，因此，需要設置并實現一套完善的網絡隔離機制，實現不同業務之間的網絡隔離。

云原生架構下的網絡組織形態，區別于傳統的基于主機或者虛擬機的網絡，在Kubernetes中，網絡的最小單位是Pod，而Pod中承載的是業務容器。因此，在實現網絡隔離的時候，傳統的基于IP、端口的網絡策略將不再適用，我們需要基于label、service等資源，實現不同粒度的網絡隔離。

?  防護策略管理

在運營過程中，如何設置準入控制、操作攔截、網絡隔離等策略，這是一個令人頭疼的問題，因為無論是安全管理員、運維管理員，甚至是開發人員，都很難完全講得清楚這些規則該如何配置，才能實現相對最安全的狀態。

這是云原生架構下安全運營的一個挑戰，同時云原生架構本身也提供應對這種挑戰的優勢。前文提到云原生架構的一個重要特性就是不可變的基礎設施，這就意味著，我們可以通過白名單、行為模型等方式，基于業務特性以及歷史運行數據，自動化的學習生成一套安全基線，這個安全基線將成為各種防護策略配置的重要參考。

2.2.3安全檢測

安全永遠是一個攻防博弈的過程，而防守方往往處于相對劣勢的地位，甚至可以說沒有攻不破的系統。

在云原生架構下，業務變得越來越開放和復雜，攻擊者的手段越來越多樣化，前文所述的防御攔截措施，總是難以應對所有的威脅，有些高級定向攻擊或者是像針對log4j2這種0day漏洞的攻擊，總是可以輕易的繞過各種防御手段，讓安全威脅防不勝防。

因此，在完成了上述所有的防御攔截措施之后，還需要持續的對云原生系統進行運行時監測以及安全檢測。基于云原生架構的特性，這里將安全檢測分為兩個維度來進行。

1）系統維度的威脅檢測

主要針對容器內的行為來進行，比如容器內進程異常的檢測、文件異常的檢測、用戶異常的檢測等，通過這些細粒度的異常檢測，發現諸如提權、挖礦等攻擊行為。

網絡維度的威脅檢測。主要面向的是后滲透階段的橫向移動，雖然我們在防護階段已經設置了嚴格的訪問控制策略，但是在網絡可達范圍內的橫向移動攻擊，仍然會帶來重要的安全威脅。網絡威脅檢測主要分為兩個方面：一方面是從網絡行為的角度，基于Flow實現網絡流量尤其是東西向流量的異常檢測，這對于端口探測、APT攻擊，甚至是新型的網絡威脅或者高級的網絡威脅等檢測將會起到重要的幫助（NDR）；另一方面就是從數據包的角度，分析容器之間網絡的數據包異常，實現容器網絡的入侵檢測（NIDS）。

2）應用維度的威脅檢測

同樣面向是后滲透階段的橫向移動，云原生時代應用的微服務架構使得容器間的網絡通信會存在大量的API調用，確保所有這些API之間調用都是安全的，對于云原生應用的安全有著重要的意義。例如，在已攻陷的容器中，通過API的方式獲取其他服務的數據、或者是通過構造惡意的參數實現對關聯服務的攻擊。因此，需要在應用的維度實現對API調用異常的檢測，比如調用行為、調用路徑、調用參數等。

2.2.4安全響應

安全響應主要是針對前一個步驟的安全檢測告警所做出的處置措施。在云原生架構下的安全響應，尤其是網絡安全層面的安全響應，我們更傾向于使用旁路檢測?響應處置這樣的操作步驟，而不是像傳統網絡安全中串聯接入IPS、WAF這種直接阻斷式的檢測響應，這樣的設計主要是從業務性能的角度出發。

威脅的響應主要也是包括兩個方面：

（1）處置

通過網絡隔離、暫停容器、停止異常進程、銷毀容器等方式，實現對告警的響應處置。這里有一個前提，就是在安全能力的建設過程中，鑒于容器的短生命周期特性，需要實現完善的日志和追蹤記錄，以便實現處置后的溯源取證。

處置的過程中，對于某些確定性異常，可以通過一鍵阻斷、一鍵隔離等方式，實現處置操作的自動化，以降低運營成本。

（2）溯源

根據容器的告警、日志、追蹤等數據以及數據間的關聯分析，實現對告警的溯源分析，明確攻擊鏈路，確定入侵原因。

2.2.5安全修復

在安全修復階段主要包括兩個方面的內容：一方面就是針對入侵原因，對相關風險進行加固性修復；另一方面，就是從加固、防護、檢測等步驟，分別更新相關的安全策略，實現運營反饋。

3.總結

Log4j2漏洞已經過去了一個多月，相信很多該打的補丁都已經修復完畢，這次突發的應急事件，是否讓我們需要重新思考云原生架構下的安全建設和安全運營。漏洞或者入侵很難預測，不知道下一次什么時候還會發生，痛定思痛，到那時我們能否可以從容應對。

希望本文的思考能給云原生安全建設帶來一些思路和幫助，如有任何建議或疑問，歡迎文末留言。