在GitLab SaaS上保护您的代码

使用ChatGPT翻译，RangWu校审。
原文：《The ultimate guide to securing your code on GitLab.com — Steve Grossman》

DevSecOps方法论的一个关键方面是在开发环境中应用最佳实践来保护您的软件免受恶意和意外的暴露或修改。本文介绍了如何控制和管理JihuLab.com和GitLab.com的访问以及与之相关的源代码管理、流水线构建、依赖和软件包仓库以及部署密钥，这些都涉及到软件供应链安全。以下最佳实践专门针对多租户JihuLab.com和GitLab.com上的最终用户，并针对旗舰版Ultimate许可证编写。并非所有这些功能都适用于专业版Premium许可证。

1. 群组设置

许多与安全相关的设置可以在顶层群组上设置，并会向所有子群组和项目进行级联。它们是保护您的JihuLab.com和GitLab.com实例的最简单和最重要的设置。

1.1 通用设置

在顶层群组中，应应用以下设置，以提供对该群组内代码的最佳安全性：

1.1.1 将群组可见性级别设置为私有

这可能是通用设置中最重要的设置。通过群组“设置——通用——可见性级别”将群组可见性设置为“私有”，除非用户为该群组成员，否则任何人都无法访问该群组。此外，通过将顶层群组设置为私有，所有子群组和项目也将变为私有，并且不可公开。

1.1.2 权限和群组功能

在群组“设置——通用——权限和群组功能——权限”中：

• 勾选“成员不能邀请[GROUP]及其子组之外的群组”。这将防止意外添加不应属于该群组的人员。
• 勾选“[GROUP]中的项目不能与其他群组共享”。这将防止通过共享或移动项目到受控制之外的其他群组中，而导致代码的意外或恶意外泄。
• 勾选“用户可以在该群组中创建项目访问令牌和群组访问令牌”。项目和群组访问令牌类似于个人访问令牌，具有以下改进：
  • 它们可见并可由群组所有者和维护者管理，这意味着管理员可以撤销访问令牌，并设置过期日期以限制滥用机会。
  • 它们创建一个虚拟的“机器人”用户，不占用许可证席位。
• 启用延迟项目删除。这将为您提供一个为期七天的宽限期，以防止对存储库的意外或恶意删除。与私有化部署的GitLab一样，JihuLab.com和GitLab.com无法在不付出巨大专业服务费用的情况下恢复单个项目。（自16.0开始，对于专业版Premium、旗舰版Ultimate用户默认开启。）
• 设置“通过 IP 地址限制访问”，这些路由确定用户可以访问代码的范围。
• 设置“通过电子邮件域限制成员资格”，仅限于您组织拥有的电子邮件域。
• 设置“允许创建子组的角色”为所有者Owner。这将有助于保持顶层群组结构符合您的管理要求 ，可以使用SAML群组同步降低用户管理的复杂度。
• 勾选“阻止派生到群组外”。这有助于防止代码外泄。
• 建议开启“双重认证”。这将禁用使用密码身份验证通过HTTPS访问Git的功能（使用SSH协议或使用个人访问令牌替代）。
• 勾选“用户不能被添加到此群组中的项目”。所有成员必须从群组继承。

1.1.3 合并请求批准

通过合并请求批准来防止恶意代码被注入仓库中。在群组中为所有项目启用合并请求批准：

• 阻止合并请求的创建者批准。
• 阻止添加提交的用户批准。
• 禁止在项目和合并请求中编辑批准规则。

需要注意，在群组设置完合并请求批准后，还需在项目中设置具体的合并请求批准规则。

1.2 SAML单点登录（SSO）

为了更加严格地控制可以访问JihuLab.com和GitLab.com上代码的人员，可以设置SAML单点登录。这将确保每个访问系统的人员都得到授权。
配置SAML单点登录，在群组“设置——SAML SSO”中：

