如何降低持续集成服务安全漏洞的风险?

信息安全 攻击 风险管理 威胁缓解 自动化测试
2021-08-29 22:32:36

我们正在使用持续集成服务来自动运行我们的产品测试套件。每次我们将代码推送到我们的中央 Git 存储库生产分支时,CI 服务都会收到通知并获取代码以运行测试套件。

CI 服务允许我们编写一个构建后脚本,它可以在测试通过时自动将代码推送到我们的 Heroku 生产服务器。

然而,我们担心如果攻击者闯入 CI 服务,他可以将他想要的任何代码更改推送到我们的生产服务器。

我们计划更改此架构,以在测试通过时让 CI 服务 ping 我们的特定“部署”服务器。这个“部署”服务器将从我们的中央 Git 存储库获取最新的生产分支代码,并推送到我们的 Heroku 生产服务器。

这样,如果 CI 服务受到威胁,攻击者就无法从 CI 服务将任何他想要的代码推送到我们的生产服务器。他将不得不闯入我们的“部署”服务器。

这种新架构的目标是将风险从 CI SaaS 转移到我们的服务器上。部署所需的 Heroku 凭据不再托管在 CI SaaS 上,而是托管在我们的服务器上。

是否有意义?或者在使用 CI 服务时(除了设置和保护自己的 CI 服务器)还有其他更简单的选择吗?

2个回答

听起来您主要是在解决问题。CI 服务器过去拥有将新安装推送到 Heroku 服务器的凭据,现在它是部署服务器。

所以我最大的问题是 - CI 服务和部署服务器之间的安全性有什么区别?是否在外部托管?您是否有理由相信其中之一。访问 Heroku 服务器的凭证是风险最大的。

在新框架中,我会问这些问题:

  • Git 服务器上的代码被篡改的可能性有多大?

  • 对部署服务器的非法“ping”是否有可能导致问题?@roxOr 提到的竞争条件就是一种情况。还有一种想法是,如果 CI 服务器被篡改,它可能会被触发以发送一个 ping,从而诱导您的部署服务器将非工作代码放在 Heroku 服务器上。或者...此 ping 所需的身份验证级别是多少?任何人都可以从任何地方发送吗?那么攻击者不需要攻击 CI 服务器来触发一个错误的部署。

  • 部署服务器是否有可能被黑客入侵?这现在是你的大资产——它可以获得你的知识产权(代码)并部署它喜欢的任何恶意软件。所以它需要最严格的保护。

  • 外部代理有没有办法获取用于访问 Heroku 的凭据并直接访问它?在这种情况下,无论您如何部署代码,攻击者都可以随意推送代码。

  • 网络是否有可能被篡改 - 一个非常好的黑客方法是强制部署服务器从合法的 git hub 站点重定向到攻击者选择的源。然后,当从 CI 服务器接收到合法 ping 时,部署服务器会部署攻击者制作的代码,而不是测试代码。

没有一个系统是“完美的”,所以最大的问题通常归结为您期望什么样的攻击者,以及您认为他们的动机可能是什么。心怀不满的员工、企业间谍、随机的朋克和网络犯罪分子希望将您的网站用作恶意软件宿主,每个人都有自己的目标,每个人都有不同的能力。它有助于在更新架构之前考虑您想要保护的内容。

您有两点可能会受到损害:git 存储库访问和 CI 服务。您是否在使用 CI SaaS,因为如果您的部署服务器或 CI 机器受到威胁,有什么区别?他们都可以推送代码。

如果您有一个远程 CI 服务,您不妨在部署服务器上构建并将实际构建推送到 CI 服务。当构建通过时,将其推送到生产环境。这样您就知道您已经测试了要部署的确切版本。

竞争条件:CI 通过代码。有人将新代码签入 git。部署机器由 CI 发出警报,并使用未经测试的代码进行构建并将其推送到生产环境。