消除IaC資安風險　五措施建立實務應用原則

由於IT基礎架構所承受的要求以及持續整合／持續交付（CI/CD）流程的風險不斷升高，因此，一致而可擴充的自動化顯得日形重要。這就是「基礎架構程式碼」（Infrastructure as Code，IaC）所扮演的角色。IaC是一種利用機器可解讀的檔案格式來配置、設定與管理基礎架構的實務方法。有別於手動設定企業內及雲端環境的作法，系統管理員和系統架構師可透過IaC來將上述工作自動化。IaC與基礎架構服務（Infrastructure as as Service，IaaS） 兩者絕配，而且也廣獲眾多企業採用，不僅可加速開發及擴充雲端環境，又能降低成本。 在概念上，IaC類似撰寫腳本協助IT流程自動化，不過IaC採用描述性語言來實現更彈性地資源配置與部署（也就是由軟體本身來負責啟動基礎架構變更），而且IaC對雲端運算與DevOps尤其重要。

IaC工具大致可分成兩類：一種是協調工具，用來配置、組織與管理基礎架構元件（如CloudFormation與Terraform）；另一種是組態管理工具，用來安裝、更新、管理基礎架構元件內所執行的軟體（如Ansible、Chef、Puppet與SaltStack）。這類工具可讓開發人員和雲端架構師消除一些容易出錯的手動流程，讓大規模的組態設定與管理作業得以簡化。

實務上的資安風險

然而，採用IaC來加快CI/CD週期的循環，卻也帶來了一些挑戰。譬如，IaC工具若存在尚未修補的漏洞，很可能將成為威脅入侵基礎架構的破口。這些漏洞會讓駭客避開一些程序、在已遭駭入的伺服器上執行程式碼，甚至植入一些虛擬加密貨幣挖礦程式。IaC範本若組態設定不當，也可能造成一些敏感資料外洩，或造成資安缺口讓駭客入侵。

機密資料的儲存

IaC一般的作法是使用一個應用程式來管理多個環境，並使用組態設定檔案來描述如何管理這些環境，組態設定檔案的內容採用程式碼的型態（所以才有惡意程式碼的問題），IaC應用程式會在目標環境中執行這些程式碼。IaC應用程式描述目標環境的方式各有不同，通常包括組態設定本身、儲存，以及一些機密資料 （Secrets），這些是連上託管基礎架構的必要資訊。

機密資料的儲存方式與其所保管的敏感資料同樣重要，如應用程式認證金鑰、SSH金鑰、密碼等等。將這些資料儲存在原始程式碼管理（SCM）系統（如Git）或儲存在純文字檔案內，都是危險的作法，而且從資安角度來看更是不負責任的作法，因為很容易發生外洩。有些殭屍網路專門在網路上搜尋公開的SCM網站，尋找可以立即使用的機密資料，進而駭入基礎架構（例如植入挖礦程式）。所以建議採用一套金庫系統來儲存這些機密資料，然後在組態設定中參照這些資料就好。

主節點（Master）通訊管道

有些IaC組態設定管理工具（如SaltStack）的設計架構當中包含了所謂的主節點（Master Node），負責管理所有其他節點。一般而言，從單一節點（也就是主節點）存取被管理的整個基礎架構時，保護這個單一節點就非常重要，因為它包含了基礎架構與部署環境的所有細節，一有任何閃失，整個基礎架構都會遭殃。

所以，雲端內若能採用一些預先準備好的環境，就能降低因為組態設定錯誤或者每次都從頭設定組態而導致的風險。

主節點需要一個安全的通訊管道來與被管理的節點溝通，其管理的方式大致分成兩種：

1.在被管理的節點上安裝一個客製化代理程式來執行管理工作。

2.使用一般常見的軟體與通訊協定來管理節點（也就是「無代理程式」的作法），例如透過SSH通訊協定來執行Bash腳本。

從資安角度而言，使用客製化網路通訊協定會多增加一個受攻擊面，甚至帶來更多漏洞，例如有些資料中心與雲端伺服器上使用的SaltStack軟體，其Salt管理架構中就被發現了CVE-2020-11651和CVE-2020-11652兩個漏洞。

CVE-2020-11651是其客製化網路通訊協定處理上的漏洞，可能讓未經認證的使用者在整個基礎架構內執行遠端程式碼（RCE）。至於CVE-2020-11652則是一個路徑瀏覽漏洞，可讓不特定的第三者讀取任意檔案。這兩個漏洞都能讓歹徒取得系統管理金鑰（Root Key）來進入主節點，進而存取整個基礎架構。由於SaltStack的漏洞太過敏感，使得發現這些漏洞的研究人員決定不對外公開任何概念驗證程式碼。

