什麼是不安全的系統組態?

不安全的系統組態是 OWASP Top 10 CI/CD 安全風險之一。當 CI/CD 系統以次佳或預設的組態進行部署時,就會產生這個問題。它可能包括不必要的開放連接埠、預設憑證、未修補的系統、分隔不佳的網路或停用的安全性功能。這些漏洞會使系統面臨未經授權的存取,並增加惡意軟體的傳播和惡意程式碼注入部署程序的可能性,最終導致資料外洩和業務運作中斷。不安全的組態也可能導致合法的 CI/CD 程序被濫用,使攻擊者得以操控工作流程並取得生產環境的存取權。

 

CICD-SEC-7:不安全系統組態說明

不安全的系統組態代表著重大的安全風險。它產生於整個管道中各種系統的安全設定、組態和加固的缺陷,例如原始碼管理 (SCM)、CI 系統和程式碼儲存庫。這些弱點往往容易成為攻擊者的目標,讓他們試圖擴大在環境中的攻擊範圍。

來自不同廠商的多個系統構成了 CI/CD 環境。為了強化 CI/CD管道的 安全性,不僅要專注於流經管道的程式碼和工件,還必須關注每個個別系統的立場和彈性。

與資料儲存和處理系統相似,CI/CD 系統涉及應用程式、網路和基礎架構層級的許多安全性設定和組態。這些設定在決定 CI/CD 環境的安全勢態及其對潛在攻擊的敏感度方面扮演重要角色。

攻擊者會尋找 CI/CD 漏洞和設定錯誤加以利用。潛在的硬化缺陷包括

  • 執行過時版本的系統
  • 網路存取控制過度放任的系統
  • 具有底層作業系統管理權限的自我託管系統
  • 憑證衛生不良

已定義系統組態

系統組態是指設定系統和服務、定義系統和服務的互動方式,以及建立系統和服務運作規則的過程。這包括設定硬體、安裝和設定軟體,以及建立網路連線。由於組態過程會對系統的功能、效能和安全性造成重大影響,因此正確完成組態並維持其最佳化狀態至關重要。

安全系統組態的元件

安全組態包括正確設定系統參數、管理存取控制,以及為 CI/CD 管道的基礎系統實作安全措施。這樣的配置可以降低未經授權存取的風險,並預防利用構成開發環境主幹的系統中的漏洞。

CI/CD 環境的複雜性源自於 CI/CD 環境,因為系統組態超越了個別系統,延伸到管道中使用的工具、服務和平台之間的互連。毫不奇怪,有效且安全的系統組態的主要組成部分是嚴格的組態管理。

CICD-SEC-7 如何發生

不安全系統組態的根本原因通常指向人為錯誤、缺乏適當的程序或對安全需求了解不足。這可能是由於簡單的原因,例如未變更預設設定、允許過多權限,或疏於更新和修補系統。

假設情況

攻擊者掃描目標網路 (一家專門從事人工智慧的科技公司),發現一台以預設設定配置的 Jenkins 伺服器外露。運用現成的工具和 API 呼叫,他們開始挖掘 Jenkins 伺服器的元資料,尋找底層系統的潛在資訊。金礦般的資訊充斥著他們的螢幕 - 有關外掛程式、工作、系統組態等資料。在這些詳細資料中,有一串資訊相當引人注目。AWS 鑰匙。它們被 Jenkins 用於在 AWS 上部署應用程式,而且安全性不足。這些金鑰是用於管理員帳號,允許可能不受限制地存取公司的 AWS 環境。

利用鑰匙滲透公司的 AWS 基礎架構,攻擊者進入組織系統的核心。他們找到一個存放專屬 AI 模型的 S3 資料桶,並透過被盜的 AWS 金鑰取得管理層級的存取權限,迅速下載模型,然後在不觸發警報的情況下離開。

然後,攻擊者決定進一步利用這個系統。他們意識到 Jenkins 伺服器擁有 GitHub 儲存庫的寫入權限,因此在主應用程式原始碼中植入惡意程式碼片段,以建立進入應用程式的後門。在下一個部署週期中,公司在不知情的情況下將應用程式推入生產。現在,攻擊者有了持久性的後門,就可以竊取資料、竄改系統控制,並植入額外的惡意軟體 - 一切都在公司安全系統的監控之下。

 

CI/CD 中安全系統組態的重要性

工程環境中任何關鍵的設定錯誤,都可能讓整個管道暴露在潛在的威脅之下。利用設定錯誤的攻擊者可能會在未經授權的情況下存取 CI/CD 系統 - 或更糟的是,入侵系統並存取底層作業系統。攻擊者可能會篡改合法的 CI/CD 流量、取得敏感的代幣,並可能存取生產環境。在某些情況下,組態缺陷可能會允許攻擊者在環境中橫向移動,並超出 CI/CD 系統的範圍。

與不安全系統組態相關的風險

