Docker容器技術將應用程序虛擬化,比起傳統熟知的虛擬器技術更加輕量,具備檔案小、執行效能高、服務啟用及部署速度高等優點,我們可以在相同的主機資源下,建立大量的容器服務。

近來,在各大資訊媒體中,經常可見到一隻藍色鯨魚載著一堆方塊的標誌圖案,這隻火紅的鯨魚商標是Docker公司,也成為現今廣為關注的容器技術(Container)代表標誌。

崛起中的容器技術

容器技術的存在時間不算短,但直至Docker平臺問世,將容器技術以更成熟且簡單方便的模式,帶入應用市場中,解決傳統在應用程式服務的開發、運行和部署之間的鴻溝瓶頸,進而提供一套有效完善的解決方案。

也因此,容器技術開拓了很多新的層面,例如:系統部署方式(輕量虛擬化、雲端應用、微服務、無伺服器、邊際運算等)以及應用開發方法(DevOps、CI/CD等)的改變,有如加裝噴射引擎般的推動,而獲得不少幫助。

除此之外,在2015年,微軟公司正式加入Docker容器技術的支援,過往在系統應用開發上,須面臨Linux與Windows這二大系統派別的選擇難題,如今得以解決,更遑論該項技術對於雲端平臺的相容性,而使其更加有彈性,這讓服務應用的設計、開發上,能免除以往諸多的執行環境限制與困擾。

簡而言之,容器技術是一種輕量的虛擬化方式,它將運行一個系統或應用程式所需的必要作業系統核心、程式編譯及函式庫等,進行打包封裝,而其餘的部分,則共用底層作業系統資源,至於Docker平臺本身,則是銜接各個容器與主機作業系統之間的控制器。

基本上,容器技術跟市場熟知的VM(Virtual Machine)虛擬器技術,是不一樣的技術概念跟應用情境。我認為,若以簡單的界分方式來看,對於以應用服務為主要任務目標,Container容器技術是最佳的選擇方案,而對於以基礎架構為主要需求的使用場景,VM虛擬器則是比較好的選擇。

透過圖解,我們可看到VM虛擬器與Docker容器技術的架構差異,基本上,VM虛擬器的結構是比較能夠被理解的,可簡單認知為:把一臺實體模式的伺服器主機,轉換成邏輯的虛擬系統主機,因此,在諸多資安風險、攻擊威脅、甚至修補防護機制的運用上,多半可以直接套用思考模式;但容器技術的架構,則是應用服務環境虛擬化的概念,可視作依據特定應用程式為主的安全固化(Harden)、且系統環境可經過優化包裝,甚至更為單純。

Docker容器可能的資安風險

Docker容器技術是將既有的應用程序及系統模式重新建構的新模式,因此,仍舊可能遭受來自不同維度的已知資安攻擊威脅。對此,OWASP組織建立OWASP Docker Top 10的安全控制建議。 資料來源OWASP- Docker Security 2017

Docker所引領出的容器技術,確實帶來許多的革新與方便,但是其存在的安全風險則仍被持續發現探索中。接下來,僅以Docker為容器技術代表,分析容器技術應用的資安風險。

如前面所提到,容器技術也是虛擬化的一種方式,但由於容器的技術架構有別於傳統作業系統及VM虛擬器,因此,對於相同類型的資安風險及威脅手法,則必須以容器技術結構來審視思考。

我們可以OWASP於2017年的一份Docker Security報告中,看到可能的攻擊維度,大致可從Docker容器技術的主要結構來分析,包括:基礎層的系統主機(Host)、運行的主體Docker系統、封裝的容器檔、以及系統應用程序之間的溝通運行,共四個層面;但Docker容器技術的應用,並不單單只是提供另一種虛擬化方式,而是因為Docker容器技術的可控性及可標準化,進而應用在持續性整合與交付(CI/CD)及軟體敏捷開發流程(DevOps),因此,Docker容器的系統結構一旦發生安全問題,將嚴重影響整個應用服務的安全可靠性。以下我將從4大層面,逐一討論存在的資安風險威脅。

1.基礎架構及作業系統層的保護

