前言
前一篇文章中，我們簡要分析了對於重大安全漏洞，在雲原生架構下該如何快速進行應急和修復，以及雲原生架構對於這種安全應急所帶來的挑戰和優勢。事件過後我們需要痛定思痛，系統的來思考下，面對雲原生架構如何進行有效的安全建設和安全運營，使得我們在安全事件的處置上可以做到遊刃有餘。
騰訊雲容器服務TKE目前擁有國內最大規模的Kubernetes叢集，執行了包括遊戲、支付、直播、金融等多個應用場景。而叢集的穩定執行離不開安全能力的保駕護航，騰訊雲容器安全服務TCSS掌握了業內最前沿的雲原生安全視角，為TKE的安全治理提供持續指導並沉澱了豐富的思考和最佳實踐。
本文將結合我們的安全建設和安全運營實踐，系統的分享我們對於雲原生架構下安全建設和安全運營的思考。
雲原生架構下的安全建設與安全運營
安全運營是目標，安全能力是手段。安全能力的建設與安全運營有著緊密的關係，安全能力建設是安全運營的基礎，巧婦難為無米之炊，更好的安全能力建設可以使安全運營更加順暢，同樣安全運營也能給安全能力建設提供更好的輸入和反饋，使安全檢測和防護能力更加精準。
雲原生架構下的安全能力建設和運營，其實是一個很大的命題，限於篇幅本文不會完全覆蓋。本文主要圍繞log4j2漏洞這個典型場景，從安全運營的視角，分析安全能力建設的必選項。
傳統的安全能力建設必不可少
首先需要說明的是，不管是我們現在講的容器安全，還是雲原生安全，都是一個相對狹義的概念，通常只包含了雲原生架構下特有安全風險的檢測與防護。從安全風險角度來看，我們也一直強調，雲原生架構下的安全風險是一個增量，因此在整體的安全建設上，一定是個縱深防禦的體系，不是某個產品單打獨鬥所能完成的。
例如南北向流量出入口的WAF、防火牆、抗D等，假如我們的雲原生是建立在IaaS基礎之上的，那麼VPC、甚至是underlay層面的網路分級分域的隔離和入侵檢測，這些都是雲原生安全建設的基礎。
在這次log4j2漏洞的應急處置中，我們也發現，即使是容器環境，通過升級WAF規則、更新防火牆出站策略等方式，也能在第一時間實現一定程度的漏洞緩解和阻斷。
騰訊雲在2021年11月釋出的《騰訊雲容器安全白皮書》中，也提出了層次化的容器安全體系框架，其中很重要的一部分就是基礎安全，這裡的基礎安全就是包括了原有的資料中心安全以及雲安全建設所覆蓋的內容。
安全運營驅動安全能力建設
對於體系化的安全建設和安全運營，一些技術組織以及標準化組織，也提出過相關的標準框架，這些框架對於我們在安全建設上，都有著重要的指導和參考意義，這裡我們以NIST提出的網路安全框架 為例來作為我們雲原生安全建設的參考。
參考NIST網路安全框架，我們同樣將雲原生安全建設劃分為五個並行並且連續的步驟，分別是識別、防護、檢測、響應和恢復。
安全識別
（1）叢集資產識別
安全識別最主要是體現在資產識別上。這裡的資產既包括cluster、node、namespace、pod、service、container等Kubernetes資源層面的資產，同樣還包括映象倉庫、容器映象等維度的應用資產資訊。
雲原生架構下，除了基本的資產識別盤點之外，還需要能夠發現這些資產之間潛在的資源和業務之間的邏輯關係。這樣一旦檢測到某個映象包含新的漏洞，或者檢測到相應的入侵行為，需要能夠快速進行所有資產和人員的自動化關聯定位，發現影響範圍，以及定位安全責任人，進而快速進行處置。
（2）自建容器識別
除了對於標準叢集層面的資產具備上述識別能力外，對於研發系統等相對複雜的環境同樣需要有一定的適配能力。例如，在研發環境中，除了標準叢集層面的資產外，還會出現自建的資產，例如使用者用Docker run等命令直接拉起執行的容器。
（3）業務風險識別
從安全運營角度看，安全識別還體現在業務風險識別上。我們需要對叢集、應用進行清晰的安全風險級別劃分，對於高風險應用，需要採用更高階別的安全策略。例如，對於核心業務系統，要有嚴格的網路隔離以及訪問控制機制，對於直接暴露出去的服務，在容器維度要有更加嚴格的許可權控制等。
安全防護
具備資產以及業務風險資訊後，接下來就需要依賴基本的安全防護能力，實現對已知威脅的安全防護。這裡的安全防護主要包括兩個方面：
（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等資源，實現不同粒度的網路隔離。
• 防護策略管理
在運營過程中，如何設定准入控制、操作攔截、網路隔離等策略，這是一個令人頭疼的問題，因為無論是安全管理員、運維管理員，甚至是開發人員，都很難完全講得清楚這些規則該如何配置，才能實現相對最安全的狀態。
這是雲原生架構下安全運營的一個挑戰，同時雲原生架構本身也提供應對這種挑戰的優勢。前文提到雲原生架構的一個重要特性就是不可變的基礎設施，這就意味著，我們可以通過白名單、行為模型等方式，基於業務特性以及歷史執行資料，自動化的學習生成一套安全基線，這個安全基線將成為各種防護策略配置的重要參考。
安全檢測
安全永遠是一個攻防博弈的過程，而防守方往往處於相對劣勢的地位，甚至可以說沒有攻不破的系統。
在雲原生架構下，業務變得越來越開放和複雜，攻擊者的手段越來越多樣化，前文所述的防禦攔截措施，總是難以應對所有的威脅，有些高階定向攻擊或者是像針對log4j2這種0day漏洞的攻擊，總是可以輕易的繞過各種防禦手段，讓安全威脅防不勝防。
因此，在完成了上述所有的防禦攔截措施之後，還需要持續的對雲原生系統進行執行時監測以及安全檢測。基於雲原生架構的特性，這裡將安全檢測分為兩個維度來進行。
1）系統維度的威脅檢測
主要針對容器內的行為來進行，比如容器內程式異常的檢測、檔案異常的檢測、使用者異常的檢測等，通過這些細粒度的異常檢測，發現諸如提權、挖礦等攻擊行為。
網路維度的威脅檢測。主要面向的是後滲透階段的橫向移動，雖然我們在防護階段已經設定了嚴格的訪問控制策略，但是在網路可達範圍內的橫向移動攻擊，仍然會帶來重要的安全威脅。網路威脅檢測主要分為兩個方面：一方面是從網路行為的角度，基於Flow實現網路流量尤其是東西向流量的異常檢測，這對於埠探測、APT攻擊，甚至是新型的網路威脅或者高階的網路威脅等檢測將會起到重要的幫助（NDR）；另一方面就是從資料包的角度，分析容器之間網路的資料包異常，實現容器網路的入侵檢測（NIDS）。
2）應用維度的威脅檢測
同樣面向是後滲透階段的橫向移動，雲原生時代應用的微服務架構使得容器間的網路通訊會存在大量的API呼叫，確保所有這些API之間呼叫都是安全的，對於雲原生應用的安全有著重要的意義。例如，在已攻陷的容器中，通過API的方式獲取其他服務的資料、或者是通過構造惡意的引數實現對關聯服務的攻擊。因此，需要在應用的維度實現對API呼叫異常的檢測，比如呼叫行為、呼叫路徑、呼叫引數等。
安全響應
安全響應主要是針對前一個步驟的安全檢測告警所做出的處置措施。在雲原生架構下的安全響應，尤其是網路安全層面的安全響應，我們更傾向於使用旁路檢測響應處置這樣的操作步驟，而不是像傳統網路安全中串聯接入IPS、WAF這種直接阻斷式的檢測響應，這樣的設計主要是從業務效能的角度出發。
威脅的響應主要也是包括兩個方面：
（1）處置
通過網路隔離、暫停容器、停止異常程式、銷燬容器等方式，實現對告警的響應處置。這裡有一個前提，就是在安全能力的建設過程中，鑑於容器的短生命週期特性，需要實現完善的日誌和追蹤記錄，以便實現處置後的溯源取證。
處置的過程中，對於某些確定性異常，可以通過一鍵阻斷、一鍵隔離等方式，實現處置操作的自動化，以降低運營成本。
（2）溯源
根據容器的告警、日誌、追蹤等資料以及資料間的關聯分析，實現對告警的溯源分析，明確攻擊鏈路，確定入侵原因。
安全修復
在安全修復階段主要包括兩個方面的內容：一方面就是針對入侵原因，對相關風險進行加固性修復；另一方面，就是從加固、防護、檢測等步驟，分別更新相關的安全策略，實現運營反饋。
總結
Log4j2漏洞已經過去了一個多月，相信很多該打的補丁都已經修復完畢，這次突發的應急事件，是否讓我們需要重新思考雲原生架構下的安全建設和安全運營。漏洞或者入侵很難預測，不知道下一次什麼時候還會發生，痛定思痛，到那時我們能否可以從容應對。
希望本文的思考能給雲原生安全建設帶來一些思路和幫助，如有任何建議或疑問，歡迎文末留言。
關於我們
即刻關注【騰訊雲原生】公眾號，回覆“虎虎生威”，領取騰訊定製紅包封面~
福利：
①公眾號後臺回覆【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~
②公眾號後臺回覆【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 效能優化實踐、最佳實踐等系列。
③公眾號後臺回覆【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》
③公眾號後臺回覆【光速入門】，可獲得騰訊騰訊雲專家5萬字精華教程，光速入門Prometheus和Grafana。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
