策略

策略为安全和合规团队提供一种方法，以在全局范围内强制执行组织中的控制措施。

安全团队可以确保：

  • 安全扫描器在开发团队的流水线中强制执行，且配置正确。
  • 所有扫描作业在没有任何更改或更改的情况下执行。
  • 基于来自这些漏洞的结果，对合并请求提供适当的批准。

合规团队可以：

  • 在所有合并请求上集中式的强制多个审批人
  • 在组织要求的范围内强制各种项目设置，例如启用或锁定合并请求和仓库设置。

可用的策略类型有：

安全策略项目

安全策略项目是一种仅用来包含策略的特殊类型项目。策略存储在 .gitlab/security-policies/policy.yml YAML 文件中。

要强制执行包含在策略项目中的安全策略，你需要将其链接到项目、群组、子群组。一个安全策略项目可能会包含多个策略，但是他们一起被强制执行。在群组或子群组上强制执行的安全策略项目会将其应用于层次结构中的所有内容，包括所有子群组和项目。

合并请求中所做的策略更改在合并请求合并后立即生效。直接提交到默认分支的策略更改可能需要最多 10 分钟才能生效。

策略设计指南

当设计你的策略时，你的目标应该是：

  • 设计策略强制执行以实现最小的开销和最大的覆盖范围
  • 确保职责分离

强制执行

要强制策略执行以满足你的要求，需要考虑以下因素：

  • 继承性： 默认情况下，策略会在其链接的组织单元上强制执行，以及所有子群组和项目。
  • 范围： 你可以定义策略的范围来匹配你的需求。

继承性

为了最大化策略范围，将安全策略项目链接到最高级别的组织单元，以实现你的目标：群组、子群组或项目。策略强制执行在链接的组织单元上强制执行，以及所有子群组和项目。在最高级别强制执行策略可以最小化所需的策略数量，从而最小化管理开销。

你可以使用策略继承来逐步推出策略。例如，当推出新策略时，你可以强制执行单个项目，然后进行测试。如果测试通过，你可以在项目中删除它，然后强制执行组，向上移动层次结构，直到策略强制执行在所有适用的项目上。

在既有群组或子群组上强制执行的策略将会在任何新创建的子群组或项目上强制执行，主要满足以下条件：

  • 新的子群组和项目包含在策略范围定义内（比如，策略范围包括该群组中的所有项目）。
  • 既有群组或子群组已经链接到安全策略项目。
note 极狐GitLab SaaS 用户可以在其顶级群组、或子群组上强制执行策略，但不能跨 GitLab SaaS 顶级群组强制执行策略。极狐GitLab 私有化部署用户可以在实例中的多个顶级群组上强制执行策略。

如下示例演示了两个群组及其结构：

  • Alpha 群组包含两个子群组，每个子群组包含多个项目。
  • 安全和合规群组包含两个策略。

Alpha 群组（包含代码项目）

  • Finance （子群组）
    • Project A
    • Accounts receiving (subgroup)
      • Project B
      • Project C
  • Engineering （子群组）
    • Project K
    • Project L
    • Project M

安全和合规 群组（包含安全策略项目）

  • 安全策略管理
  • 安全策略管理 - 安全策略项目
    • SAST 策略
    • 密钥检测策略

假设没有强制执行的策略，考虑以下示例：

  • 如果 “SAST” 策略在群组 Alpha 中强制执行，则它会应用到其子群组、Finance 和 Engineering，以及它们的所有项目和子群组。如果 “密钥检测” 策略也在子群组 “Accounts receiving” 中强制执行，则两个策略都适用于项目 B 和 C。但是，仅 “SAST” 策略适用于项目 A。
  • 如果 “SAST” 策略在子群组 “Accounts receiving” 中强制执行，则它仅适用于项目 B 和 C。没有其他子群组或项目有策略适用于它们。
  • 如果 “密钥检测” 策略在项目 K 中强制执行，则它仅适用于项目 K。没有其他子群组或项目有策略适用于它们。