Docker容器系統與服務,仍需在基礎架構以,及作業系統(Linux或Windows)上建立,以及運行,因此,對於傳統的網路通訊管控、漏洞掃描修補、系統存取控制及帳號權限管控等,都是基本必要的安全項目,否則駭客一旦「放大絕」,將運行Docker容器服務的整個基礎架構,以及作業系統,進行提權控制或毀損侵害,結果就如同整個機房毀損故障的慘狀。

不過,如同前述所言,Docker容器是將應用程序為主的輕量虛擬化方式執行,換句話說,作業系統本身就不需要安裝,以及存在該支應用程序,所以,在安全檢測與管控上,將可以更明確的界分。

舉例來說,過往建立一個網站應用服務時,必須在作業系統上安裝Apache程式或啟用IIS元件,所以,當作Apache或IIS存在安全風險時,就會發生對作業系統交互影響的威脅。但是,如果改為利用Docker容器服務時,Apache及IIS是以應用程序虛擬化的方式存在,此時,對於作業系統的安全性影響有限。

2.Docker平臺的保護

由於Docker是容器掛載運行的控制平臺,因此,Docker系統本身的安全性更顯重要。以今年初揭露的相關新聞「容器執行元件runC含有容器逃逸漏洞(CVE-2019-5736)」為例,包括:Docker、containerd及CRI-O等支援runC標準化的容器平臺,都受到波及,同時,也影響多個雲端服務平臺(GCP、AWS、Red Hat),以及數個Linux發行版。

在這個漏洞當中,允許惡意容器透過該漏洞覆蓋runC的二進位檔案,並取得容器主機端的最高權限而得以執行命令。此外,這個漏洞的POC(概念性驗證)也已經出現漏洞利用的程式碼,並發布在GitHub,這意謂已是可被實作的攻擊威脅。

除了Docker系統本身的安全外,管理者也必須避免將root權限共用於容器服務,因此,需將容器的root使用者,改對應到本機上的非root使用者,並且只允許Docker系統在非root權限下執行,僅限縮在特定的操作設定方面(例如:虛擬網路設定、檔案系統管理、配置操作等)。

3.容器資源的保護

Docker Hub為Docker官方維護的公開映像檔倉庫,已有超過100,000個容器映像檔可供利用。它們來自各大型商業軟體廠商、開源軟體及社群組織,除了Linux 版本的作業系統及應用程式外,也包括Microsoft版本的多項企業主要應用程式(例如,MS SQL、IIS、ASP.NET等);使用時,建議選擇官方釋出或經過驗證的容器映像檔版本為佳。

容器資源所指的部分,是將特定應用程式系統封裝好的映像檔。這些映像檔的來源,除了使用者自己建立之外,目前絕大多數會取用來自於外界已經封裝好的版本使用。一般而言,我們可以到Docker Hub搜尋資源,並佈建於Docker平臺上使用,也可以再加工封裝成自己所需要的版本。

不過,根據Snyk資安公司於2019年所發布的《The State of Open source Security Report》」當中提到,他們掃描了Docker Hub中10個最受歡迎的Docker映像檔,結果發現當中的每一個映像檔,都包含了存在不少漏洞的系統函式庫。

因此,我建議各位在選擇容器資源時,應以DockerCertified或是已經被驗證過的發布者(Verified Publisher)及官方公布的容器映像檔為佳,並且是取得最近更新的版本。

此外,如果企業是自建容器映像的Private docker registry登錄,加以管理,本身除了做好對此的存取權限管控外,對容器映像檔進行弱點掃描及惡意程式檢測的作業,應該透過自動化的方式來進行,以確保容器遭受竄改,並避免有問題的容器被啟用服務。

4.操作權限的保護:

Docker容器的操作權限,可概分為二者:Docker系統自身及容器服務。Docker系統自身的操作權限安全,我在上述第二點已經提到;而容器服務的部份,本身則是一個應用程序的虛擬體,所以自身除了已封裝在內的應用程序及相關系統資源以外,基本上,不需要真正的root權限。舉例來說:

  • ssh存取是由系統主機的ssh服務管理,所以,容器並不特別需要root權限。
  • cron是用作排程執行,其權限是交由主要使用cron服務的應用程式處理,所以,容器並不特別需要root權限。
  • Syslogd服務為日誌系統,主要由Docker系統或第三方服務管理,所以,容器並不特別需要root權限。
  • 硬體管理及網路設定等部分與容器無關,所以,容器也不需要執行udevd或類似的服務。

