☰

安全的只读自托管 git 脚本存储库

tag-icon • tag-icon security git
安全的只读自托管 git 脚本存储库

我需要构建一个 git 服务器，其中某些用户对存储库具有读写访问权限，并且使用此存储库运行某些脚本的管理服务器对 git 服务器中的同一存储库具有只读访问权限：

git 服务器拓扑

设置应尽可能安全。目前我完成了这个硅藻土其中devices存储库具有以下配置：

repo devices
    RW     =   eng1
    RW     =   eng2
    RW     =   eng3
    R      =   graphs

用户的SSH密钥对graphs存储在mgmt-svr服务器的用户graphs主目录中，私钥只有该用户可读可写graphs。该私钥不受密码保护。

有没有更安全的方法来实现这一点？我考虑过使用 HTTPS 访问devicesgit 服务器中的存储库和基本访问身份验证，但与当前基于 SSH 的设置相比，我看不到任何优势 - 我仍然需要将访问凭据存储在用户主graphs目录中的某个位置。

答案1

您可以使用gitlabCI 的部署关键功能。此功能也适用于社区版 (ce)。

全局共享部署密钥允许在整个 GitLab 安装中的任何存储库上配置只读或读写（如果启用）访问权限。

这对于将存储库集成到安全的、共享的持续集成 (CI) 服务或其他共享服务非常有用。 GitLab 管理员可以在 GitLab 中设置 Global Shared Deploy 密钥，并将私钥添加到任何共享系统。当项目维护者（或更高级别）授权全局共享部署密钥用于其项目时，各个存储库选择使用这些密钥公开其存储库。

与按项目部署密钥相比，全局共享密钥可以提供更高的安全性，因为目标集成系统的管理员是唯一需要了解和配置私钥的人。

GitLab 管理员在管理区域的部署密钥部分下设置全局部署密钥。确保密钥具有有意义的标题，因为这将是项目维护人员和所有者识别要添加的正确 Global Deploy 密钥的主要方式。例如，如果密钥允许访问 SaaS CI 实例，则在密钥名称中使用该服务的名称（如果这就是它的全部用途）。创建全局共享部署密钥时，请考虑密钥的粒度 - 它们的用途可能非常狭窄，例如仅用于特定服务，也可能用途更广泛，例如“任何需要授予对存储库的读取访问权限的地方”。

一旦 GitLab 管理员添加了全局部署密钥，项目维护者和所有者就可以将其添加到项目的“设置”>“存储库”页面中，方法是展开“部署密钥”部分，然后单击“可用于任何项目的公共部署密钥”下列出的相应密钥旁边的“启用”。

https://docs.gitlab.com/ee/ssh/#deploy-keys

编辑:
gitea与 . 相比，是一个更轻量级的自托管 git 服务gitlab。它只有一个静态的单个二进制文件，没有任何依赖项 - 使用 go 编程（当然，您需要添加配置文件和 systemd 服务或类似服务）。该网站对其功能有很好的概述： https://docs.gitea.io/en-us/

答案2

您的设置听起来很安全。不过，只要有足够的时间，黑客总能找到办法。 ...如果有人攻击你，请不要起诉我。 它可能适合小型设置。对于大型企业中的大型团队来说，这可能不太合适（请参阅下面的“社会工程”）。

它有一些优点，也有一些要点供您考虑以使其变得更好。

关于您的设置的积极点

  • Gitolite 本身重量轻，并且使用得足够好，并且不断更新。 （最后一次提交是在撰写本文时 23 天前）。这是相当安全的。
  • Gitolite 搭载 OpenSSH 服务器，该服务器得到了很好的支持并且非常安全。
  • 公共私钥（例如 SSH 密钥）比密码安全得多
  • 设置非常简单，可以减少出错的可能性，并且是一种廉价的解决方案。

改进的考虑因素

未加密的密钥

尽管很常见，但未加密地存储私钥并不完美。正如你所说，你必须将它们存储在某个地方。然而，这可能是备份或物理上不安全的服务器的问题。有些选项要求您在重新启动服务器时手动解密私钥。也许其中最简单的是ssh代理并在重新启动时手动将加密密钥添加到其中。

SSH服务器加固

请记住，Gitolite 在 OpenSSH 服务器下运行。您可以做很多事情来强化 ssh 服务器本身。

您甚至可以考虑在以下环境下运行 Gitolitechroot环境。有很多关于如何设置chrootOpenSSH 的教程。请记住，结果将需要访问这样的程序，python因此这将使其在技术上比许多教程让您相信的更加复杂。

社会工程学

每个系统管理员都在寻找黑客可以入侵的技术方法，但现实世界中的许多黑客行为都是到人。

也许您的解决方案最薄弱的一点是 ssh 密钥的管理。 这在许多企业中被广泛认为是一个安全问题。 Gitolite 将 SSH 密钥的所有管理工作交给管理员。这带来了一些重大影响：

  • 由于不支持单点登录，系统管理员可能不知道当有人离开时他们需要删除对此特定框​​的访问权限。例如：如果您的团队自己运行这个盒子，他们会在员工被解雇时收到通知吗？
  • Gitolite 配置中的命名约定不太好。很容易犯错误并删除或替换错误的密钥。您需要为自己制定一个目录结构，以明确您在做什么。
  • 用户可能不会告诉您他们何时停止使用密钥。他们用这把钥匙做什么下一个可能不安全。其他更大的软件（例如 Github Enterprise）实际上已经内置了以下功能：审核 SSH 密钥通过大规模禁用它们并要求用户重新批准它们。

相关内容