范围

  • 引入于极狐GitLab 16.7，使用名为 security_policies_policy_scope 的功能标志。默认禁用。
  • 在极狐GitLab 16.11 中 GA。功能标志 security_policies_policy_scope 已删除。
  • 在极狐GitLab 17.4 中引入了群组范围。

你可以通过如下方式重新定义策略的范围：

  • 合规框架：在选定的合规框架的项目上强制执行策略。
  • 群组：
    • 群组中的所有项目，包括其所有子群组及其项目。可以选择排除特定项目。
    • 多个群组中的所有项目，包括其所有子群组及其项目。仅链接到同一安全策略项目的群组可以在此策略中列出。可以选择排除特定项目。
  • 项目：包含或排除特定项目。仅链接到同一安全策略项目的项目可以在此策略中列出。

这些选项可以一起在同一个策略中使用。但是，排除优先于包含。

policy_scope 关键字

使用 policy_scope 关键字来仅在你指定的群组、项目、合规框架或它们的组合上执行强制执行策略。

字段 类型 可能值 描述
compliance_frameworks array 不可应用的 List of IDs of the compliance frameworks in scope for enforcement, in an array of objects with key id.
projects object including, excluding 使用 excluding: 或 including:，然后，在一个键为 id 的对象数组中列出你希望包含或排除的项目的 ID。
groups object including 使用 including:，然后，在一个键为 id 的对象数组中列出你希望包含或排除的项目的 ID。仅有链接到相同安全策略项目的群组可以在策略中被列出。
范围示例

在此示例中，扫描执行策略在每个版本流水线中强制执行一个 SAST 扫描，在每个具有 ID 为 2 或 11 的合规框架的应用项目上。

---
scan_execution_policy:
- name: Enforce specified scans in every release pipeline
  description: This policy enforces a SAST scan for release branches
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: sast
  policy_scope:
    compliance_frameworks:
      - id: 2
      - id: 11

在此示例中，扫描执行策略针对默认分支的流水线都会强制执行一个密钥检测和 SAST 扫描，在 ID 为 203 的群组中的所有项目上（包括所有子群组及其项目），排除 ID 为 64 的项目。

- name: Enforce specified scans in every default branch pipeline
  description: This policy enforces Secret Detection and SAST scans for the default branch
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
  policy_scope:
    groups:
      including:
        - id: 203
    projects:
      excluding:
        - id: 64

职责分离

职责分离对于成功实现策略至关重要。实现策略以满足必要的合规和安全要求，同时允许开发团队实现他们的目标。

安全和合规团队：

  • 应该为定义策略负责，并和研发团队一起来确保策略满足他们的需求。

研发团队：

  • 不能够以任何方式来禁用、修改或规避策略。

要在群组、子群组或项目上强制执行安全策略项目，您必须具有以下权限之一：

  • 群组、子群组或项目的所有者角色。
  • 在群组、子群组或项目中的自定义角色，具有 manage_security_policy_link 权限。

所有者角色或具有 manage_security_policy_link 权限的自定义角色遵循群组、子群组和项目之间的标准层次结构规则：

组织单元 群组所有者或群组 manage_security_policy_link 权限 子群组或子群组 manage_security_policy_link 权限 项目所有者或项目 manage_security_policy_link 权限
群组 Yes No No
子群组 Yes Yes No
项目 Yes Yes Yes

策略实现

安全策略项目的实现选项在 JihuLab.com 和私有化部署上有所不同。主要的区别在于，在 JihuLab.com 上，只能创建子群组。为了实现职责分离，需要更精细的权限配置。

在 JihuLab.com 命名空间上强制执行策略

先决条件：

  • 你必须具有群组所有者角色或具有 manage_security_policy_link 权限的自定义角色，才能链接到安全策略项目。有关更多信息，请参阅职责分离。

