在 CircleCI 漏洞之后，對(duì)于任何依賴 CI/CD 基礎(chǔ)架構(gòu)的團(tuán)隊(duì)來(lái)說(shuō)，這是一個(gè)審查其管道安全性的好時(shí)機(jī)，因?yàn)樗麄兛梢圆扇∫恍┲鲃?dòng)措施。

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

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

CircleCI 團(tuán)隊(duì)還使所有 Project API 令牌失效，并通知用戶他們需要更換。

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

CI/CD 中的身份管理和訪問(wèn)控制

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

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

雖然向 DevOps 團(tuán)隊(duì)的所有成員、開(kāi)發(fā)人員和工程師授予訪問(wèn)權(quán)限可能很方便;這是一個(gè)非常糟糕的主意，因?yàn)樗蟠笤黾恿藛蝹€(gè)被破壞帳戶允許攻擊者完全訪問(wèn)所有相關(guān)系統(tǒng)的機(jī)會(huì)。

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

安全的非人為訪問(wèn)

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

當(dāng)依賴基于容器的系統(tǒng)時(shí)，請(qǐng)確保您使用身份驗(yàn)證器來(lái)驗(yàn)證機(jī)器身份。身份驗(yàn)證器驗(yàn)證容器的屬性，并且僅在獲得批準(zhǔn)時(shí)才授予范圍內(nèi)的訪問(wèn)級(jí)別。

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

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

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

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

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

自動(dòng)化秘密輪換

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

大多數(shù)平臺(tái)提供商，如 AWS、谷歌云和 Azure DevOps 都提供或提供直接的方法來(lái)編寫(xiě)自動(dòng)密鑰輪換腳本。這可以手動(dòng)或按固定計(jì)劃執(zhí)行。自動(dòng)化密鑰輪換可以幫助每個(gè)人在緊急情況下高枕無(wú)憂，因?yàn)樗试S在事件之外測(cè)試失效和替換過(guò)程。

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

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

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

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

用于入侵檢測(cè)的蜜標(biāo)

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

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

您的 CI/CD 安全是一項(xiàng)共同責(zé)任

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

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

本文僅列出了保護(hù) CI/CD 管道的幾種方法。有關(guān) CI/CD 安全的更多信息，我們建議查看OWASP 十大 CI/CD 安全風(fēng)險(xiǎn)。