• 0

  • 3

GitLab 实例:安全性最佳实践

GitLab爱好者

😄GitLab太好用了!

3个月前

产品的默认设置可能是非常有用的。但是当涉及到增强 GitLab 实例时,我们的安全团队提供了一些有用的配置建议

GitLab 是一款功能丰富强大和易于使用的协作工具,我们的自我管理安装模式旨在使其能够开箱即用。从安全的角度来看,向互联网公开任何服务都可能带来自身的挑战,因此管理员可能要为如何安全地进行设置而绞尽脑汁。

幸运的是,我们有大量的安全功能和选项可以用来帮助解决这方面的难题。在这篇博客文章中,我们将强调几个重要功能,这些功能肯定会帮助管理员增强新的 GitLab 实例——尤其是面向互联网的实例。

访问

在最初 GitLab 安装过程中,你将被要求设置一个根密码 (root password)。显然,我们强烈推荐你设置一个长密码,该密码只是用于 GitLab 实例,且使用不容易猜到的大小写混合数字和特殊字符。下面我们举个例子,来看看我们建议 GitLab 团队成员如何创建、存储和管理密码

为了简化安装,请考虑使用环境变量。根密码也可以这样设置。例如:

GITLAB_ROOT_PASSWORD=hunter2 GITLAB_HOST=https://hunter2.instance apt install gitlab-ee

这样做的另一个好处是启动了整个 letsencrypt 过程,确保你的实例使用了最新的证书。

你还需要确保你的实例的用户也使用强大的、惟一的密码,并且需要确保他们用于访问实例的方法是可靠的。同样,请参考我们关于密码的文档

你可以做出一些选择来限制访问数据和限制访问授权用户。在 Admin Area >Settings > General 中,你需要展开“可见性和访问控制” (visibility and access controls) 部分并做一些更改

为了对 SSH 访问进行保护,应该支持 RSA SSH 密钥ED25519。简单而言。开源人士似乎更喜欢 ED25519,因为它的所有内容都是开源的 (有良好文档记录的、值得信赖的椭圆曲线参数),而其他算法并没有详细说明它们为什么选择某些值 (values)。DSA 存在一个理论上的攻击,可用于对抗 DSA,而尽管 RSA 在理论上也可能遇到同样的攻击,但 RSA 更能抵抗该攻击。哦,我跑题了!

应该同时支持 RSA 和 ED25519 的主要原因是,要连接的旧系统可能不支持 ED25519,而仍然支持 RSA,所以至少建议两者都支持。关于 RSA,鼓励你的用户在配置密钥时使用 2048 位或更高的位。

我们强烈建议使用无密码的 SSH 身份验证,而不是密码身份验证。这样会使通信更加安全 (因为无密码的 SSH 身份验证使用公钥/私钥加密),允许更简单的工作流程,而且少了一个需要担心的密码。

有关 SSH 密钥的更多信息,请参阅我们关于 SSH 密钥限制的文档,以及可以配置的其他可见性和访问控制设置。

如何限制?对谁限制?

我们建议调整一些设置,以帮助定义用户访问实例的方式,以及允许谁访问。你需要查看Admin Area > Settings > General 设置中的三个区域。

注册限制:

  • 禁用注册。创建实例的默认设置是开放注册。如果启用了此功能,且你的实例对互联网开放,那任何人都可以注册和访问数据。这可能是受欢迎的设置,但如果你限制普通公众作为常规用户访问该实例,那么请禁用注册。
  • 确保检查了“发送注册确认邮件”。这在一定程度上保证了用户实际上是真正的用户。
  • 如果你想要限制访问某个子群体 (比如你组织中的用户),可以考虑为你组织的域名 (比如“example.com”) 配置一个白名单,从而只允许白名单中的用户注册。
  • 最小密码长度:12。对于被允许访问的用户,需要确保他们使用较长的密码。详细信息请参阅我们的密码长度限制文档
  • 更多信息请参阅我们的注册限制相关文档

登入限制:

  • 确保启用了 Require 2FA。多因素身份验证是保护用户帐户身份验证的一种更安全的方法,因此我们对此强烈推荐。
  • 如果由于某种原因不能要求 MFA,请禁用 "password authentication enabled for Git over HTTP(S)" (“通过 HTTP(S) 为 Git 启用密码身份验证”)这将要求用户使用个人访问令牌 (access token),进一步保护用户帐户。
  • 更多信息请参阅我们的有关登入限制的文档

可见性和隐私 (visibility and privacy):确保现有项目的可见性设置为“Private”,对于新项目默认设置为“Private”。隐私项目只能由项目成员克隆、下载或查看,新注册的用户将不能访问这些项目。

改善新能和网络调整

有一些设置可以帮助保护你的系统免受各种网络使用高峰的影响,使你的系统更加稳定,用户可以更好地访问。

用户和 IP 速率限制

进入 Admin Area > Network > User and IP rate limits 允许你做一些调整。具体来说,你将需要检查所有以下三个项目:

  • "Enable unauthenticated request rate limit" (“启用未经身份验证的请求速率限制”)
  • "Enable authenticated API request rate limit" (“启用经过身份验证的 API 请求速率限制”)
  • "Enable authenticated web request rate limit" (“启用经过身份验证的 web 请求速率限制”)

在大多数情况下,与这些项目关联的默认值应该是正常的。有关更多信息,请参阅我们关于用户和 IP 速率限制的文档

Webhooks

Webhooks 是一个非常实用的功能。除非存在允许 webhooks 与内部服务通信的合法需要,否则它们应该被限制为允许公共可访问的服务,你可以在 Admin Area > Network > Outbound Requests 中进行验证。虽然 "allow requests to the local network from web hooks and services" (“允许从 webhooks 和服务请求到本地网络”) 在默认情况下是禁用的,你也应该取消选中“allow requests to the local network from system hooks” (“允许从系统 hooks 请求到本地网络”)。要了解更多细节,包括 webhooks 固有的一些危险,请参阅我们的 webhooks 文档

保护的路径

Admin Area > Network > Protected Paths 中检查"Enable protected paths rate limit" (“启用保护路径速率限制”)。使用默认值应该足够了。有关详细信息,请查看我们的保护路径文档

自定义你的配置,增强你的实例

我们知道,在安全性方面,保护和灵活性之间总有一个平衡。对于那些拥有面向互联网开放的 GitLab 实例的客户来说,他们的选择往往是由不同的业务驱动因素和需求推动。但是,通过一些配置调整,你可以增强实例,更好地保护你的组织,同时仍然对互联网开放。

其他设置,包括那些涉及安全的设置,可以在 Admin Area 中找到。你会想要探索这些以真正调整你的设置。对于其中一些人来说,这些设置有其自身的安全影响,可能是你的组织所特有的。祝你的探索和保护实例之旅愉快!

 

来源:https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/

声明:版权归原作者所有,发布文章仅为传递更多信息,不构成任何投资意见或建议。

GitLab

3

相关文章推荐

未登录头像

暂无评论