DevOps 瞭解不安全系統組態相關風險的團隊,有能力設計較不脆弱的系統、對所設計系統的安全性負責,並在風險發生時降低風險。

案例研究 1:PHP 在安全事件和潛在的使用者資料庫洩漏後轉移到 GitHub

2021 年 4 月,PHP 社群面臨涉及 git.php.net 的安全事件。最初懷疑是伺服器外洩,調查發現惡意提交使用 HTTPS 和密碼式驗證,繞過 Gitolite 基礎架構。master.php.net的使用者資料庫可能洩漏,促使系統遷移至main.php.net,並為所有php.net使用者重新設定密碼。Git.php.net 和 svn.php.net 變成唯讀,PHP 的主要儲存庫也移到 GitHub,增強了安全性並簡化了開發工作流程。

案例研究 2:Webmin 在發生惡意程式碼插入事件後全面檢討安全措施

2019 年 8 月,基於 Web 的系統組態工具 Webmin 遭到惡意程式碼插入其原始碼的安全漏洞。此漏洞並非意外的錯誤,它允許遠端指令執行。惡意程式碼是透過受攻擊的開發建置伺服器導入的。Webmin 在發現此漏洞後,採取的回應措施包括更新建立程序,僅使用來自 GitHub 的檢查過的程式碼、輪換所有可存取的秘密,以及稽核過去一年所有 GitHub 的提交記錄,以找出類似的漏洞。

案例研究 3:由於 Git 伺服器設定錯誤,日產北美的原始碼在線上曝光

由於 Git 伺服器設定錯誤,導致 Nissan North America 行動應用程式和內部工具的原始碼在線上洩露,造成重大的安全漏洞。這台伺服器的預設使用者名稱和密碼為「admin/admin」,是由瑞士的軟體工程師 Tillie Kottmann 發現的。程式碼儲存庫包含各種 Nissan 應用程式、診斷工具、經銷商入口網站、行銷工具等的程式碼。日產確認了這次事件,保護了受影響的系統,並聲稱沒有個人資料被存取。

案例研究 4:紐約州 IT 部門於線上公開內部程式碼儲存庫

紐約州 IT 部門使用的內部程式碼儲存庫不慎曝光在網路上,任何人都可以存取。由網路安全公司 SpiderSilk 發現的 GitLab 伺服器,包含州政府系統的秘密金鑰和密碼的專案。該伺服器被設定為允許任何人建立使用者帳戶並登入。該伺服器於 3 月 18 日首次被偵測到上線,並在接獲曝光報告後下線。據報導,該伺服器是由廠商架设的測試盒,之後就退役了。

 

在 CI/CD 中預防不安全的系統組態

雖然錯誤設定會為攻擊者提供切入點,導致重大的安全漏洞,但安全的系統設定在許多開發過程中仍被忽略。來自 OWASP 十大 CI/CD 安全風險 清單作者的內幕人士建議,可以讓您的系統處於良好的狀態:

  • 記錄使用中的系統和版本清單,將每個系統對應到指定的擁有者。定期檢查這些元件是否有已知的漏洞。當有安全修補程式時,更新易受攻擊的元件。如果易受攻擊的元件沒有修補程式,請考慮移除該元件或系統。或者,透過限制系統存取權限或執行敏感作業的能力,將利用漏洞的潛在影響降至最低。
  • 確保網路存取系統符合 最低權限存苃的原則
  • 建立定期檢閱所有系統組態的程序。將檢查重點放在可能影響系統安全狀態的設定上。確保最佳化設定。
  • 根據最少權限原則,授予 管道執行節點權限 。在此情況下,常見的設定錯誤包括將執行節點上的除錯權限授予工程師。許多 組織都允許這樣做,但必須考慮到,任何在除錯模式下能夠存取執行節點的使用者,都有可能在秘密載入記憶體時暴露所有秘密。他們也可以使用節點的身分,有效地將提升的權限授予任何擁有此權限的工程師。

 

系統組態安全的業界標準

幾個業界標準概述了系統組態安全的最佳實務。網際網路安全中心 (Center for Internet Security, CIS) 提供了全面的安全性配置基準,而美國國家標準與技術研究院 (National Institute of Standards and Technology, NIST) 也發布了配置系統安全性的指引。

加密您的秘密

密碼、REST API 金鑰、資料庫憑證等密碼應在儲存和傳輸時加密。 切勿在程式碼或組態檔案中儲存機密。使用秘密管理工具,如 HashiCorp Vault 或 AWS Secrets Manager。這些工具可將機密加密並控制存取權,有助於防止組織的憑證落入歹徒手中。

記錄和監控您的系統

維護安全系統組態的關鍵部分包括建立明確的政策,並定期監控合規性。記錄所有活動非常重要,這樣您才能偵測可疑活動,並快速回應安全事故。您也應該監控系統是否有受到攻擊的跡象,例如不尋常的流量模式或登入嘗試失敗。

修補漏洞

