Content last updated 2026-09-16

GitLab セキュリティロギング標準

概要

GitLab セキュリティロギング標準は、GitLab の製品とインフラ全体でセキュリティ関連イベントをどのように取得、構造化、保持する必要があるかを定義します。その目的は、脅威の検出を可能にし、セキュリティインシデントの調査を支援し、GitLab.com、GitLab Dedicated、セルフマネージド環境全体で一貫性と信頼性のあるログの網羅性を確保することです。

基本原則

  • 検出を最優先 - アカウント乗っ取り、権限昇格、データの不正持ち出し、CI/CD の悪用などの重大な脅威を検出するために必要な情報をログに記録します。
  • 調査可能性 - ログから、誰が、何を、いつ、どこから、何に対して行い、どのような結果になったかを把握できなければなりません。
  • 一貫性 - イベントの関連付けと検出を支援するため、イベントの種類、フィールド名、意味を製品領域間で統一しなければなりません。
  • プライバシーとデータの最小化 - セキュリティに必要な情報のみをログに記録し、認証情報、シークレット、不要な個人データの記録を避けます。
  • 信頼性 - 重要なセキュリティイベントを通知なく破棄してはなりません。ロギングは障害に耐えられるものでなければなりません。
  • コストへの配慮 - 標準フィールドを持つ、件数が少なく価値の高いイベントを優先します。

イベントの分類

Product チームは、次のカテゴリのセキュリティ関連イベントが構造化イベントとしてログに記録されるようにしなければなりません。

  • 認証イベント(ログイン、ログアウト、MFA チャレンジ、SSO ログイン、ログイン失敗)
  • セッションのライフサイクルイベント(セッションの作成、更新、終了)
  • 認可と権限の変更(ロールの変更、権限の変更、ポリシーの変更)
  • アカウントのライフサイクルイベント(アカウントの作成、無効化、削除、パスワードまたはメールアドレスの変更、MFA の登録)
  • トークンとキーのライフサイクル(パーソナルアクセストークン、OAuth トークン、CI トークン、SSH キー、デプロイキーの作成、ローテーション、失効)
  • プロジェクト、リポジトリ、コードのイベント(プロジェクトの作成または削除、プッシュ、強制プッシュ、保護ブランチの変更、マージリクエストの承認)
  • CI/CD パイプラインとジョブのイベント(パイプラインの作成と承認、手動トリガー、Runner の登録)
  • データアクセスとエクスポートのイベント(一括ダウンロード、リポジトリのクローン、メンバーリストまたはセキュリティレポートのエクスポート)
  • 設定と管理のイベント(SSO、二要素認証ポリシー、IP 制限、Webhook、インテグレーションの変更)
  • セキュリティコントロールと検出のイベント(レート制限によるブロック、不正利用の検出、ポリシー違反)
  • API 利用イベント(セキュリティに影響する API 操作:管理者の操作、トークン管理、設定変更)
  • バックグラウンド処理とシステムの操作(自動失効、アカウントロック、定期クリーンアップ)

共通の必須フィールド

すべてのセキュリティイベントは構造化(JSON)し、少なくとも以下を含めなければなりません。

  • イベントの種類とエンティティの種類
  • UTC タイムスタンプ(ISO-8601)
  • 一意のイベント識別子
  • アクターの識別子とユーザー名
  • 送信元 IP アドレス
  • 対象リソースの識別子、種類、詳細
  • 結果(成功、失敗、不明)

データ保護

セキュリティログには、パスワード、パスワードハッシュ、トークン、シークレット、秘密鍵を決して含めてはなりません。識別子が必要な場合は、ハッシュ、フィンガープリント、または一部を切り詰めた値を使用します。運用目的でログに記録する追加のコンテキストは、記録範囲を限定し、機密情報をマスキングし、保持制限とアクセス制御を適用しなければなりません。

ログ形式と転送

