{{< details >}}

  • Tier: 专业版，旗舰版
  • Offering: 私有化部署

{{< /details >}}

极狐GitLab Geo 功能集的以下安全审查侧重于运行自己极狐GitLab 实例的客户的功能的安全方面。

业务模式

应用程序服务哪些地理区域？

  • 这因客户而异。Geo 允许客户部署到多个区域，他们可以选择在哪里。
  • 区域和节点选择完全是手动的。

数据要点

应用程序接收、生成和处理什么数据？

  • Geo 在极狐GitLab 实例之间几乎所有的数据流传输。这包括完整的数据库复制、大多数文件（如用户上传的附件）以及仓库 + wiki 数据。在典型配置中，这将在公共互联网中发生，并进行 TLS 加密。
  • PostgreSQL 复制是 TLS 加密的。

如何根据数据的敏感性将数据分类？

  • 极狐GitLab 的敏感性模型围绕公共 vs. 内部 vs. 私有项目。Geo 不加区分地复制它们。存在“选择性同步”用于文件和仓库（但不包括数据库内容），如果需要，允许仅将较不敏感的项目复制到 secondary 站点。

已为应用程序定义哪些数据备份和保留要求？

  • Geo 旨在提供应用程序数据的某个子集的复制。这是解决方案的一部分，而不是问题的一部分。

终端用户

应用程序的终端用户是谁？

  • Secondary 站点是在距离极狐GitLab 安装（即 primary 站点）较远的地区创建的（就互联网延迟而言）。它们旨在供任何通常使用 primary 站点的人使用，他们发现 secondary 站点离他们更近（就互联网延迟而言）。

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

  • Secondary 站点提供 primary 站点的所有接口（特别是 HTTP/HTTPS 网络应用程序，以及 HTTP/HTTPS 或 SSH Git 仓库访问），但仅限于只读活动。主要用例被设想为从 secondary 站点克隆 Git 仓库，而不是 primary 站点，但终端用户可以使用极狐GitLab 网络界面查看项目信息，如项目、议题、合并请求和代码片段。

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

  • 复制过程必须是安全的。例如，通常不可接受在公共互联网中以明文传输整个数据库内容或所有文件和仓库。
  • Secondary 站点必须对其内容具有与 primary 站点相同的访问控制 - 未经过身份验证的用户不得通过查询 secondary 站点访问 primary 站点上的特权信息。
  • 攻击者不得冒充 secondary 站点到 primary 站点，从而获得特权信息。

管理员

谁在应用程序中具有管理能力？

  • 没有 Geo 特定的。任何在数据库中设置 admin: true 的用户都被视为具有超级用户权限的管理员。
  • Geo 的许多集成（例如数据库复制）必须由系统管理员配置应用程序。

应用程序提供哪些管理功能？

  • Secondary 站点可以由具有管理访问权限的用户添加、修改或删除。
  • 可以通过 Sidekiq 管理控制来控制复制过程（开始/停止）。

网络

已定义哪些有关路由、交换、防火墙和负载均衡的详细信息？

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

支持应用程序的核心网络设备是什么？

  • 因客户而异。

存在什么网络性能要求？

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

支持应用程序的私有和公共网络链接是什么？

  • 客户选择自己的网络。由于站点旨在地理上分离，预计复制流量将在典型部署中通过公共互联网传输，但这不是要求。

系统

支持应用程序的操作系统是什么？

  • 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 特定值。一些是共享密钥，必须在设置时安全地从 primary 站点传输到 secondary 站点。我们的文档建议通过 SSH 从 primary 站点传输到系统管理员，然后以相同方式传回到 secondary 站点。特别包括 PostgreSQL 复制凭据和一个密钥 (db_key_base)，用于解密数据库中的某些列。db_key_base 密钥未加密存储在文件系统上，位于 /etc/gitlab/gitlab-secrets.json，以及其他一些密钥。没有静态保护。

数据处理

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

  • 数据通过极狐GitLab 自身公开的网络应用程序输入。一些数据也通过极狐GitLab 服务器上的系统管理命令输入（例如 gitlab-ctl set-primary-node）。
  • Secondary 站点还通过来自 primary 站点的 PostgreSQL 流复制接收输入。

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

  • Primary 站点通过 PostgreSQL 流复制输出到 secondary 站点。否则，主要通过极狐GitLab 自身公开的网络应用程序，以及由终端用户启动的 SSH git clone 操作。

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

  • Secondary 站点和 primary 站点通过 HTTP/HTTPS 交互（用 JSON 网络令牌保护）以及通过 PostgreSQL 流复制。
  • 在 primary 站点或 secondary 站点内，SSOT 是文件系统和数据库（包括 secondary 站点上的 Geo 跟踪数据库）。各种内部组件协调以对这些存储进行更改。

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

  • Secondary 站点必须忠实复制 primary 站点的数据。

应用程序存储什么数据以及如何存储？

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

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

  • Primary 站点或 secondary 站点都不在静态状态下加密 Git 仓库或文件系统数据。使用 db_otp_key 静态加密数据库列的子集。
  • 在极狐GitLab 部署的所有主机之间共享的静态密钥。
  • 在传输中，数据应加密，尽管应用程序允许通信以未加密的方式进行。两个主要传输是 secondary 站点的 PostgreSQL 复制过程和 Git 仓库/文件的复制过程。两者都应使用 TLS 保护，其密钥由 Linux 软件包根据现有配置进行管理，以便终端用户访问极狐GitLab。

存在什么能力来检测敏感数据的泄漏？

  • 现有全面的系统日志，跟踪每次连接到极狐GitLab 和 PostgreSQL。

已定义哪些数据传输加密要求？

  • （这包括通过 WAN、LAN、SecureFTP 或公开可访问协议如 http: 和 https: 进行的传输。）
  • 数据必须可以选择在传输中加密，并且对被动和主动攻击（例如，不应该可能进行 MITM 攻击）是安全的。

访问

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

  • Geo 添加了一种权限：secondary 站点可以访问特殊的 Geo API，通过 HTTP/HTTPS 下载文件，并通过 HTTP/HTTPS 克隆仓库。

已定义哪些用户识别和认证要求？

  • Secondary 站点通过共享数据库（HTTP 访问）或 PostgreSQL 复制用户（用于数据库复制）通过 OAuth 或 JWT 验证识别到 Geo primary 站点。数据库复制还需要定义基于 IP 的访问控制。

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

  • Secondary 站点只能读取数据。它们不能在 primary 站点上更改数据。

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

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

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

  • Secondary 站点对 primary 站点的 API 进行许多调用。这是文件复制进行的方式，例如。此端点仅可通过 JWT 令牌访问。
  • Primary 站点还对 secondary 站点进行调用以获取状态信息。

应用程序监控

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

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