確保您有一套全面的弱點辨識與修補系統。有系統地找出弱點,並排定修復的優先順序。在無法修補漏洞的情況下,請使用其他緩解措施,例如移除管理員權限。請記住,保持您的系統為最新狀態意味著要定期為您的伺服器、應用程式和 CI/CD 工具套用修補程式和更新。

消除不必要的帳戶和權限

透過移除不必要的帳號 (例如遺棄帳號和未使用的帳號) 來強制執行最低權限。這是減少攻擊面最有效的安全措施之一。確保系統的每個元件 (包括使用者、程序和服務) 僅具有執行其功能所需的最低權限。這樣做可以在元件損壞時限制損害。

架設網路路障

如果攻擊者取得網路存取權,將您的網路分割成較小的、隔離的區段將可限制橫向移動。使用防火牆和存取控制清單 (ACL) 控制網段間的流量。加密流量、封鎖未使用或不需要的開放網路連接埠,以及停用或移除不必要的通訊協定和服務。定期審核防火牆規則。

保護您的建置伺服器

您的建立伺服器負責編譯和套件您的程式碼,因此它們是攻擊者的主要目標。確保您的建立伺服器已使用最新的安全修補程式和強大的密碼妥善加固。請記住,保護您的建立環境意味著將它與您的生產環境隔離。

審核您現有的系統

定期稽核與檢閱有助於確保系統組態長期維持安全。對您現有的技術進行全面審核。使用滲透測試、弱點掃描、組態管理和其他安全稽核工具,找出系統中的缺陷,並優先進行修復。使用 NIST、Microsoft、CIS、DISA 等的業界標準,針對資源進行系統評估。

使用工具協助保護系統組態安全

有許多工具可協助管理和保護系統組態。配置管理工具(如 Ansible、Chef 或 Puppet)可在各種環境中進行自動配置和一致的應用。對於雲端原生系統,AWS Config、Azure Policy 和 Google Cloud Security Command Center 等雲端服務可協助維護安全組態。

 

不安全系統組態常見問題

組態管理是一個系統工程流程,用來建立並維持產品在整個生命週期中,其性能、功能和物理屬性與其需求、設計和作業資訊的一致性。
系統強化是一個有條不紊的過程,在整個組織中審核、識別、關閉和控制潛在的安全漏洞。透過套用一套準則和工具來最小化弱點,強化消除了不必要的功能、組態和服務。更新程序可包括安全配置系統設定、及時套用修補程式和更新、限制系統管理員和使用者的人數,以及設定強大的驗證通訊協定。系統強化背後的理念是透過縮小系統的攻擊面來強化安全性。
系統強化標準是為了保護系統免受威脅而設計的準則和最佳實務。強化標準通常是由網路安全組織或業界團體所制定,提供設定系統的架構,以盡量減少系統的攻擊面。

加固標準的範例包括網際網路安全中心 (CIS) 的基準,該基準提供明確、無偏見、以共識為基礎的業界最佳實務,以協助組織評估和改善其安全性。

其他標準包括美國國防資訊系統管理局 (Defense Information Systems Agency, DISA) 的安全技術實作指南 (Security Technical Implementation Guides, STIGs) 以及美國國家標準與技術研究院 (National Institute of Standards and Technology, NIST) 的加固指南。這些標準涵蓋廣泛的系統,包括作業系統、網路裝置和雲端環境,並會定期更新以因應新興的威脅和弱點。
基礎架構即程式碼是透過機器可讀定義檔案,而非實體硬體組態或互動式組態工具,來管理和佈建電腦資料中心的過程。
Dockerfile 是一份文字文件,包含使用者在命令列上可以呼叫的所有指令,用以組裝容器映像。使用 Docker build 使用者可以建立自動化的建置,連續執行數個命令列指令。
Kubernetes 部署是 Kubernetes 中的資源物件,提供 Pod 和 ReplicaSets 的宣告式更新。工程師會描述部署中的理想狀態,而部署控制器會以受控的速率將實際狀態變更為理想狀態。
Helm 是 Kubernetes 的套件管理器,可讓開發人員和操作人員更輕鬆地將應用程式和服務套件化、組態化並部署到 Kubernetes 叢集上。Helm 圖表是描述一組相關 Kubernetes 資源的檔案集合。
Buildpacks 是將應用程式原始碼轉換為 OCI 影像的模組化且與語言無關的方式。buildpack 會檢查您的程式碼,以決定要在 OCI 映像中包含哪些內容。
當系統「漂移」或變更其預定配置時,就會發生配置漂移。對系統進行手動變更,或在未使用組態管理工具的情況下執行更新或安裝時,都可能發生這種情況。
YAML (YAML Ain't Markup Language) 是一種人類可讀的資料序列化語言。它通常用於設定檔案以及儲存或傳輸資料的應用程式。
JSON (JavaScript Object Notation) 是一種輕量級的資料交換格式,人類容易讀寫,機器也容易解析和產生。它通常用於在網路應用程式中傳輸資料。