在 CircleCI 漏洞之后，對于任何依賴 CI/CD 基礎架構(gòu)的團隊來說，這是一個審查其管道安全性的好時機，因為他們可以采取一些主動措施。

最近，我們了解到CircleCI 遭到破壞。他們強烈建議所有客戶：

• 立即輪換存儲在 CircleCI 中的所有秘密。
• 從 2022 年 12 月 21 日到 2023 年 1 月 4 日，或者你在 CircleCI 中輪換秘密的日期，檢查他們系統(tǒng)的內(nèi)部日志是否有未經(jīng)授權(quán)的訪問。

CircleCI 團隊還使所有 Project API 令牌失效，并通知用戶他們需要更換。

這一刻可以作為任何依賴 CI/CD 基礎架構(gòu)的團隊的轉(zhuǎn)折點，以此作為審查其管道安全性的機會。雖然 CircleCI 團隊制定的步驟是可靠的，但它們是對事件的反應。DevOps 團隊可以采取一些步驟來變得更加主動。

CI/CD 中的身份管理和訪問控制

如果您不熟悉這個主題，持續(xù)集成/持續(xù)交付、CI/CD 管道是一種通過一致的自動化流程交付應用程序的方法。開發(fā)人員將他們的代碼推送到 GitHub、GitLab、Azure DevOps 或 BitBucket 等存儲庫主機，這將啟動構(gòu)建應用程序、測試它以及最終將該代碼部署到生產(chǎn)環(huán)境的自動化過程。雖然 CI/CD 管道允許團隊更快地工作并減少手動錯誤的機會，但它們也為惡意行為者提供了一個新的攻擊面。

確保攻擊者無法利用您的 CD/CD 管道的最佳方法之一是鎖定可以訪問哪些工具和資源的人員。如果未明確授予某人訪問權(quán)限，則他們不應獲得訪問權(quán)限。這可以包括密碼、訪問密鑰和其他訪問控制機制，并且應該盡可能細化地實施。

雖然向 DevOps 團隊的所有成員、開發(fā)人員和工程師授予訪問權(quán)限可能很方便;這是一個非常糟糕的主意，因為它大大增加了單個被破壞帳戶允許攻擊者完全訪問所有相關系統(tǒng)的機會。

我們鼓勵每個人盡可能實施單點登錄 ( SSO ) 或使用基于角色的訪問控制 ( RBAC )。這些可以幫助您嚴格限定訪問權(quán)限，以便只向合適的人授予對相關系統(tǒng)的訪問權(quán)限。

安全的非人為訪問

我們已經(jīng)討論了人工訪問，但適當?shù)卮_定和管理第三方服務和工具的訪問也很重要。在部署 CI/CD 管道的任何元素時，您應該確切地知道哪些系統(tǒng)和服務將發(fā)送請求以及這些響應將發(fā)送到哪里。如果惡意代碼確實進入了您的管道，請確保它無法打電話回家或與未經(jīng)授權(quán)的用戶通信。

當依賴基于容器的系統(tǒng)時，請確保您使用身份驗證器來驗證機器身份。身份驗證器驗證容器的屬性，并且僅在獲得批準時才授予范圍內(nèi)的訪問級別。

關于非人類訪問的最后一點說明：您應該盡快消除任何未使用的資產(chǎn)。這意味著一旦不再需要容器和虛擬機就將其銷毀，并在未被積極使用時阻止對第三方工具的訪問。

不要暴露 CI/CD 管道中的秘密

攻擊者在任何系統(tǒng)中尋找的第一件事就是獲得進一步訪問的方法，即硬編碼憑證，也稱為秘密。雖然您不應該以明文形式存儲秘密似乎很明顯，但這種情況發(fā)生的頻率比您預期的要高。鑒于 CI/CD 管道的復雜性和它們的發(fā)展速度，它通常是開發(fā)人員在趕時間前求助的最簡單、最快捷的解決方案。也很容易忽視秘密是如何在您的管道日志中顯示的，如果沒有正確編輯，它們可能會出現(xiàn)在那里。

幸運的是，大多數(shù) CI/CD 提供商都提供內(nèi)置解決方案，允許您存儲憑據(jù)，然后在需要時以編程方式調(diào)用它們。或者，大多數(shù)解決方案都提供了將關鍵管理器(如 Hashicorp Vault)集成到您的管道中的途徑。

使明文憑據(jù)遠離您的管道的一個關鍵步驟是盡早實施秘密檢測。最好的情況是開發(fā)人員在提交之前捕獲硬編碼的秘密，他們可以在本地計算機上使用預提交掛鉤或預推掛鉤、預接收掛鉤或在 CI 環(huán)境中執(zhí)行此操作。

自動化秘密輪換

機密管理的另一個重要元素是控制每個憑證的生命周期。秘密保持有效的時間越長，攻擊者發(fā)現(xiàn)和使用它的可能性就越大。許多憑據(jù)能夠長期存在的最大原因之一是手動輪換密鑰帶來的痛苦以及對破壞生產(chǎn)系統(tǒng)的恐懼。這就是自動密鑰輪換節(jié)省時間的地方。

大多數(shù)平臺提供商，如 AWS、谷歌云和 Azure DevOps 都提供或提供直接的方法來編寫自動密鑰輪換腳本。這可以手動或按固定計劃執(zhí)行。自動化密鑰輪換可以幫助每個人在緊急情況下高枕無憂，因為它允許在事件之外測試失效和替換過程。

在自動創(chuàng)建機密時，請記住將這些憑據(jù)正確地限定在他們的任務范圍內(nèi)。始終遵循最小特權(quán)原則，限制對完成手頭工作所需的數(shù)據(jù)和系統(tǒng)的訪問。

主動監(jiān)控可疑行為

在事件發(fā)生后尋找可疑活動可以幫助您確定出了什么問題或在攻擊期間誰訪問了哪些系統(tǒng)。但是您無需等待壞事發(fā)生就可以利用您的日志。

當大多數(shù)人考慮主動驅(qū)動 CI/CD 時，目的是觀察資源消耗或可用性。但是，您也可以為可疑活動配置警報，例如意外添加特權(quán)角色或嘗試連接到未經(jīng)授權(quán)的服務。

用于入侵檢測的蜜標

保護 CI/CD 管道的另一種方法是設置入侵者可以在整個環(huán)境中觸發(fā)的陷阱。這些通常被稱為蜜標。Honeytokens 是看起來像真正的秘密但對任何服務都無效的憑據(jù)，但在使用時，它們會觸發(fā)警報并報告用戶地址。

一致部署 honeytokens 的一種方法是使它們成為自動化環(huán)境構(gòu)建的一部分，利用Terraform和我們的開源項目ggcanary等工具。可以在您的 CI/CD 管道以及代碼存儲庫或項目管理系統(tǒng)中創(chuàng)建和部署金絲雀令牌。

您的 CI/CD 安全是一項共同責任

用戶對他們的服務提供商的期望之一是他們將確保他們的平臺安全?，F(xiàn)實情況是，惡意攻擊者將繼續(xù)滲透和利用任何和所有目標，包括 CI/CD 提供商。最終保護您的管道是所有參與者的共同努力，包括您的團隊。

雖然不幸的是 CircleCI 已被破壞并且許多客戶受到影響，但我們也希望呼吁任何依賴 CI/CD 管道來審查其安全實踐的人采取行動。

本文僅列出了保護 CI/CD 管道的幾種方法。有關 CI/CD 安全的更多信息，我們建議查看OWASP 十大 CI/CD 安全風險。