Help us learn about your current experience with the documentation. Take the survey.

Geo 安全审查 (问答)

  • 级别：Premium, Ultimate
  • 产品：GitLab Self-Managed

以下对 Geo 功能集的安全审查，重点在于该功能对于运行自有 GitLab 实例的客户而言，其安全方面的考量。审查问题部分基于 owasp.org 的 OWASP 应用安全验证标准项目。

业务模式

该应用服务于哪些地理区域？

  • 这因客户而异。Geo 允许客户部署到多个区域，并由他们自行选择部署位置。
  • 区域和节点的选择完全是手动的。

数据基础

该应用接收、生成和处理哪些数据？

  • Geo 在站点之间流式传输 GitLab 实例持有的几乎所有数据。这包括完整的数据库复制、大多数文件（如用户上传的附件）以及仓库和 Wiki 数据。在典型配置下，这些数据将通过公共互联网传输，并使用 TLS 加密。
  • PostgreSQL 复制已进行 TLS 加密。
  • 另请参阅：仅应支持 TLSv1.2

如何根据数据的敏感性对其进行分类？

  • GitLab 的敏感性模型主要围绕公开、内部和私有项目。Geo 会无差别地复制所有这些项目。“选择性同步”功能适用于文件和仓库（但不适用于数据库内容），如果需要，该功能可以只将敏感性较低的项目复制到 辅站点。

为该应用定义了哪些数据备份和保留要求？

  • Geo 的设计旨在提供应用数据特定子集的复制功能。它是解决方案的一部分，而不是问题的一部分。

终端用户

谁是该应用的终端用户？

  • 辅站点 创建在远离（从网络延迟角度看）主 GitLab 安装（即 主站点）的区域。它们旨在供任何通常会使用 主站点，但又发现 辅站点（从网络延迟角度看）离自己更近的用户使用。

终端用户如何与应用交互？

  • 辅站点 提供 主站点 所有的接口（特别是 HTTP/HTTPS Web 应用，以及 HTTP/HTTPS 或 SSH Git 仓库访问），但其活动仅限于只读。其主要用例设想是，用户优先从 辅站点 而非 主站点 克隆 Git 仓库，但终端用户也可以使用 GitLab Web 界面来查看项目、议题、合并请求和代码片段等信息。

终端用户有哪些安全期望？

  • 复制过程必须是安全的。例如，通常情况下，通过公共互联网以明文形式传输整个数据库内容或所有文件和仓库是不可接受的。
  • 辅站点 必须对其内容拥有与 主站点 相同的访问控制——未经身份验证的用户不得能够通过查询 辅站点 来获取 主站点 上的特权信息。
  • 攻击者必须无法向 主站点 伪装成 辅站点，从而获取特权信息。

管理员

谁在应用中拥有管理权限？

  • 没有 Geo 特定的内容。数据库中 admin: true 被设置的任何用户都被视为拥有超级用户权限的管理员。
  • 另请参阅：更细粒度的访问控制（非 Geo 特定）。
  • Geo 的大部分集成（例如数据库复制）必须在应用中进行配置，通常由系统管理员完成。

该应用提供哪些管理功能？

  • 具有管理访问权限的用户可以添加、修改或移除 辅站点。
  • 复制过程可以通过 Sidekiq 管理控件进行控制（启动/停止）。

网络

已定义了哪些关于路由、交换、防火墙和负载均衡的细节？

  • Geo 要求 主站点 和 辅站点 能够通过 TCP/IP 网络相互通信。特别是，辅站点 必须能够访问 主站点 上的 HTTP/HTTPS 和 PostgreSQL 服务。

哪些核心网络设备支持该应用？

  • 因客户而异。

存在哪些网络性能要求？

  • 主站点 和 辅站点 之间的最大复制速度受站点间可用带宽的限制。没有硬性要求——完成复制的时间（以及跟上 主站点 变更的能力）是数据集大小、延迟容忍度和可用网络容量的函数。

哪些私有和公共网络链路支持该应用？

  • 客户自行选择其网络。由于站点旨在地理上分离，因此在典型部署中，设想复制流量会通过公共互联网传输，但这并非硬性要求。

系统

哪些操作系统支持该应用？

  • Geo 对操作系统没有额外的限制（更多详情请参阅 GitLab 安装 页面），但我们建议使用 Geo 文档 中列出的操作系统。

已定义了哪些关于所需操作系统组件和锁定需求的细节？

  • 受支持的 Linux 包安装方法会自行打包大多数组件。
  • 它在很大程度上依赖于系统安装的 OpenSSH 守护进程（Geo 要求用户设置自定义身份验证方法）以及 Linux 包提供或系统提供的 PostgreSQL 守护进程（必须将其配置为监听 TCP，必须添加额外的用户和复制槽等）。
  • 处理安全更新的过程（例如，如果 OpenSSH 或其他服务存在重大漏洞，并且客户希望在操作系统上修补这些服务）与非 Geo 情况完全相同：OpenSSH 的安全更新将通过常规的分发渠道提供给用户。Geo 不会在此过程中造成任何延迟。

基础设施监控

已定义了哪些网络和系统性能监控要求？

  • 没有 Geo 特定的要求。

存在哪些机制来检测恶意代码或受损的应用组件？

  • 没有 Geo 特定的机制。

已定义了哪些网络和系统安全监控要求？

  • 没有 Geo 特定的要求。

虚拟化与外部化

应用的哪些方面适合虚拟化？

  • 所有方面。