为 JihuLab.com 命名空间上的所有子群组和项目强制执行策略的高级工作流程：

  1. 从你的顶级群组访问 策略 选项卡。

  2. 在子群组中，前往 策略 选项卡病创建一个测试策略。

    (提示：你可以创建一个禁用的策略进行测试。) 创建策略会自动在你的顶级群组下创建一个新的安全策略项目。此项目用于存储你的 policy.yml 或策略即代码。

  3. 检查并根据需要设置新创建项目的权限。

    默认情况下，所有者和维护者可以创建、编辑和删除策略。开发人员可以提出策略更改，但不能合并它们。

  4. 在子群组中创建的安全策略项目中，创建所需的策略。

    你可以使用你创建的 Security Policy Management 项目中位于 策略 选项卡下的策略编辑器。或者，你可以在新创建的安全策略项目 Security Policy Management - security policy project 中直接更新 policy.yml 文件中的策略。

  5. 链接群组、子群组或项目到安全策略项目。

    作为子群组所有者，或具有适当权限的项目所有者，你可以访问 策略 页面并创建一个链接到安全策略项目的链接。包括完整的路径，项目的名称应该以 “- security policy project” 结尾。所有链接的群组、子群组和项目都成为 “可执行” 的，任何在安全策略项目中创建的策略都可以执行。更多详情，可查阅链接到安全策略项目。

  6. 默认情况下，当策略启用时，它将对所有链接的组、子组和项目中的项目生效。

    对于更精细的执行，添加一个 “策略范围”。策略范围允许你对特定的一组项目或包含给定的一组合规框架标签的项目执行策略。

  7. 如果你需要额外的限制，例如阻止继承权限或要求对策略更改进行额外的审查或批准，你可以创建一个仅针对你的安全策略项目的策略，并强制执行额外的批准。

在你的私有化部署实例上强制执行全局策略

先决条件：

  • 你必须具有所有者角色或具有 manage_security_policy_link 权限的自定义角色来链接到安全策略项目。更多详情，可以查看职责分离。
  • 为了支持全局实例的审批群组，在你的GitLab实例应用程序设置中启用 security_policy_global_group_approvers_enabled。

在多个群组中强制执行策略的高级工作流：

  1. 创建个单独的群组来包含你的策略并确保职责分离。

    通过创建一个单独的独立群组，你可以最小化继承权限的用户数量。

  2. 在新的群组中，访问 策略 选项卡。

    这作为策略编辑器的主要位置，允许你在 UI 中创建和管理策略。

  3. 创建一个测试策略（你可以创建一个禁用的策略进行测试）。

    创建策略会自动在你的群组下创建一个新的安全策略项目。此项目用于存储你的 policy.yml 或策略即代码。

  4. 检查并根据需要设置新创建项目的权限。

    默认情况下，所有者和维护者都可以创建、编辑和删除策略。开发人员可以提出策略更改，但不能合并它们。

  5. 在你子群组中创建的安全策略项目中，创建需要的策略。

    你可以在你创建的安全策略项目 Security Policy Management 的策略选项卡下面使用策略编辑器。或者，你可以在新创建的安全策略项目 Security Policy Management - security policy project 中直接更新 policy.yml 文件中的策略。

  6. 将群组、子群组或项目链接到安全策略项目。

    作为子群组所有者，或具有适当权限的项目所有者，你可以访问 策略 页面并创建到安全策略项目的链接。包含完整的路径，项目的名称应该以 -security policy project 结尾。所有链接的群组、子群组和项目都可以通过安全策略项目中的任何策略强制执行。有关更多信息，请参阅链接到安全策略项目。

  7. 默认情况下，当策略启用时，它将在所有链接的群组、子群组和项目中强制执行。更多关于细粒度的强制执行，添加策略范围。策略范围允许你针对特定的一组项目或针对包含给定合规性框架标签的一组项目强制执行策略。

  8. 如果你需要额外的限制，例如阻止继承权限或要求对策略更改进行额外的审查或批准，你可以创建一个仅针对你的安全策略项目的策略，并强制执行额外的批准。

链接到安全策略项目

