縱深防禦的資安防禦方法採多層式控管,在企業內各個不同環節設置資安屏障來提供多重保障,以防某個環節失效遭駭時,還有其他環節提供保護。雲端原生防護就是採用這樣的方式,將防護策略劃分成「雲端原生防護4C」四個不同層次。
雲端原生運算是一種在雲端內建構及執行可擴充式應用程式的軟體開發方法,不論在公有雲、私有雲、企業內或混合雲等環境,其結合了開放原始碼與非開放原始碼兩種軟體來部署應用程式,例如包裝在個別容器中的微服務(Microservice)即是一例。
容器(如Docker容器)會將所有必要的軟體和應用程式包裝到隔離獨立的處理程序內部。由於企業經常跨多台主機執行多個容器,因此還需要使用Kubernetes這類的容器協調系統,並透過持續整合∕持續交付(CI/CD)工具,遵循DevOps方法來管理和部署。最終,雲端原生技術將使企業徹底發揮雲端資源的效益,不僅能減輕負擔、加快反應速度,而且管理起來也更輕鬆。
如同任何仰賴各種環環相扣的工具與平台的技術一樣,雲端原生運算環境的資安扮演著相當重要的角色。如果有什麼是資安專家們一致認同的看法,那就是「今日沒有任何現代化的複雜軟體系統是『完全無法駭入』的,沒有百分之百無法被滲透的系統、裝置或環境。」也因此,才會衍生出一種所謂「縱深防禦」的資安防禦方法,這是一個從軍事領域借用到網路資安領域的概念。
縱深防禦的方法採用多層式控管,在企業內各個不同環節設置資安屏障來提供多重保障,以防萬一某個環節失效或遭駭,還有其他環節可提供保護。雲端原生防護就是採用這樣的方式,如圖1所示,將雲端原生系統的防護策略劃分成「雲端原生防護4C」的四個不同層次。
雖然在每一個層次都設置資安控管相當重要,但由於每一層都是歹徒可利用的攻擊面,且各層的防護又獨立運作,所以應用程式還是可能遭到攻擊。例如,當一個不安全的網站應用程式遭遇SQL資料隱碼攻擊(SQL Injection)時,除非使用了某種特殊功能的第三方軟體,否則圖1當中的其他防護層也無法發揮保護作用。
網路資安攻防的防禦者,必須盡可能涵蓋每一種可能的情況,盡量讓系統防護面面俱到。雖然這聽起來很難,但還是必須做到,因為有時駭客只須找到一個破口,就能入侵整個系統。以下將詳細探討雲端原生系統的每一層最常出現的資安問題,並提供偵測及防範的祕訣。
雲端防護
「雲端」這一層,指的是伺服器執行時的底層基礎架構。要在所選定的雲端服務供應商(CSP)環境建立一台伺服器,將牽涉到許多不同服務,如圖2所示。儘管這些服務(如作業系統、平台管理、網路組態)的安全責任絕大部分該由CSP來承擔,但客戶仍有責任檢查並設好這些服務的組態設定,並且小心看守及保護自己的資料。企業在決定將企業內的運算資源和服務移轉到雲端時,很重要的一點就是要了解並且妥善運用這種共同分擔資安責任的模式。
接下來,說明今日雲端系統最常見的問題:
組態設定錯誤
隨著各種雲端架構組成元件的數量不斷增加,預估組態設定錯誤的情況也會跟著增加。雖然組態設定錯誤通常只是使用者的疏忽或無心之過,然而這卻是網路犯罪集團經常利用的弱點,並可能為企業帶來龐大的財務甚至名譽損失。
組態設定錯誤的問題可說相當常見,其中一起案例就是,駭客藉由特斯拉(Tesla)公司Kubernetes系統管理主控台的組態設定錯誤,植入挖礦程式。許多服務和應用程式在建立時都使用預設的設定值,因此暴露在網際網路上。這讓伺機而動的許多殭屍病毒和駭客變得有機可乘。駭客會攻擊暴露在網路上的Redis執行個體,發動遠端程式碼執行(RCE)攻擊,或者將它們變成虛擬加密貨幣挖礦殭屍。
自動化
自動化可以加快建立新系統與部署新應用程式的速度,但是如果沒有經過仔細的檢查或監督,也可能讓錯誤和資安問題擴散得更快。除了威脅之外,威脅在不安全的連網系統或裝置上的入侵速度也是另一項值得憂心的。根據一項研究發現,駭客只需52秒的時間就能掃描並駭入研究人員設置在誘捕網路中的不安全裝置。因此,企業必須適當且有效地保護其架構的各個面向。
企業若能確實遵照雲端廠商的建議,定期執行稽核並確保一切設定都正確之後再部署到對外開放的生產環境,就能避免遭遇上述的問題。 採用基礎架構即程式碼(Infrastructure-as-a-Code,IaC)是確保系統正確建立、正確設定組態的一項有效方法。IaC透過程式碼將IT架構的正確配置自動化,如此就不必依賴DevOps工程師手動執行這項作業,進而減少人為疏失,只須遵循最佳實務原則即可。此外,像Terraform、Ansible和CloudFormation這類的工具,可定義基礎架構的基準設定(包括防護設定),因此算是很方便的工具。除此之外,此類工具還可確保設定不會遭到非經授權的變更。
IaC未來將成為建構雲端環境的新常態,它能讓企業善用不同程度的自動化與部署的速度。今日,企業已經無須手動啟動或設定伺服器,自動化已是雲端架構安全的關鍵。
除此之外,也請務必遵照CSP的資安建議,詳情請參考以下各家主流CSP的資安最佳實務原則:
‧Amazon Web Services:https://aws.amazon.com/security/
‧Google Cloud Platform:https://cloud.google.com/security/
‧Microsoft Azure:https://docs.microsoft.com/en-us/azure/security/azure-security
除此之外,一些可提供雲端基礎架構可視性並將防護與法規遵循檢查自動化的解決方案,如Trend Micro Cloud One - Conformity,也能讓這一層的防護簡化及最佳化。
叢集防護
叢集防護的討論重點主要是Kubernetes,因為它是今日最普遍使用的容器協調工具。不過,此處討論的資安原則同樣也適用於其他同類型的產品。關於叢集,企業最需要關注的有三點:
叢集元件
首先,要保護叢集的構成元件,對Kubernetes來說就是主要節點(Master Node)。叢集防護最重要的就是管控API伺服器的存取與限制「etcd」(也就是Kubernetes主要資料儲存區)的直接存取等等。Kubernetes有一套完整的文件來說明如何防止叢集遭到意外或惡意的存取。趨勢科技在一篇文章(https://t.rend.tw/?i=OTI5NA)提到,發現有3,000台主機的「etcd」公開暴露在網路上。為了避免這樣的情況發生,建議雲端系統管理員應該預設它禁止存取,僅允許經過核准的流量。除非擁有充足的人力或制定了嚴格的規範,否則建議採用Azure Kubernetes Service(AKS)、Elastic Kubernetes Service(EKS)或Google Kubernetes Engine(GKE)之類的叢集託管服務。
叢集服務
其次,要藉由正確的組態設定與存取控管來保護叢集上執行的服務。為了這些服務的安全,Kubernetes建議應採取一些必要的防護措施,例如資源管理,還有以最低的權限來執行服務。請務必為自身的叢集設定適當的認證與授權機制,利用Transport Layer Security(TLS)將流量加密,並使用Kubernetes Secret來保護敏感資料。另外,也建議參考一下Center for Internet(CIS)Kubernetes評測來了解有關保護叢集服務的更多技術細節。
叢集網路
最後一點是要正確配置連接埠來支援容器、工作負載群組(Pod)與服務之間的通訊。使用一個容器網路介面(CNI)讓使用者限制工作負載群組的流量,以確保Kubernetes網路模型的安全建置非常重要。趨勢科技在Kubernetes威脅模型指南一文當中提供了更多有關保護容器協調平台的詳細建議,有興趣的人可於趨勢科技官網搜尋閱讀。
容器防護
叢集內的容器要能執行,需要一個稱為「容器運行引擎」(Container Runtime Engine,CRE)的元件。儘管Docker是目前最流行的CRE,但Kubernetes也支援其他CRE,如containerd和CRI-O。在容器防護層次,企業要關心的主要有三個重點:
容器映像安不安全?
這一點基本上就是要確保容器隨時維持更新、沒有任何駭客可攻擊的重大漏洞。企業不僅要保護容器映像,還要確定容器內執行的應用程式都經過掃描及確認。雖然網路上有一些開放原始碼工具可以做到這點,但有些工具只能偵測作業系統的漏洞。要彌補這點,企業可採用一些能廣泛偵測各種應用程式漏洞的解決方案,例如Deep Security Smart Check。
容器是否可信賴?
目前系統上執行的容器是否是從自己的容器映像登錄檔(Registry)中產生?如何確保這一點?可利用一些映像簽署工具(如TUF或Notary)來簽署自身的映像,建立一套系統來維護你對容器的信賴。
容器執行權限是否恰當?
針對這點,可採取最低授權原則(能不開放的權限就不開放)。盡量以執行工作時所需的最低必要作業系統權限的使用者身分來執行自身的容器。如果想了解為什麼最好不要在Docker中執行特權容器以及駭客可能如何利用特權容器發動攻擊,可以至趨勢科技「資安趨勢部落格」搜尋「為何在Docker中執行特權容器不是個好主意?」以獲得進一步的了解。
程式碼防護
這一層防護又稱為應用程式防護,是企業最能掌控的一層。企業系統的主要核心就是系統程式碼以及相關的資料庫,而這些通常會暴露於網際網路上。所以,如果其他環節都找不到漏洞,那麼駭客就會以這一層為目標。當企業每天都有數十、數百、甚至數千名程式設計師在撰寫並部署程式碼到生產環境時,企業如何確保自己的應用程式碼都正確無誤、安全無虞?
首先,企業必須確保所有通訊都經過TLS加密,即使是在負載平衡器、應用程式伺服器、資料庫等這類內部服務中傳遞也一樣。若企業使用了Kubernetes之類的協調工具,那麼可考慮採用類似Istio或Linkerd的服務。
企業只須盡量減少並監控暴露在外的服務、連接埠與API端點裝置,就能大幅減少其系統的受攻擊面。此外,同樣重要的還有所使用的容器基礎映像,以及執行叢集的系統。
可在開發流程當中加入各種程式碼安全檢查來確保自身程式碼的安全性,例如以下幾種:
靜態應用程式安全分析
也就是「安全程式碼分析」或「程式碼稽核」,這仍是目前發掘程式碼資安漏洞最快也最有效的方法之一。不論使用的是何種程式語言,至少要在開發流程當中加入一種靜態分析工具,以便在開發人員送出新完成的程式碼時檢查是否有一些不安全的程式寫法。開放網站應用程式安全計畫(Open Web Application Security Project,簡稱OWASP)基金會製作了一份開放原始碼工具與商用工具清單,裡面介紹了各種專門用來分析原始程式碼與編譯後程式碼的工具,協助偵測程式碼的安全漏洞,也可以參考。
動態應用程式安全分析
雖然動態分析只能在應用程式執行時進行,但建議企業還是應該透過自動化的掃描與檢查來測試一些常見的應用程式攻擊手法,例如SQL資料隱碼攻擊(SQL Injection)、跨網站腳本攻擊(XSS)以及跨站請求偽造(CSRF)。這些工具還可測試你的應用程式、容器與叢集在面對一系列非預期性的負載或不正確的請求時是否會無法招架。OWASP也提供了一個叫做OWASP Zed Attack Proxy(ZAP)的工具,可加入開發流程中進行自動化動態分析。
軟體構成元件分析
約有70%至90%的雲端原生應用程式是由程式庫或第三方元件所構成。這些程式碼有的可能不是內部人員所撰寫,但卻會在生產環境中執行,它們通常不會做過靜態安全分析,因此可以利用OWASP相依性檢查之類的工具來檢查自身的程式碼當中是否含有老舊或含有漏洞的程式庫。此外,還有Snyk這個針對開放原始碼專案設計的第三方免費程式碼檢查工具。
結語
以上雲端原生系統的四個層次都是確保應用程式安全的重要關鍵,不論是哪一層的安全漏通,都會讓駭客有機會入侵整個系統。確保雲端原生系統的安全穩定,是將企業維持生產力的關鍵,而這最終將是企業生存的基礎。採用專為雲端設計的資安解決方案將有助於維護雲端原生系統及各層次的安全,舉例來說,趨勢科技混合雲防護是以Trend Micro Cloud One防護服務平台為基礎,能為CI/CD流程及應用程式提供自動化防護,此外,也有助於提早發掘及解決資安問題,加速DevOps團隊的應用程式交付時程。
<本文作者:趨勢科技全球技術支援及研發中心本文出自趨勢科技資安部落格,是由趨勢科技資安威脅研究員、研發人員及資安專家全年無休協力合作,發掘消費者及商業經營所面臨層出不窮的資安威脅,進行研究分析、分享觀點並提出建議。>