【關鍵資安議題：容器安全】剖析容器的資安風險與防護

近來，在各大資訊媒體中，經常可見到一隻藍色鯨魚載著一堆方塊的標誌圖案，這隻火紅的鯨魚商標是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臺灣資安年鑑》