• 勾选“为此群组启用 SAML 身份认证”。
• 勾选“对该群组的 Web 活动强制执行仅 SSO 身份验证。
• 勾选“对该群组的 Git 和依赖代理活动强制执行仅 SSO 身份验证。
• 将“默认成员角色”设置为最小访问权限Minimal Access。在子群组或个别项目中可以根据需要增加角色，最小访问权限将防止用户对未明确授权的项目或子群组的任何可见性。
• 对维护者和所有者角色的访问权限进行严格控制，不是每个开发人员都需要拥有维护者Maintainer角色。

1.3 群组审计和合规性

定期检查和审查合规报告，以验证谁批准了合并请求以及被批准的合并请求是哪些。设置流式审计事件到企业安全信息和事件管理（SIEM）系统，并监控其中是否存在异常活动。这需要对层级结构中的每个群组和项目进行重复操作，以获取最大数量的审计事件。

1.4 群组级推送规则

在群组级别“设置——仓库——预定义推送规则”设置严格的推送规则有助于确保恶意代码不会注入到仓库中：

• 拒绝未经验证的用户（验证git user.email是不是当前执行push命令的GitLab用户的已验证的邮箱）。
• 拒绝不一致的用户名（验证git user.user是不是当前执行push命令的GitLab用户的用户名）。
• 检查提交者是否是 GitLab 用户（验证git user.email是不是GitLab某个用户的邮箱）。
• 拒绝未签名提交。
• 防止推送 secret 文件。

1.5 CI/CD

以下设置可以确保CI/CD流水线的完整性，并减少滥用和恶意行为的机会：

• 将Runner注册控制在最小范围（如指定的项目或子群组），以减少任何恶意使用的影响范围。
• 取消勾选所有Runner的“运行未打标签的作业”，以减少滥用的机会。
• 将CI/CD变量控制在最小范围（如指定的项目或子群组），特别是包含机密信息的变量，以减少任何恶意使用的影响范围。
• 使用受保护的Runner、受保护的变量和受保护的分支来限制谁可以部署到生产环境。
• 对所有存储库中的.gitlab-ci.yml流水线定义文件的更改权限进行严格控制，通过CODEOWNERS文件防止CI/CD系统的恶意使用。

2. 项目设置

一些设置不能从群组级别进行继承，或者在群组级别不可用，必须在单个项目上进行设置。这些设置包括一些特定于仓库的设置。

2.1 仓库

设置受保护的分支和受保护的标签，与上述受保护的Runner和受保护的变量相配合。

2.2 CI/CD

在项目“设置——CI/CD——流水线通用设置”中

• 取消勾选“公开流水线”。
• 勾选“为受保护的分支使用单独的缓存”。

2.3 受保护的环境

使用受保护的环境并严格限制可以部署和要求批准的人员。

2.4 令牌访问

在项目“设置——CI/CD——令牌访问”勾选“允许使用 CI_JOB_TOKEN 访问此项目”，默认仅允许当前项目使用该令牌，可添加其他指定的项目使用该令牌。不要关闭该功能，来确保恶意项目无法检索并使用它来访问API。

2.5 安全文件

将密钥、配置文件和签名证书存储在安全文件中存储，而不是存储在代码仓库中。

2.6 项目级安全扫描与合规

2.6.1 安全测试

• 启用静态应用程序安全测试SAST，以防止恶意代码插入应用程序中。
• 启用依赖扫描并定期审查依赖项列表或由依赖扫描生成的软件或软件材料清单（SBOM），以检测漏洞和恶意组件。
• 启用容器扫描和集群镜像扫描。

2.6.2 策略

作为上述安全扫描的补充方案，您可以选择启用扫描执行策略以防止合并具有严重漏洞的代码。
遵循这些最佳实践将有助于确保您托管在JihuLab.com和GitLab.com上的代码不受篡改和公开暴露，确保您的软件供应链安全，只有授权的用户可以访问您的软件资产。

3. 更多资源

• 群组级别设置文档
• 项目级别设置文档