什麼是 GitLab IaC 掃描？

基礎架構即程式碼（IaC）已迅速成為現代技術版圖中的變革力量。透過將基礎架構佈建與管理流程轉換為程式碼，開發人員可獲得版本控制與可重複性，並降低潛在弱點，但隨著其普及，也帶來了潛在的弱點問題。

GitLab IaC 掃描 是一種有效且高效率的方法，可用於發現 IaC 設定中的錯誤設定與安全缺口，並加以防護。本指南將深入探討其價值、設定流程與最佳實務，以強化 IaC 設定。

什麼是基礎架構即程式碼（IaC）？

基礎架構即程式碼（IaC）是一種方法，將基礎架構佈建、管理與設定工作以程式碼形式指定，而非透過手動流程或自訂指令碼完成。IaC 不依賴手動流程來佈建伺服器、資料庫或網路基礎架構元件，而是使用標準程式碼範本。

IaC 的普及可歸因於部署與擴展應用程式時對敏捷性的需求持續增加。傳統基礎架構管理需要耗時的設定，且經常依賴容易出錯的人工作業；IaC 透過像軟體程式碼一樣對基礎架構進行版本控制，提供一致性、可重複性與快速更新流程，使具版本控制且可重複的基礎架構建置能持續執行，而無需人工監督或承受人為錯誤。

DevOps 實務也與 IaC 實務高度協同，有助於組織彌合開發與營運之間的落差。透過 IaC，可與應用程式開發同步實施基礎架構變更，以加快部署速度並讓管線管理更順暢。兩者的結合可推動組織在部署流程中提升效率與可靠性。

為什麼 IaC 掃描至關重要？

基礎架構即程式碼開啟了新的潛在弱點途徑。撰寫指令碼以自動化基礎架構部署的開發人員，可能會在無意間將重大的安全缺口引入基礎架構部署流程；IaC 掃描 因此成為在這些安全漏洞進入正式環境之前偵測它們的必要手段。

現代雲端原生基礎架構可能是相當動態且複雜的環境；即使是最警覺的開發人員，也可能遺漏錯誤設定，而若沒有 IaC 掃描工具檢視程式碼定義以偵測違反安全最佳實務的錯誤設定，便難以降低因基礎架構弱點導致的資料外洩與系統遭入侵風險。IaC 掃描工具使用 Artificial Intelligence-as-a-Consumption technology (AIC)。藉此，它們可大幅降低與基礎架構弱點導致資料外洩或系統遭入侵相關的風險。

隨著法規遵循與資料保護標準日益嚴格，企業需要從第一天起就實施安全的基礎架構，以避免法律或聲譽上的影響。IaC 掃描可協助企業遵循此一標準，確保其基礎架構符合產業法規，進而保護自身免於法律後果。

了解 GitLab IaC 掃描

GitLab 的基礎架構即程式碼（IaC）掃描功能提供系統化的方法，用於檢查 IaC 設定檔是否存在潛在弱點。這可確保用於佈建與管理基礎架構的設定具備穩健性、安全性與合規性。其支援範圍涵蓋多種 IaC 設定檔，包括 Terraform、Ansible、AWS CloudFormation 與 Kubernetes 等常見類型。

1. 需求與相容性
2. 支援的檔案與自訂
3. 設定與規則自訂
4. 自動弱點修復

1. 需求與相容性

有效的 IaC 掃描 需要在 test 階段中運作，因為必須將其納入該階段的.gitlab-ci.yml 檔案中。

• 最低 RAM 需求應為 4GB，以達到最佳效能。 
• 依預設，必須使用搭配 Docker 或 Kubernetes executor 的 GitLab Runner（且對 GitLab.com 使用者會自動啟用）。不過，IaC 掃描分析器可能與非 amd64 CPU 架構不相容，且建議避免在這些工作中使用 Docker 版本 19.03.0。

2. 支援的檔案與自訂

