正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

コンプライアンスフレームワーク

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

コンプライアンスフレームワークは、プロジェクトに特定のコンプライアンス要件があるか、追加の監視が必要であることを識別するためのラベルとして作成できます。

Ultimateプランでは、コンプライアンスフレームワークは、適用先のプロジェクトに対してオプションでコンプライアンスコンプライアンスパイプライン構成セキュリティポリシーを適用できます。

コンプライアンスフレームワークはトップレベルグループに作成されます。プロジェクトが既存のトップレベルグループの外部に移動された場合、そのフレームワークは削除されます。

各プロジェクトに最大20個のコンプライアンスフレームワークを適用できます。

クリック可能なデモについては、Custom Compliance frameworksを参照してください。

前提要件

  • コンプライアンスフレームワークを作成、編集、削除するには、次のいずれかの権限がユーザーに必要です:
  • プロジェクトとの間でコンプライアンスフレームワークを追加または削除するには、プロジェクトが所属するグループにコンプライアンスフレームワークが必要です。

コンプライアンスフレームワークを作成、編集、または削除する

コンプライアンスフレームワークレポートまたはコンプライアンスプロジェクトレポートのいずれかを使用して、コンプライアンスフレームワークを作成、編集、または削除できます。

コンプライアンスフレームワークレポートの使用に関する詳細については、以下を参照してください:

コンプライアンスプロジェクトレポートの使用に関する詳細については、以下を参照してください:

プロジェクトにコンプライアンスフレームワークを適用する

複数のコンプライアンスフレームワークを1つのプロジェクトに適用できますが、個人用ネームスペースのプロジェクトにはコンプライアンスフレームワークを適用できません。

コンプライアンスフレームワークをプロジェクトに適用するには、コンプライアンスプロジェクトレポートを介してコンプライアンスフレームワークを適用します。

GraphQL APIを使用して、1つまたは複数のコンプライアンスフレームワークをプロジェクトに適用できます。

GraphQLを使用してサブグループにコンプライアンスフレームワークを作成する場合、ユーザーが適切な権限を持っている場合、フレームワークはルート祖先に作成されます。GitLab UIは、この動作を抑制するために読み取り専用ビューを表示します。

コンプライアンスフレームワークをコンプライアンスフレームワークを介してプロジェクトに適用するには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、プロジェクトタブを選択します。
  4. コンプライアンスフレームワークにカーソルを合わせ、Edit Framework(フレームワークを編集)タブを選択します。
  5. プロジェクトセクションを選択します。
  6. リストからプロジェクトを選択します。
  7. Update Framework(フレームワークを更新)を選択します。

デフォルトコンプライアンスフレームワーク

グループオーナーは、デフォルトコンプライアンスフレームワークを設定できます。デフォルトのフレームワークは、そのグループで作成されたすべての新しいプロジェクトとインポートされたプロジェクトに適用されます。既存のプロジェクトに適用されるフレームワークには影響しません。デフォルトのフレームワークは削除できません。

デフォルトに設定されているコンプライアンスフレームワークには、defaultラベルが付いています。

コンプライアンスセンターを使用して、デフォルトを設定および削除する

コンプライアンスプロジェクトレポートからデフォルトとして設定する(またはデフォルトを削除する)には:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、プロジェクトタブを選択します。
  4. コンプライアンスフレームワークにカーソルを合わせ、Edit Framework(フレームワークを編集)タブを選択します。
  5. デフォルトとして設定を選択します。
  6. 変更を保存を選択します。

コンプライアンスフレームワークレポートからデフォルトとして設定する(またはデフォルトを削除する)には:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、フレームワークタブを選択します。
  4. コンプライアンスフレームワークにカーソルを合わせ、Edit Framework(フレームワークを編集)タブを選択します。
  5. デフォルトとして設定を選択します。
  6. 変更を保存を選択します。

プロジェクトからコンプライアンスフレームワークを削除する

グループ内の1つまたは複数のプロジェクトからコンプライアンスフレームワークを削除するには、コンプライアンスプロジェクトレポートを使用してコンプライアンスフレームワークを削除します。

コンプライアンスフレームワークをインポートおよびエクスポートする

既存のコンプライアンスフレームワークをJSONファイルとしてダウンロードし、JSONテンプレートから新しいフレームワークをアップロードします。

JSONテンプレートのライブラリは、Compliance Adherence Templatesプロジェクトから入手できます。これらのテンプレートを使用して、定義済みのコンプライアンスフレームワークを迅速に採用します。