要强制执行安全策略项目中包含的策略，你需要将它们链接起来。默认情况下，所有链接的实体都会被强制执行。要根据每个策略的粒度强制执行策略，你可以在每个策略中设置“策略范围”。

先决条件：

  • 你必须具有所有者角色或具有 manage_security_policy_link 权限的自定义角色才能链接到安全策略项目。有关更多信息，请参阅职责分离。

要将群组、子群组或项目链接到安全策略项目：

  1. 在左侧边栏中，选择 搜索或前往 并找到你的项目、子群组或群组。
  2. 选择 安全 > 策略。
  3. 选择 编辑策略项目，然后从下拉列表中搜索并选择要链接的项目。
  4. 选择 保存。

要取消安全策略项目链接，请按照相同的步骤，但选择对话框中的垃圾桶图标即可。

查看链接的安全策略项目

所有能够访问项目策略页面的用户，而不是项目所有者，都会看到一个链接到关联的安全策略项目的按钮。

策略建议

当实现策略时，请考虑以下建议。

分支名称

当在策略中指定分支名称时，请使用受保护分支的通用类别，例如 默认分支 或 所有受保护的分支，而不是单独的分支名称。

如果项目中存在指定的分支，则策略仅在此项目中强制执行。比如，如果你的策略在分支 main 上强制执行规则，但范围内的某些项目使用 production 作为其默认分支，则不会对后者应用策略。

推送规则

在极狐GitLab 17.3 及之前版本中，如果使用推送规则来验证分支名称时，请确保它们允许创建带有前缀 update-policy- 的分支。此分支命名前缀在创建或修改安全策略时使用。例如，update-policy-1659094451，其中 1659094451 是时间戳。如果推送规则阻止创建分支，将出现以下错误：

Branch name update-policy-<timestamp> does not follow the pattern <branch_name_regex>.

在极狐GitLab 17.4 及以后版本中，安全策略项目将从强制执行分支名称验证的推送规则中排除。

策略管理

策略页面显示所有可用环境的已部署策略。你可以检查策略信息（例如描述或强制执行状态），并创建和编辑已部署策略：

  1. 在左侧边栏中，选择 搜索或前往 并找到你的项目。
  2. 选择 安全 > 策略。

Policies List Page

策略编辑器

使用策略编辑器来创建、编辑和删除策略：

  1. 在左侧导航栏，选择 搜索或前往 并找到您的项目。
  2. 选择 安全 > 策略。
    • 要创建新策略，请选择 新建策略，它位于 策略 页面的标题中。然后，您可以选择要创建的策略类型。
    • 要编辑现有策略，请在所选策略抽屉中选择 编辑策略。

    策略编辑器有两种模式：

    • 可视化 规则 模式允许您使用规则块和相关控件构造和预览策略规则。

      Policy Editor Rule Mode

    • YAML 模式允许你以 .yaml 格式输入策略定义，它针对的是专家用户以及规则模式所不支持的情况。

      Policy Editor YAML Mode

      你可以互换使用这两种模式，并且可以在任何时候在它们之间切换。如果 YAML 资源不正确或包含 Rule 模式不支持的数据，则 Rule 模式将自动禁用。如果 YAML 不正确，你必须在 Rule 模式再次可用之前使用 YAML 模式修复你的策略。

  3. 选择 配置合并请求 来保存并应用更改。

    策略的 YAML 文件被验证，并显示任何结果错误。

  4. 审查并合并生成的合并请求。

    如果你是项目所有者，且此项目未关联到安全策略项目，则在创建合并请求时，会创建并关联安全策略项目到此项目。

故障排查

当和安全策略工作时，考虑如下故障排查指南：

  • 您不应该将安全策略项目同时关联到开发项目和开发项目所属的群组或子群组。这样关联会导致合并请求批准规则不会被应用盗开发项目中的合并请求。
  • 当创建合并请求批准策略时，scan_finding 规则中的数组 severity_levels 和数组 vulnerability_states 不能留空。对于一个有效的规则，每个数组至少需要一个条目。