網路犯罪集團的腳步很快，早已鎖定這類基礎架構管理平台，例如有許多雲端伺服器感染了虛擬加密貨幣挖礦程式，造成一些Salt運算實體的CPU用量飆高，使得系統超載。此外，駭客也曾經處心積慮試圖透過某個重大漏洞來取得某憑證透明化（CT）伺服器的簽署金鑰。（如需有關CVE-2020-11651與CVE-2020-11652的詳細分析，請參閱https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/coinminers-exploit-saltstack-vulnerabilities-cve-2020-11651-and-cve-2020-11652）

使用者權限

使用者權限是另一項資安問題，如果IaC應用程式只是用來管理應用程式的部署，那麼應該不太需要目標系統的管理員（Root）權限。採用最低授權原則雖然有一定的麻煩，但卻能降低遭駭客入侵的風險。同樣原則也適用於部署在Amazon Web Services（AWS）公有雲內的環境，專為特定用途（例如啟動預先準備好的虛擬機器）而設立的帳號或角色，其權限應該受到限制。使用具備系統管理權限的雲端帳號登入憑證來執行一些權限較低的工作，是一項危險的作法。

IaC範本

IaC範本的作用是用來配置與管理雲端基礎架構，進而達成部署的靈活性。IaC範本是機器可閱讀的定義檔，用來建立環境並從外部執行程式碼。然而這些範本並非毫無風險，由於它們是IaC流程的一環，而且可能不小心用到來自非信賴來源的作業系統與容器映像，因而招來一些後門程式與挖礦程式之類的威脅。

此外，IaC範本也可能含有一些漏洞和不安全的預設組態而使得資料發生外洩。這些漏洞又進一步對IaC部署的雲端基礎架構與所儲存的資料造成更大風險，尤其是非必要地公開暴露在網際網路上。所以，企業應在開發流程的早期就預先檢查IaC範本是否有不安全的組態設定或其他的潛在弱點。此外，更應透過某種雲端資安狀態管理服務來定期掃描，以發掘並矯正組態設定錯誤。

主要重點與最佳實務原則  

IaC的作用是用來部署及管理基礎架構，包括資料庫、網路伺服器、服務以及虛擬機器，這是DevOps實務中實現軟體開發靈活性很重要的一環。IaC有助於加快開發速度，提升基礎架構的管理效率。在沒有IaC時，開發人員和IT團隊必須手動維護每個部署環境的組態設定，而手動作業很容易造成部署上的不一致與資安問題。

有了IaC之後，基礎架構的詳細內容會定義在文字檔內（其形態是程式碼）。雖然這樣可以讓使用者指定詳細的屬性內容，但若處理不當，卻可能造成安全問題。組態設定錯誤是雲端環境的一大資安問題，同樣情況也發生在IaC工具。企業若對IaC流程的資安意識不足，將導致整個基礎架構遭駭客入侵。

為了確保混合雲與公有雲環境的安全，我們建議採取以下措施：

•可能的話，盡量採取最低授權原則，能不開放的權限就不要開放。雲端服務的帳號權限必須受到限制，尤其是公有雲供應商的帳號，必須限制帳號與工具的存取權限以防止駭客入侵各個節點。如此就能安全地儲存IaC組態設定，並防止資料外洩。

•使用IaC資安附加元件。整合式開發環境（IDE）的資安附加元件可在IaC範本部署之前預先防範潛在問題。

•將基礎架構軟體更新到最新版本。企業應該在廠商釋出安全更新時就立即套用（前文提到的Salt漏洞目前已經釋出安全更新）。

•請勿讓中央系統暴露在外。中央伺服器不應暴露在網際網路上，這樣才能避免萬一遭到駭客入侵時擴散到下游單元。

•提升安全與法規遵循狀況。企業應建置能夠偵測雲端服務供應商組態設定錯誤的即時防護，以確保流程安全。此外，具備自動矯正功能的解決方案也有助於修正問題。

＜本文作者：趨勢科技全球技術支援及研發中心本文出自趨勢科技資安部落格，是由趨勢科技資安威脅研究員、研發人員及資安專家全年無休協力合作，發掘消費者及商業經營所面臨層出不窮的資安威脅，進行研究分析、分享觀點並提出建議。＞