コンプライアンスフレームワークをJSONファイルとしてエクスポートする

この機能を使用すると、コンプライアンスフレームワークを共有およびバックアップできます。

コンプライアンスセンターからコンプライアンスフレームワークをエクスポートするには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、フレームワークタブを選択します。
  4. エクスポートするコンプライアンスフレームワークを見つけます。
  5. 縦方向の省略記号( ellipsis_v )を選択し、編集を選択します。
  6. Export as JSON file(JSONファイルとしてエクスポート)を選択します。

JSONファイルがローカルシステムにダウンロードされます。

JSONファイルからコンプライアンスフレームワークをインポートする

この機能を使用すると、共有またはバックアップされたコンプライアンスフレームワークを使用できます。JSONファイルの名前は、既存のコンプライアンスフレームワークと同じであってはなりません。

JSONテンプレートを使用してコンプライアンスフレームワークをインポートするには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、フレームワークタブを選択します。
  4. 新規フレームワークを選択します。
  5. フレームワークのインポートを選択します。
  6. 表示されるダイアログで、ローカルシステムからJSONファイルを選択します。

インポートが成功すると、新しいコンプライアンスフレームワークがリストに表示されます。エラーは修正のために表示されます。

JSONテンプレートの構造とスキーマ

コンプライアンスフレームワークのJSONテンプレートは、フレームワークのメタデータ、要求、および関連するコントロールを定義する特定のスキーマ構造に従います。この構造を理解すると、組織固有のコンプライアンスのニーズに合わせて、カスタムテンプレートを作成したり、既存のテンプレートを変更したりするのに役立ちます。

フレームワークのプロパティ

各JSONテンプレートには、次のトップレベルグループプロパティが含まれています:

プロパティ必須説明
name文字列はいコンプライアンスフレームワークの表示名。
description文字列はいフレームワークの目的の詳細な説明。
color文字列はいフレームワークの16進カラーコード(例: #1f75cb)。
requirements配列いいえコンプライアンスコントロールを定義する要求オブジェクトの配列。

要求構造

requirements配列内の各要求には、以下が含まれます:

プロパティ必須説明
name文字列はいコンプライアンス要件の名前。
description文字列はい要求が強制する内容の詳細な説明。
controls配列はい要求を実装するコントロールオブジェクトの配列。

コントロール構造

controls配列内の各コントロールは、特定のチェックを定義します:

プロパティ必須説明
name文字列はいGitLabコントロールID(例: scanner_sast_running)。
control_type文字列はいGitLabコントロールの場合は常に"internal"
expressionオブジェクトはいコントロールの評価ロジックを定義します。

式オブジェクト

expressionオブジェクトは、コントロールの評価方法を定義します:

プロパティ必須説明
field文字列はい評価するフィールド名(コントロール名と一致)。
operator文字列はい比較演算子(=>=<=><)。
value混合はい予想される値(ブール値、数値、または文字列)。

JSONテンプレート構造の例

完全な構造を示す簡単な例を次に示します:

{
  "name": "Example Compliance Framework",
  "description": "Example framework demonstrating JSON structure",
  "color": "#1f75cb",
  "requirements": [
    {
      "name": "Security Scanning Requirement",
      "description": "Ensure security scanning is enabled for all projects",
      "controls": [
        {
          "name": "scanner_sast_running",
          "control_type": "internal",
          "expression": {
            "field": "scanner_sast_running",
            "operator": "=",
            "value": true
          }
        },
        {
          "name": "minimum_approvals_required_2",
          "control_type": "internal",
          "expression": {
            "field": "minimum_approvals_required",
            "operator": ">=",
            "value": 2
          }
        }
      ]
    }
  ]
}

要件

  • プラン: Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

GitLab Ultimateでは、コンプライアンスフレームワークの特定のrequirements(要求)を定義できます。要求は1つまたは複数のコントロールで構成され、フレームワークが割り当てられているプロジェクトの設定または動作に対するチェックです。各要求には、最大5つのコントロールがあります。

各コントロールには、スケジュールされたスキャンまたはトリガーされたスキャン中にGitLabがプロジェクトのコンプライアンス遵守を評価するために使用するロジックが含まれています。コンプライアンス遵守の追跡方法の詳細については、コンプライアンス状況レポートを参照してください。

GitLabコンプライアンスコントロールまたは外部コントロールをフレームワーク要求に使用できます。

GitLabコンプライアンスコントロール

GitLabコンプライアンスコントロールは、GitLabコンプライアンスフレームワークで使用できます。コントロールは、コンプライアンスフレームワークに割り当てられているプロジェクトの設定または動作に対するチェックです。

GitLabコンプライアンスコントロールを組み合わせて、コンプライアンス標準を満たすのに役立ちます。

コントロール名コントロールID説明
APIセキュリティを実行中scanner_api_security_runningAPIセキュリティスキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。
少なくとも1つの承認minimum_approvals_required_1マージリクエストのマージ前に、少なくとも1つの承認を必要とすることを確認します。
少なくとも2件の承認minimum_approvals_required_2マージリクエストのマージ前に、少なくとも2つの承認を必要とすることを確認します。
認証SSOが有効auth_sso_enabledプロジェクトでシングルサインオン(SSO)認証が有効になっていることを確認します。
作成者が承認したマージリクエストは禁止されていますmerge_request_prevent_author_approvalマージリクエストの作成者が自分の変更を承認できないことを確認します。
ブランチの削除が無効branch_deletion_disabledブランチを削除できないことを確認します。
CI/CDジョブトークンのスコープが有効cicd_job_token_scope_enabledCI/CDジョブトークンのスコープ制限が有効になっていることを確認します。
コードの変更にはコードオーナーが必要code_changes_requires_code_ownersコードの変更にはコードオーナーからの承認が必要であることを確認します。
コードオーナーの承認を必須とするcode_owner_approval_requiredコードオーナーファイルが構成されていることを確認します。
コード品質の実行scanner_code_quality_runningコード品質スキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。
コミッターが承認したマージリクエストは禁止されていますmerge_request_prevent_committers_approvalマージリクエストにコミットしたユーザーはそれを承認できないことを確認します。
コンテナスキャンを実行中scanner_container_scanning_runningコンテナスキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。
DASTを実行中scanner_dast_running動的アプリケーションセキュリティテスト(DAST)が構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。
デフォルトブランチの保護default_branch_protectedデフォルトブランチブランチに保護ルールが有効になっていることを確認します。
デフォルトブランチが直接プッシュから保護されているdefault_branch_protected_from_direct_pushデフォルトブランチブランチへの直接プッシュを防止します。
デフォルトブランチブランチのユーザーがマージできるdefault_branch_users_can_mergeユーザーがデフォルトブランチブランチへの変更をマージできるかどうかを制御します。
デフォルトブランチブランチのユーザーがプッシュできるdefault_branch_users_can_pushユーザーがデフォルトブランチブランチに直接プッシュできるかどうかを制御します。
依存関係スキャンの実行scanner_dep_scanning_running依存関係スキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。メモ: GitLabセルフマネージドインスタンス(18.4以降)では、アーティファクトの相違により、SBOMベースの依存関係スキャンを使用すると、このコントロールが失敗する可能性があります。互換性に関する考慮事項を参照してください。
リポジトリごとに2人の管理者を確保ensure_2_admins_per_repo少なくとも2人のオーナーが各プロジェクトに割り当てられていることを確認します。
エラートラッキングが有効error_tracking_enabledプロジェクトでエラートラッキングが有効になっていることを確認します。
強制プッシュが無効force_push_disabledリポジトリへの強制プッシュを防止します。
プロジェクトのフォークが存在するhas_forksプロジェクトがフォークされていることを確認します。
ファズテストの実行scanner_fuzz_testing_runningプロジェクトのデフォルトブランチパイプラインでファズテストが構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。
GitLabライセンスレベルUltimategitlab_license_level_ultimateGitLabインスタンスがUltimateライセンスを使用していることを確認します。
有効なCI/CD設定があるhas_valid_ci_configプロジェクトに有効なCI/CD設定があることを確認します。
IaCスキャンの実行scanner_iac_runningInfrastructure as Code(IaC)スキャンが構成され、プロジェクトのデフォルトブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。
内部表示レベルが禁止されているproject_visibility_not_internalプロジェクトが内部表示レベルに設定されていないことを確認します。
イシュートラッキングが有効issue_tracking_enabledプロジェクトでイシュートラッキングが有効になっていることを確認します。
ライセンスコンプライアンスを実行中scanner_license_compliance_runningプロジェクトのデフォルトブランチパイプラインでライセンスコンプライアンススキャンが構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。
マージリクエストのコミットにより承認がリセットされるmerge_request_commit_reset_approvalsマージリクエストへの新しいコミットで承認がリセットされることを確認します。
マージリクエストの承認ルールでは編集を禁止merge_requests_approval_rules_prevent_editingマージリクエストの承認ルールを編集できないようにします。
マージリクエストにはコードオーナーの承認が必要merge_requests_require_code_owner_approvalマージリクエストにはコードオーナーからの承認が必要であることを確認します。
管理者よりもメンバーが多いmore_members_than_adminsプロジェクトに割り当てられている管理者(オーナーまたはメンテナー)の数が、メンバーの総数よりも少ないことを確認します。
トリアージされていないパッケージハンターの検出結果なしpackage_hunter_no_findings_untriagedすべてのパッケージハンターの検出結果がトリアージされていることを確認します。
プロジェクトはアーカイブされていませんproject_archivedプロジェクトがアーカイブされているかどうかを確認します。通常、falseに準拠しています。
プロジェクトは削除対象としてマークされていませんproject_marked_for_deletionプロジェクトが削除対象としてマークされているかどうかを確認します。falseに準拠しています。
プロジェクトパイプラインは公開されていませんproject_pipelines_not_publicプロジェクトパイプラインが公開されていないことを確認します。
プロジェクトリポジトリが存在するproject_repo_existsプロジェクトにGitリポジトリが存在することを確認します。
プロジェクトの表示レベルは公開されていませんproject_visibility_not_publicプロジェクトが公開表示レベルに設定されていないことを確認します。
保護ブランチが存在するprotected_branches_setプロジェクトに保護ブランチが含まれていることを確認します。
プッシュ保護が有効push_protection_enabled機密ファイルに対してプッシュ保護が有効になっていることを確認します。
ブランチを最新にする必要require_branch_up_to_dateソースブランチが、マージする前にターゲットブランチと一致していることを確認します。
直線的な履歴が必要require_linear_historyマージコミットを禁止することで、直線的なコミット履歴を確保します。
組織レベルでMFAが必要require_mfa_at_org_level組織レベルで多要素認証が必須であることを確認します。
コントリビューターにMFAが必要require_mfa_for_contributorsコントリビューターが多要素認証を有効にしていることを確認します。
署名されたコミットが必要require_signed_commits署名されたコミットが必須であることを確認します。
プッシュ時に承認をリセットreset_approvals_on_pushマージリクエストに新しいコミットがプッシュされると承認がリセットされることを確認します。
ディスカッションを解決する必要があるresolve_discussions_requiredマージが許可される前に、すべてのディスカッションを解決する必要があることを確認します。
プッシュ/マージアクセスを制限restrict_push_merge_access保護ブランチへのプッシュまたはマージを許可するユーザーを制限します。
ビルドへのアクセス制限restricted_build_accessビルドアーティファクトとパイプライン出力へのアクセスを制限することを確認します。
古いリポジトリを確認してアーカイブするreview_and_archive_stale_repos古いリポジトリを確認してアーカイブされていることを確認します。
非アクティブなユーザーを確認して削除するreview_and_remove_inactive_users非アクティブなユーザーを確認して削除されていることを確認します。
SASTを実行中scanner_sast_runningプロジェクトのデフォルトブランチパイプラインで静的アプリケーションセキュリティテスト(SAST)が構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。
シークレット検出を実行中scanner_secret_detection_runningプロジェクトのデフォルトブランチパイプラインでシークレット検出スキャンが構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。
セキュアWebhooksecure_webhooksWebhookが安全に構成されていることを確認します。
古いブランチのクリーンアップを有効stale_branch_cleanup_enabled古いブランチの自動クリーンアップが有効になっていることを確認します。
ステータスチェックが必要status_checks_requiredマージが許可される前にステータスチェックに合格する必要があることを確認します。
ステータスページの設定status_page_configuredプロジェクトにステータスページが構成されていることを確認します。
リポジトリに対する厳密なアクセス許可strict_permissions_for_repoリポジトリ・アクセスに対して厳密なアクセス許可が設定されていることを確認します。
Terraformが有効terraform_enabledプロジェクトでTerraformインテグレーションが有効になっていることを確認します。
ユーザー定義のCI/CD変数はメンテナーに制限project_user_defined_variables_restricted_to_maintainersメンテナーロール以上のユーザーのみがパイプラインをトリガーする際にユーザー定義変数を渡すことができるようにします。
脆弱性のSLO日数がしきい値を超過vulnerabilities_slo_days_over_threshold脆弱性が、サービスレベル目標(SLO)のしきい値(180日)内で処理されるようにします。

外部コントロール

外部コントロールとは、外部コントロールまたは要件のステータスを要求する外部システムへのAPIコールです。

サードパーティツールにデータを送信する外部コントロールを作成できます。

コンプライアンススキャンの実行時に、GitLabは通知を送信します。ユーザーまたは自動化されたワークフローは、GitLabの外部からコントロールのステータスを更新できます。

このインテグレーションにより、ServiceNowなどのサードパーティ製ワークフローツール、または選択したカスタムツールとインテグレーションできます。サードパーティツールは、関連付けられたステータスで応答します。このステータスは、コンプライアンスステータスレポートに表示されます。

プロジェクトごとに外部コントロールを構成できます。外部コントロールはプロジェクト間で共有されません。外部コントロールが6時間以上保留状態のままの場合、ステータスチェックは失敗します。

外部コントロールを追加する

フレームワークの作成時または編集時に外部コントロールを追加するには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、フレームワークタブを選択します。
  4. 新規フレームワークを選択するか、既存のものを編集します。
  5. 要求セクションで、新しい要件を選択します。
  6. 外部コントロールの追加を選択します。
  7. フィールドで、外部コントロール名外部URLHMAC shared secret(共有シークレット)を編集します。
  8. オプション。Ping enabled(Pingを有効にする) 切替をオフにして、コンプライアンススキャン中にGitLabが外部サービスに通知を送信するかどうかを制御します。
  9. フレームワークへの変更を保存を選択して、要件を保存します。

Pingが有効な設定

Ping enabled(Pingを有効にする) の設定は、GitLabが外部システムから外部コントロール・ステータスの更新を12時間ごとにリクエストするかどうかを制御します。

  • 有効(デフォルト): GitLabは、HTTPリクエストを外部サービスのURLに12時間ごとに自動的に送信し、応答に基づいて外部コントロール・ステータスを更新します。
  • 無効: GitLabは外部サービスに通知を送信せず、外部コントロールはコンプライアンスフレームワークのUIに無効バッジを表示します。外部コントロールのステータスをリクエストするには、外部コントロールAPIを手動で使用する必要があります。

外部コントロール・ライフサイクル

外部コントロールにはasynchronous(非同期)ワークフローがあります。コンプライアンススキャンは、ペイロードを外部サービスに送信するたびに発行します。

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Workflow for external compliance controls
    accDescr: GitLab sends a requirement payload to an external service and receives a control response for compliance validation.

    GitLab->>+External service: Requirement payload
    External service-->>-GitLab: Control response
    Note over External service,GitLab: Response includes SHA at HEAD

ペイロードを受信すると、外部サービスは必要なプロセスを実行できます。次に、外部サービスはREST APIを使用して、応答をマージリクエストにポストバックできます。

外部コントロールには、3つのステータスのいずれかを設定できます。

ステータス説明
pendingデフォルトの状態外部サービスから応答を受信しませんでした。
pass外部サービスから応答を受信し、外部コントロールが外部サービスによって承認されました。
fail外部サービスから応答を受信し、外部コントロールが外部サービスによって拒否されました。

GitLabの外部で何かが変更された場合は、APIを使用して外部コントロールのステータスを設定できます。最初にペイロードが送信されるのを待つ必要はありません。

要件を追加

フレームワークの作成時または編集時に要件を追加するには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、フレームワークタブを選択します。
  4. 新規フレームワークを選択するか、既存のものを編集します。
  5. 要求セクションで、新しい要件を選択します。
  6. ダイアログで、名前説明を追加します。
  7. GitLabコントロールを追加するを選択して、コントロールを追加します。
  8. コントロール・ドロップダウン・リストでコントロールを検索して選択します。
  9. フレームワークへの変更を保存を選択して、要件を保存します。

要件の編集

フレームワークの作成時または編集時に要件を編集するには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
  2. 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
  3. ページで、フレームワークタブを選択します。
  4. 新規フレームワークを選択するか、既存のものを編集します。
  5. 要求セクションで、アクション > 編集を選択します。
  6. ダイアログで、名前説明を編集します。
  7. GitLabコントロールを追加するを選択して、コントロールを追加します。
  8. コントロール・ドロップダウン・リストでコントロールを検索して選択します。
  9. コントロールを削除するには、 remove を選択します。
  10. フレームワークへの変更を保存を選択して、要件を保存します。

トラブルシューティング

コンプライアンスフレームワークを操作しているときに、次の問題が発生する可能性があります。

エラー: Unable to determine the correct upload URL

JSONテンプレートと同じ名前のコンプライアンスフレームワークがすでに存在する場合、コンプライアンスフレームワークのインポート中にこのエラーが発生します。