因此,容器真正要做好的部分,就是自身的應用程序服務,對於Docker容器管理者及使用者而言,應該盡量避免不必要的權限。我建議,應注意以下的容器權限管制:

  • 限制任何檔案掛載操作(可利用Data Volumes及Data Volumes Containers)
  • 限制直接存取本機的Socket通訊
  • 限制檔案系統操作、新增裝置、修改檔案屬性等
  • 限制載入核心模組

實施上述作法的目的,是為了避免駭客取得容器中的root權限時,仍無法取得本機系統的最高權限,藉此降低威脅風險。當然,在一些特殊的容器應用下,還是需要開放部分的特殊權限,不過,容器的權限設計上,的確比傳統模式更容易區隔。

以Oracle、MySQL、MS SQL等資料庫系統為例,在傳統使用模式下,往往DBA要求系統管理者提供系統最高權限,以確保資料庫系統運行的各種情況;但在容器服務的環境下,則能夠提供一個更妥適的方式。

此外,由於容器服務之間,主要透過API的方式來相互溝通,以構成完整的應用服務,所以,我們也必須確保,容器服務之間是以TLS v1.1以上安全驗證方式來通訊。整體而言,這些都是強化權限安全的方法。

快速認識容器技術與Docker

容器的概念,可追溯於1979年時Unix系統中的Chroot功能設計,發展至LXC(Linux Container)做為容器技術概念的實現。隨著Linux CGroups及Namespace等技術的發展而變得更完整。

之後,在2013年DotCloud(即Docker公司前身)所推出的開源容器Docker後,開始點燃容器技術的熱潮。

雖然最初容器技術以Linux系統環境為主,但在2015年,微軟也在Windows Server加入容器技術,並且正式提供Windows系統環境的容器支援。

建立更敏捷快速的資安反應

Docker容器技術是個非常有趣的新趨勢,幾乎對於近幾年所討論的議題,如SDN、Cloud Services、IoT、Micro Services、DevOps,以及Serverless、Edge Computing,似乎都可以利用容器技術,設計出更敏捷、方便、好操控的架構。

因此,在Docker容器的「創建階段」到「交付上線」過程中,我建議,以系統發展生命周期(SDLC)來確保應用服務的安全可靠性,但由於容器技術更著眼於敏捷速度(畢竟,應用程式開發跟環境設定條件已經由開發者配置好,而維運單位則是提供容器運行的基礎資源配置)所以,前端及後端的作業如果都依照前述方式準備好,此時,唯一必須要確認的部分,就是交付上線前的安全檢測。

為了避免此一作業過程耗時費工(以傳統方式而言,需進行弱點及安全檢測後,再由開發者、系統及網路管理者,進行多方討論與改善修正),所以,檢測作業也必須具備敏捷快速的方式,以自動化整合在SDLC流程中,發現容器映像檔存在問題元件及惡意程式,則自動通報或退回開發者,進行重新調整封裝;當完成交付上線後,則持續針對啟用的容器服務進行安全監測,一旦後續又發現新暴露的漏洞利用,則自動通報與進行政策控制。

駭客攻佔目標時間越來越短,防守端的資安反應須更敏捷

由於Docker容器技術是應用程序的虛擬化,在程式碼更換異動時,可確保應用服務持續可用,並且不會與底層系統核心及相依服務元件有太多的瓜葛,所以,對於版本更新汰換作業上,可提供更便利的作業方式。

過往大多數的資安事件都是肇始於「存在安全問題的版本更新修補不易」的因素,因而讓駭客有充足時間執行。更可怕的是,根據近期美國資安業者CrowdStrike的資料,各國駭客從外部入侵目標系統至成功達陣所需時間,俄羅斯駭客集團Bear,僅用了18分鐘,次者為北韓駭客集團,也僅需2小時多,而這樣的攻擊速度,非常值得我們再次深思自身的資安反應敏捷性。文☉創泓科技資深技術顧問Jim Huang本文出自《iThome 2019臺灣資安年鑑》


Advertisement

更多 iThome相關內容