GitLab IaC 掃描透過 KICS 工具提供全面支援。支援的設定檔包括來自 Ansible、AWS CloudFormation、Azure Resource Manager、Dockerfile、Google Deployment Manager、Kubernetes、OpenAPI、Terraform 等；在檢閱結果時，也應考量特定需求，例如 Azure Resource Manager 範本必須為 JSON 格式，以及不支援自訂 registry Terraform 模組。

GitLab 透過此功能持續展現其對開放性的承諾，將所有開源（OSS）分析器提供於 GitLab Free 方案中。透過操作 SAST_IMAGE_SUFFIX 變數，您可以在映像檔的標準版本與 FIPS 版本之間切換。

3. 設定與規則自訂

在您的專案中建立 IaC 掃描相對直接。您可以透過納入 SAST-IaC.gitlab-ci.yml 範本手動設定；納入後，會在您的 CI/CD 管線中產生 IaC 掃描工作，或透過 merge request 自動設定——IaC 掃描工作的結果會在掃描完成後儲存為 SAST 報告成品。

希望強化掃描流程的團隊可選擇自訂預設規則；此功能包括能夠：

• 停用預先定義的規則。 
• 以自訂定義覆寫現有規則，影響嚴重性等層面，或直接連結至個人文件。

也可以將掃描流程與特定分析器版本建立關聯，以在更新帶來回歸問題或不必要修改時提供保護。

4. 自動弱點修復

GitLab IaC 掃描強調消除報告中不必要的雜訊。為了維持相關性並聚焦於目前的弱點，系統會採取某些自動化動作：

1. 停用規則：一旦您判定一或多項規則不再與您的專案相關，並明確將其停用，先前由這些規則回報的弱點將自動獲得修復。

2. 移除規則：若 GitLab 判定一或多項預設規則已過時或產生過多誤判，則很可能會將其移除，而由這些規則標記的任何弱點也將自動獲得修復。

3. 歷史記錄：維持稽核軌跡至關重要；GitLab 的弱點管理系統會新增註解，確保您仍能掌握過去已自動化處理並修復的弱點。

4. 重新啟用規則：重新啟用先前停用的規則，將會重新開啟任何已自動修復的發現以供再次分類處理，確保過去的弱點不會未被偵測。

報告：了解 JSON 格式

GitLab 的 IaC 掃描工具會將其發現輸出為結構化 JSON 報告，以符合 SAST 報告格式，為使用者提供全面的結果：

1. 標準化: 此格式有助於在各種專案或掃描之間輕鬆整合與比較。

2. 可存取性: 使用者可以使用 artifacts: paths 指示詞直接從 CI pipelines 頁面或 merge request pipelines 快速且輕鬆地下載報告至 “gl-sast-report.json”。為了便於執行此操作，請將您的 artifacts: paths 指示詞設為 “gl-sast-report.json”。

3. 結構描述參考: GitLab 提供詳細的結構描述文件，讓有興趣深入研究或將此報告與其他系統整合的人員，能夠輕鬆且全面地存取其所有部分。

設定 GitLab IaC Scanning

讓我們來看看如何為您的專案設定 GitLab IaC Scanning。

設定 GitLab IaC Scanning 的步驟如下 –

1. 先決條件
2. 整合 GitLab CI/CD
3. 自訂設定（選用）
4. 執行掃描
5. 檢視結果

1. 先決條件

• GitLab 版本：您應確認使用的是 12.10 或更新版本的 GitLab。 
• 存放庫設定：您的 Infrastructure as Code 檔案（例如 Terraform、CloudFormation 和 Kubernetes 設定檔）應為您存放庫的一部分。

2. 整合 GitLab CI/CD

若要設定 IaC 掃描，您需要將其整合至 GitLab CI/CD pipeline。

在您存放庫的根目錄中建立或更新 .gitlab-ci.yml。

新增以下設定：

Include:

  template: Security/Infrastructure-Scanning.gitlab-ci.yml

此包含項目將在您的 CI/CD pipeline 中啟用 IaC Scanning 工作。

3. 自訂設定（選用）

對於具有特定需求的專案，可自訂掃描流程：

