微軟2020年發布Kubernetes攻擊威脅矩陣,今年上半改版,該公司首度在臺探討這項議題,他們的首席雲端解決方案架構師李匡正揭露須關注的3大風險面,包含網路安全政策面、敏感資料面與應用程式面,圖為應用程式面所對應的4項攻擊技術手法。

隨著輕量虛擬化的容器技術(container)成為熱門應用,管理容器化的Kubernetes(K8s)系統也備受關注,而了解容器化環境的各種威脅與安全風險,更是成為近年矚目焦點,特別的是,在2020年4月,微軟仿效MITRE ATT&CK,發布了Kubernetes攻擊威脅矩陣(Threat matrix for Kubernetes),期望剖析攻擊面,並建立業界面對容器資安威脅的共通描述語言。

相隔一年,微軟首度更新K8s攻擊威脅矩陣,今年4月該公司首席雲端解決方案架構師李匡正提出更多說明,闡釋K8s值得關注的安全議題。

值得關注的安全議題,包含網路安全政策、敏感資料與應用程式面

基本上,K8s攻擊威脅矩陣參考MITRE ATT&CK框架,將相關攻擊技術手法系統予以歸納,各戰略階段名稱幾乎與ATT&CK相同,但與現行ATT&CK相比,數量顯然較少。

以K8s攻擊威脅矩陣而言,目前最新版共畫分10個階段(第一版為9個階段),從入侵初期、執行、權限提升、防禦逃避、憑證存取、發現、橫向移動、收集,以至最終的衝擊,並統整歸納出48個技術手法(第一版為40項技術手法)。

而在這些統整的這些K8s攻擊技術手法中,近年有那些安全議題值得關注?李匡正表示,可從三大面向著手,包括:網路安全政策、敏感資料保存與應用程式面。

首先,是在網路安全政策方面,以攻擊手法而言,是列為發現階段的Network Mapping,以及橫向移動階段的Clusterinternal networking。

對於網路安全政策面的資安風險,李匡正表示,部署於同一K8s叢集的Pod與Pod之間,預設是允許相互連線,也就是不會有任何攔阻,而這樣的設計並不安全。

他進一步解釋原因。以傳統規畫機房為例,每個網段可能會配置防火牆,作業系統本身有防火牆,而在雲端每個虛擬網路的網段,也都會有類似網火牆的機制。

因此,在K8s 1.7版本之後,CNCF基金會開始定義Network policy規格,來因應這樣的需求,而這等同於實體網路環境中防火牆的角色,可定義Pod與Pod之間流量進出規則,市面上,已有多套實作Network Policy的機制,李匡正表示,若以Azure Kubernetes Service(AKS)為例,微軟本身的相關實作,稱為Azure Network Policy,也支援Calico專案。

他特別提醒,雖然開發人員在測試環境中會盡量簡化應用程式的架構,不過在正式營運環境中,需考慮到透過這樣網路政策,預設就要擋掉所有對外及對內的流量,在依照政策規則,開放特定網路埠供特定的Pod來使用。

第二個常見的風險,在於敏感資料保存方面的K8s Secrets,而對應的攻擊手法,主要是列於該威脅矩陣中,在憑證存取階段的List K8s Secrets。

李匡正說,K8s提供給開發者用來存放敏感資訊的機制稱為Secrets,可存放access token、帳號密碼與資料庫連線字串等機密資訊,不過,由於K8sSecrets預設並沒有加密,只是用Base64編碼寫入,因此懂得寫程式的人,都能用Base64解碼的方式將這些機密還原。

因此,在K8s的相關文件,已經強調須使用加密的方案來達到安全。李匡正表示,在Azure環境當中,他們提供了HSM硬體加密的Azure Key Vault,可與K8s Secrets結合應用。

同時,雖然套用加密,但在存取時還是會解密, 因此,做到以角色為基礎的存取控制(RBAC)就相當重要。他舉例,在開發測試環境中,往往可能為了除錯方便,而沒有做到細部的存取管控,但是,到了正式環境,存取管控千萬不能省略,不論是開發人員、系統管理人員的權限,都需要被定義清楚。

因此,對於K8s Secrets的基本安全防護,他提醒,必須使用加密解決方案,以及制定嚴謹存取權限管控。