セキュリティイベントは、安定したフィールド名を持つ構造化形式(JSON)でログに記録しなければなりません。すべてのセキュリティイベントで UTC タイムスタンプを使用しなければなりません。GitLab が管理する環境(GitLab.com、Dedicated)では、ログをセキュリティロギングプラットフォームと SIEM に転送しなければなりません。セルフマネージド環境では、お客様が自身の SIEM にエクスポートできるよう、ログにアクセスでき、標準的なログ転送ツールと互換性がなければなりません。


目的と適用範囲

このセキュリティロギング標準の目的は、GitLab のセキュリティロギング要件を定義することです。本書は、GitLab の SIEM(Devo)におけるセキュリティロギングと、SIEM にログを送信していないシステム向けのセキュリティロギング要件の双方をカバーします。

役割と責任

役割責任
GitLab システムオーナー(GitLab の Tech Stack で定義)本標準に記載された要件を遵守することに直接的な責任を負います
Security Operations チームSecurity チームの SIEM(Security Information Event Management)システムである Devo において、ログの優先順位付け、オンボーディング、保守を直接的に担当します。

セキュリティロギング要件

セキュリティログは GitLab で使用されるアプリケーションとシステムによって生成され、主にセキュリティ監視、セキュリティインシデント対応、サイバー脅威ハンティングに使用されます。

GitLab Security Operations チームは、既存システムのセキュリティログの優先順位を反復的に評価し、セキュリティ可観測性を向上させるためにオンボーディングする必要がある新規ログソースのリクエストを評価します。Security Operations チームは、SIEM 内のセキュリティログに関する Single Source of Truth(SSOT)を維持しています。

GitLab で新しいアプリケーション、システム、サービスがオンボードされた際に、システムのセキュリティログ(例: アプリ、OS、トランザクションログ)が GitLab の SIEM に送信されない場合、セキュリティログは保持ポリシーに沿った期間、承認されたセキュアストレージに保存される必要があります。

セキュリティログ保持要件

セキュリティログの説明保持要件
本番システムのセキュリティログ最低 1 年
本番ではないクリティカルシステムのセキュリティログ最低 90 日

セキュリティログ収集要件

最低限、GitLab の本番システムおよび本番外のクリティカルな GitLab システムについて、認証イベントとトランザクションイベントを収集しなければなりません。

セキュリティイベントとフィールドの詳細な説明は以下に示します。

セキュリティログイベントタイプ必須?セキュリティログフィールド
認証イベントはいユーザー
認証イベントはいタイムスタンプ
認証イベントはいソース IP アドレス
認証イベントはいデスティネーション IP アドレス
認証イベントはい試行されたアクション
認証イベントはいアクション結果(成功または失敗)
トランザクションイベントはいユーザー
トランザクションイベントはいタイムスタンプ
トランザクションイベントはいソース IP アドレス
トランザクションイベントはい試行されたアクション
トランザクションイベントはいアクション結果(成功または失敗)
データアクセスイベントいいえ - ログの詳細度に依存ユーザー
データアクセスイベントいいえ - ログの詳細度に依存タイムスタンプ
データアクセスイベントいいえ - ログの詳細度に依存ソース IP アドレス
データアクセスイベントいいえ - ログの詳細度に依存試行されたアクション
データアクセスイベントいいえ - ログの詳細度に依存アクセスされたリソース
データアクセスイベントいいえ - ログの詳細度に依存アクション結果(成功または失敗)
アラートイベントいいえ - ログの詳細度に依存アラート名
アラートイベントいいえ - ログの詳細度に依存タイムスタンプ
アラートイベントいいえ - ログの詳細度に依存ユーザー
アラートイベントいいえ - ログの詳細度に依存ソース IP アドレス
セキュリティアラートイベントいいえ - ログの詳細度に依存アクション
セキュリティアラートイベントいいえ - ログの詳細度に依存アラートの追加詳細