加固 - 通用概念

通用加固指南在主要加固文档中有概述。

以下文档总结了 GitLab 实例加固的一些基本理念。 虽然我们以 GitLab 为例，但在很多情况下，这些理念实际上适用于所有计算机系统。

分层安全

如果有两种实现安全的方式，应该同时采用这两种方式，而不仅仅是一种。一个简单的例子是账户安全：

• 为账户使用长、复杂且唯一的密码。
• 在认证过程中实施第二因素以增加安全性。
• 使用硬件令牌作为第二因素。
• 对失败的认证尝试锁定账户（至少固定时间）。
• 长时间未使用的账户应被禁用，通过自动化或定期审计来强制执行这一点。

不要只使用列表中的一两项，而应尽可能多地使用。这种理念不仅适用于账户安全，还可以应用于其他领域——应该应用于所有可能的领域。

消除通过隐藏来保障的安全

通过隐藏来保障的安全指的是，由于担心潜在攻击者可能会利用这些细节来制定攻击策略，而不讨论系统、服务或流程的某些元素。相反，系统应该被加固到即使其配置细节公开，系统仍然能够保持最大安全性的程度。本质上，如果攻击者了解到计算机系统配置的详细信息，这不会给他们带来任何优势。通过隐藏来保障安全的缺点之一是，它可能导致系统管理员产生一种潜在的错误安全感，认为系统比实际上更安全。

一个例子是在非标准 TCP 端口上运行服务。例如，服务器上默认的 SSH 守护进程端口是 TCP 端口 22，但可以配置 SSH 守护进程在另一个端口上运行，例如 TCP 端口 2222。配置此功能的管理员可能会认为它提高了系统的安全性，然而攻击者对系统进行端口扫描以发现所有开放端口是很常见的，这可以快速发现 SSH 服务，并消除任何感知到的安全优势。

由于 GitLab 是一个开源核心系统，所有配置选项都有完善的文档记录且是公开信息，通过隐藏来保障安全的理念违背了 GitLab 的核心价值观——透明度。这些加固建议旨在公开，以帮助消除任何通过隐藏来保障的安全。

减少攻击面

GitLab 是一个包含许多组件的大型系统。作为安全的一般规则，禁用未使用的系统会有所帮助。这消除了潜在攻击者可用于攻击的可用"攻击面"。这也可以带来额外的好处，即增加可用的系统资源。

例如，系统上有一个进程，每五分钟启动一次并检查输入队列，在执行检查时会查询多个子进程。如果您不使用该进程，就没有理由配置它，应该禁用它。如果攻击者找到了使用该进程的攻击向量，即使您的组织不使用它，攻击者也可能利用它。作为一般规则，您应该禁用任何未被使用的服务。

外部系统

在较大但仍保持加固的部署中，通常使用多个节点来处理您的 GitLab 部署所需的负载。在这些情况下，使用外部、操作系统和配置选项的组合来设置防火墙规则。任何使用限制的选项都应仅开放到足以允许子系统运行的程度。尽可能使用 TLS 加密来保护网络流量。