为该应用定义了哪些虚拟化要求？

  • 没有 Geo 特定的要求，但 GitLab 中的所有功能都需要在此类环境中完全可用。

产品的哪些方面可以通过云计算模型托管，哪些不可以？

  • GitLab 是“云原生”的，这同样适用于 Geo 和产品的其余部分。在云中部署是一种常见且受支持的场景。

如果适用，采用了哪些云计算方法？

  • 是否使用这些方法由我们的客户根据其运营需求决定：

    • 托管主机与“纯”云
    • “完整机器”方法（如 AWS-ED2）与“托管数据库”方法（如 AWS-RDS 和 Azure）

环境

创建该应用使用了哪些框架和编程语言？

  • Ruby on Rails, Ruby。

为该应用定义了哪些流程、代码或基础设施依赖项？

  • 没有 Geo 特定的依赖项。

哪些数据库和应用服务器支持该应用？

  • PostgreSQL >= 12, Redis, Sidekiq, Puma。

如何保护数据库连接字符串、加密密钥和其他敏感组件？

  • 存在一些 Geo 特定的值。其中一些是共享密钥，必须在设置时从 主站点 安全地传输到 辅站点。我们的文档建议通过 SSH 将它们从 主站点 传输给系统管理员，然后再以相同方式传输到 辅站点。
  • 特别是，这包括 PostgreSQL 复制凭据和一个用于解密数据库中特定列的密钥 (db_key_base)。
  • db_key_base 密钥与其他许多密钥一起，以未加密形式存储在文件系统的 /etc/gitlab/gitlab-secrets.json 文件中。它们没有静态保护。

数据处理

该应用支持哪些数据输入路径？

  • 数据通过 GitLab 自身暴露的 Web 应用输入。一些数据也通过 GitLab 服务器上的系统管理命令输入（例如 gitlab-ctl set-primary-node）。
  • 辅站点 还通过来自 主站点 的 PostgreSQL 流复制接收输入。

该应用支持哪些数据输出路径？

  • 主站点 通过 PostgreSQL 流复制向 辅站点 输出数据。此外，主要通过 GitLab 自身暴露的 Web 应用，以及由终端用户发起的 SSH git clone 操作输出。

数据如何在应用的内部组件之间流动？

  • 辅站点 和 主站点 通过 HTTP/HTTPS（使用 JSON Web Token 保护）以及 PostgreSQL 流复制进行交互。
  • 在 主站点 或 辅站点 内部，单一事实来源（SSOT）是文件系统和数据库（包括 辅站点 上的 Geo 跟踪数据库）。各种内部组件被协调以对这些存储进行更改。

已定义了哪些数据输入验证要求？

  • 辅站点 必须忠实地复制 主站点 的数据。

该应用存储哪些数据以及如何存储？

  • Git 仓库和文件、与其相关的跟踪信息，以及 GitLab 数据库内容。

哪些数据应该加密？定义了哪些密钥管理要求？

  • 主站点 和 辅站点 都不会对 Git 仓库或文件系统数据进行静态加密。数据库中的一部分列使用 db_otp_key 进行静态加密。
  • 一个在 GitLab 部署的所有主机之间共享的静态密钥。
  • 在传输过程中，数据应该被加密，尽管应用确实允许未加密的通信。两个主要的传输路径是 辅站点 对 PostgreSQL 的复制过程，以及对 Git 仓库/文件的复制过程。两者都应使用 TLS 进行保护，其密钥由 Linux 包根据终端用户访问 GitLab 的现有配置进行管理。

存在哪些检测敏感数据泄露的能力？

  • 存在全面的系统日志，记录到 GitLab 和 PostgreSQL 的每一次连接。

为传输中的数据定义了哪些加密要求？

  • （这包括通过 WAN、LAN、SecureFTP 或公开可访问的协议（如 http: 和 https:）进行的传输。）
  • 数据必须可以选择在传输时加密，并且能够抵御被动和主动攻击（例如，必须能够防止 MITM 攻击）。

访问

该应用支持哪些用户权限级别？

  • Geo 增加了一种权限类型：辅站点 可以访问一个特殊的 Geo API，通过 HTTP/HTTPS 下载文件，以及通过 HTTP/HTTPS 克隆仓库。

已定义了哪些用户身份识别和身份验证要求？

  • 辅站点 通过基于共享数据库（HTTP 访问）的 OAuth 或 JWT 身份验证，或通过 PostgreSQL 复制用户（用于数据库复制）向 Geo 主站点 进行身份识别。数据库复制还要求定义基于 IP 的访问控制。

已定义了哪些用户授权要求？

  • 辅站点 必须只能读取数据。它们不能更改 主站点 上的数据。

已定义了哪些会话管理要求？

  • Geo JWT 被定义为在需要重新生成之前仅持续两分钟。
  • Geo JWT 是为以下特定范围之一生成的：
    • Geo API 访问。
    • Git 访问。
    • LFS 和文件 ID。
    • 上传和文件 ID。
    • 作业产物和文件 ID。

为 URI 和服务调用定义了哪些访问要求？

  • 辅站点 会对 主站点 的 API 进行大量调用。例如，文件复制就是这样进行的。此端点只能通过 JWT 令牌访问。
  • 主站点 也会调用 辅站点 以获取状态信息。

应用监控

如何访问、存储和保护审计与调试日志？

  • 结构化的 JSON 日志被写入文件系统，也可以被摄取到 Kibana 安装中以进行进一步分析。