第三個常見的K8s資安風險面向,是在應用程式方面,對應的攻擊技術手法有4項,分別是入侵初期階段的Using cloud credentials、Compromised images in registry與Application vulnerability,以及橫向移動階段的Container service account。

在雲端環境中,系統管理員對於整個叢集的管控上,用戶驗證機制如何設定?是否開啟多因素驗證? 都是至關重要的事情, 還有惡意映像檔的風險,包括:下載來歷不明的映像檔, 或是容器映像檔建立時本身已經被發現有資安漏洞,當用戶從網路上的免費Docker Hub下載這些映像檔使用,有可能會造成嚴重的問題,而上述面向,經常是攻擊發起點。

李匡正也提醒大家注意應用程式的弱點,雖然這與容器無關,不過,當應用程式有弱點,且一併進到K8s環境之際,這些弱點也會浮現。

需仰賴多重防護配合,以達到安全性要求

對於上述K8s攻擊面的防護,雖然初期測試環境可能很簡單,但在正式環境下需要注意一些細節,因為要做到相關的要求,背後其實是要有多重防護的配合。

以Azure環境而言,例如:包含Azure Firewall Subnet、Azure App Gateway Subnet,可控制由內往外的網路流量、搭配網站應用程式防火牆(WAF)保護,以及在Azure Kubernetes Serveice Subnet中,將透過內部負載平衡器來連接,並藉由Calico提供網路政策給Kubernetes使用,透過Azure AD Pod Identity,讓Pod存取各項Azure服務。之後,再經過Azure VNET內部私有IP位址,存取Azure File與Azure Container Registry。

李匡正特別強調,要讓人員經手接觸機密資訊的機會降低,透過CI/CD工具將整個環節串起來,而微軟本身也使用WhiteSource公司發展的Bolt,來執行開放原始碼軟體套件的資安監控。此外,他也提醒,開發測試與正式營運應完全分開,避免共同環境底下的資安風險。

李匡正表示,企業若要防護K8s攻擊,需注意多種機制的搭配,顧及許多細節才能要做到相關的要求,他並以Azure環境下來說明。同時,他也提醒,開發測試與正式營運的作業區應完全分開,避免因共同環境而產生資安風險。

新增8項攻擊技術手法,以Sidecar injection最受關注

另外值得一提的是,由於今年微軟K8s攻擊威脅矩陣改版,對於相關攻擊技術手法的統整,作了更動,當中刪除3項並額外增加8項,似乎透露K8s在基本安全性的提升,以及新的威脅趨勢,到底當中有哪些變化值得關注?

對此問題,李匡正表示,在本次改版當中,微軟已經移除了儀表板相關的攻擊手法,包括:Exposed Kubernetes Dashboard,以及Access Kubernetes dashboard。

主要原因是,對於K8s儀表板方面的威脅,之前微軟已經建議,不要在網際網路上暴露Kubernetes儀表板,同時,只應授與儀表板服務帳號必要的權限等。

以實際狀況來看,包括微軟AKS,以及Google Kubernetes Engine(GKE)等服務,現在都關閉K8s儀表板,用戶需從Azure Portal、Google CloudConsole來檢視資訊。同時,在新版K8s攻擊框架中,也用涵蓋範圍更廣泛的exposed sensitive interfaces,取代相關威脅。

至於Access tiller endpoint項目被移除,主要是K8s應用程式管理工具Helm第3版中,不再需要使用API通訊工具Tiller。換言之,若是現在仍繼續使用Helm第2版與Tiller,在安全面是有疑慮的。

關於新增的攻擊手法中,何者特別值得關注? 李匡正表示,以Sidecar injection為例,目前Kubernetes邊車模式(Sidecar)大量用在Service Mesh,而在Service Mesh扮演邊車Proxy的Pod,如果被注入惡意軟體,代表主程式的所有網路存取,都可能會被這類資安威脅攔截,如此將造成很嚴重的問題。

微軟Azure團隊於今年3月針對K8s威脅矩陣進行首度改版,相關彙整技術手法有些變化,新增8項並刪除3項。(圖片來源:微軟)


熱門新聞

Advertisement