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 アドレス |
| セキュリティアラートイベント | いいえ - ログの詳細度に依存 | アクション |
| セキュリティアラートイベント | いいえ - ログの詳細度に依存 | アラートの追加詳細 |
5d840611)