• 自訂規則：GitLab IaC Scanning 允許使用者定義自訂規則或修改現有規則。這些規則可新增至您存放庫根目錄中的 .iac-custom-rules 目錄。

• 忽略目錄：如果您希望掃描器略過某些目錄，可以在 variables: 下方的 CI/CD 設定中定義它們：

Variables:

  IAC_PATHS: “infrastructure/*,!infrastructure/legacy/”

在上述範例中，掃描器只會分析 infrastructure 目錄中的檔案，並排除 legacy 子目錄。

4. 執行掃描

設定完成後，啟動一次 CI/CD pipeline 執行。IaC Scanning 工作將分析您的 Infrastructure as Code 檔案，並提供潛在弱點的洞察。

5. 檢視結果

分析後，弱點（若有）將顯示於：

• merge request 內（如果掃描是由其觸發）。
• 您專案的 Security & Compliance 區段中。

您可以在這裡：

• 查看弱點詳細資訊。
• 將其標記為已解決，或建立 issue 以追蹤它。
• 視需要根據弱點嚴重性或類型設定自動化動作。

安全 IaC（Infrastructure as Code）設定的最佳實務

安全 IaC（Infrastructure as Code）設定的最佳實務如下 –

1. PoLP 原則（最小權限原則）
2. 維護版本控制與變更追蹤
3. 定期掃描並更新相依性
4. 保護機密資訊
5. 有效驗證與評估設定

1. PoLP 原則（最小權限原則）

The 最小權限原則 是一項重要的安全概念，旨在確保實體（無論是使用者、系統或程序）僅獲得執行其任務所需的權限，而不多不少。在可透過程式指派權限的 IaC 環境中，這項原則更顯重要；若權限授予錯誤或範圍過廣，可能會使資源暴露於不必要的風險之中。

在 IaC 中遵循 PoLP 要求，需要仔細編寫權限腳本，使每項服務或功能僅能存取其所需的資源——對於 AWS 等雲端基礎架構而言，這可能表示僅授予 S3 bucket 唯讀權限，而非對所有儲存資源授予全面權限；並持續審查 IaC 腳本，以確保隨著基礎架構演進，權限仍維持最小化。

2. 維護版本控制與變更追蹤

版本控制不僅是傳統軟體開發所必需；它在 IaC 環境中的基礎架構管理也扮演關鍵角色。追蹤變更、回復組態，以及理解基礎架構調整，對於維持安全且穩定的 IaC 基礎架構管理環境至關重要。

用於 IaC 組態的 GitLab 與 GitHub 平台不僅提供變更追蹤工具，也提供協作功能，讓團隊成員可在部署至正式環境前審查擬議的修改。此同儕審查流程可確保在將任何重大修改導入 IaC 環境之前，已考量安全疑慮並符合最佳實務。

3. 定期掃描並更新相依性

與軟體開發相同，基礎架構即程式碼（IaC）組態通常依賴第三方範本與模組來簡化基礎架構部署；雖然這類相依性可讓部署更簡單，但若已過時或遭到入侵，也會帶來潛在弱點。

持續掃描相依性有助於確保不會將已知安全弱點引入基礎架構，專為此任務設計的工具可自動標示過時或有弱點的模組，並提示團隊依需求更新它們——這很像軟體修補程式管理，但特別套用於基礎架構模組，以達到最大程度的防護與韌性。

4. 保護機密

數位環境中充斥著因機密外洩而導致嚴重入侵事件的警示案例。IaC 的程式化特性，容易讓程式設計人員想直接將敏感資訊硬式編碼到腳本中——這是一種不負責任且應始終避免的做法。

組織應避免將機密直接嵌入 IaC 腳本，而應改用 HashiCorp Vault 或 AWS Secrets Manager 等專用機密管理解決方案來保護機密，並使其維持加密狀態，從而確保即使組態檔案公開暴露，也仍能受到保護。

5. 有效率地驗證與評估組態

確保 IaC 腳本兼具功能性與安全性是一項持續性的工作，需要定期評估。隨著組態變更或 IT 環境轉變，新的弱點會浮現，可能使先前可正常運作的腳本失效，甚至完全中斷。

組織應確保其 IaC 組態定期符合產業基準與最佳實務，以避免這種情況發生，並使用自動化測試工具進行定期檢查而無需人工介入。在將任何變更推送至正式環境之前，預備或測試環境在提供任何非預期問題的早期警示方面極具價值，有助於確保正式環境中的基礎架構既安全又可運作。

IaC 中的常見陷阱及其避免方式

GitLab IaC Scanning 中的常見陷阱及其避免方式？

1. 將基礎架構程式碼視為一次性腳本
2. 忽略測試
3. 硬式編碼機密與認證資料
4. 過度複雜化 IaC 腳本
5. 繞過已淘汰的工具或程式庫

1. 將基礎架構程式碼視為一次性腳本

對基礎架構程式碼（IaC）的一個常見誤解，是將其視為只寫一次且很少再回頭檢視的一次性腳本。然而，IaC 不同於一次性腳本，它與任何軟體程式碼一樣，需要定期維護、更新與修訂。

如何預防：使用 GitLab IaC Scanning 等工具持續掃描 IaC 組態，並定期進行程式碼審查與更新——這可確保您的程式碼保持最新、具相關性，且不含潛在弱點。

2. 忽略測試

某些急於部署的團隊可能會跳過完整的 IaC 腳本測試，以換取更快的速度——認為只要能執行，一切就沒問題——這可能導致其佈建的基礎架構出現非預期行為或安全弱點。這種疏忽可能使非預期行為未被納入考量，或造成在部署後需要立即修補的安全漏洞。

如何預防：與應用程式程式碼相同，在 staging 等非正式環境中測試 IaC 組態，對於避免正式環境中的錯誤組態與潛在陷阱至關重要；GitLab IaC Scanning 在此提供關鍵功能，讓團隊能在問題直接影響正式環境之前識別任何錯誤組態。

3. 硬式編碼機密與認證資料

硬式編碼是 IaC 腳本中明顯的陷阱，為保護資料安全，應始終避免。若直接將機密或認證資料嵌入程式碼中，硬式編碼的機密或認證資料可能構成重大安全威脅，不可忽視。

如何預防：不要直接在腳本中包含機密，而應使用專用的機密管理工具。GitLab IaC Scanning 工具可能會在掃描流程中偵測此類做法，例如提醒開發人員其組態檔案中存在任何硬式編碼的認證資料。

4. 過度複雜化 IaC 腳本

有些工程師在撰寫 IaC 腳本時，試圖打造一套涵蓋所有可能情境的解決方案，因而使內容變得過度複雜。雖然這可能更有效率地涵蓋各種情況，但也會在其 IaC 解決方案中造成不必要的複雜性與潛在故障點。

如何預防：使用 GitLab IaC Scanning 將複雜組態拆分為可管理的模組，並優先考量簡潔與清晰；定期使用 GitLab IaC Scanning 檢查這些模組，使其持續有效、安全且可運作。

5. 繞過已淘汰的工具或程式庫

IaC 經常依賴第三方工具或程式庫；然而，隨著這些外部資源發展，某些特性或功能可能會被淘汰。使用過時的方法可能帶來功能性與安全性弱點。

如何預防：主動關注您的 IaC 組態所依賴的任何第三方工具或程式庫，定期更新腳本以反映最新版本與建議，並使用如 GitLab IaC Scanning 之類的掃描工具來標示過時的功能或相依性。

See SentinelOne in Action

Discover how AI-powered cloud security can protect your organization in a one-on-one demo with a SentinelOne product expert.

Get a Demo

結論

GitLab IaC 掃描可偵測安全缺口並處理相依性。您可以消除誤判、設定自訂規則，並維持稽核軌跡。它也讓報告作業方便許多，且您可以輕鬆將 GitLab IaC 掃描整合至您的 CI/CD 管線中，以獲得最佳成效。使用 GitLab IaC 掃描器保護機密資訊、維持版本控制與變更追蹤，並套用最小權限存取原則。它將協助您有效率地評估與管理您的組態，讓基礎架構管理更加順暢。