前言
前一篇文章中，我們簡要分析了對于重大安全漏洞，在云原生架構下該如何快速進行應急和修復，以及云原生架構對于這種安全應急所帶來的挑戰和優勢，事件過后我們需要痛定思痛，系統的來思考下，面對云原生架構如何進行有效的安全建設和安全運營，使得我們在安全事件的處置上可以做到游刃有余，
騰訊云容器服務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，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/421819.html
標籤：其他