セキュリティテレメトリー

セキュリティテレメトリとは、セキュリティインシデントを検出して調査するためにGitLabから収集するデータです。

GitLabセキュリティオペレーションチームは、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスの管理者、およびGitLab.comのネームスペースのオーナー向けに、これらの推奨事項を作成しました。これらを使用して、GitLabが生成するセキュリティテレメトリの種類、それぞれが示す情報、および提供形態とサブスクリプションのプランで収集できる内容を理解してください。これらは、組織が定義するログ記録およびモニタリングのプロセスを補完するものであり、それらに代わるものではありません。

検出が発生した場合は、セキュリティインシデントへの対応に従って、インシデントを封じ込めて修正してください。

セキュリティテレメトリの種類

GitLabは、2種類の主なセキュリティテレメトリを生成します。それぞれ異なる質問に答え、異なる方法で収集されるため、可能な限り両方を使用してください。

監査イベント: ユーザーのサインイン、権限の変更、トークンの作成、設定の変更など、セキュリティに関連するアクションが発生したときにGitLabが発行する構造化されたイベントです。各イベントは、誰が実行したか、何が影響を受けたか、どのIPアドレスから、いつ実行されたかを記録します。監査イベントは「GitLabでユーザーが何を行ったか」という質問に答えます。GitLabは数百種類の監査イベントタイプを定義しています。

アプリケーションログ: GitLab Railsアプリケーションと周辺コンポーネントによって書き込まれるログファイルです: Workhorse、Gitaly、GitLab Shell、Sidekiq。これらは、すべてのHTTPリクエスト、Git操作、バックグラウンドジョブを記録します。この活動の多くは、失敗したリクエストやブロックされたリクエスト、監査対象外のエンドポイントへのリクエスト、リクエストの正確なパラメータ、GitLabがそれを処理するために実行した内部ステップなど、監査イベントにはなりません。アプリケーションログは「GitLab内部で何が起こったか」という質問に答えるものであり、GitLab自体に対する悪用の試みを検出するための唯一の情報源です。

これら2つに加えて、CI/CDジョブログや認証情報インベントリなど、いくつかのGitLab機能は独自にセキュリティ関連のデータを記録します。詳細については、その他のセキュリティデータのソースを参照してください。

提供形態とプランで収集できる内容

次の表は、各提供形態において、セキュリティテレメトリを収集する各方法に必要な最小のプランを示しています。GitLab DedicatedはUltimateでのみ利用可能であるため、この表のすべての項目はGitLab Dedicatedで利用できます。

実際には、これは次のことを意味します:

• Freeでは、自分自身のサインインイベントの確認やCI/CDジョブログのレビューは可能ですが、グループ、プロジェクト、インスタンスの監査イベントは表示できません。GitLab Self-Managedでは、それでもアプリケーションログを収集できます。これにはaudit_json.logに書き込まれる少数の監査イベントが含まれます。
• Premiumでは、GitLabで監査イベントを表示および検索したり、APIで取得したりできますが、ストリーミングはできません。GitLab内部で何が起こっているかを把握できないわけではありませんが、検出と長期保持はお客様の責任で行う必要があります。
• Ultimateでは、ほぼリアルタイムでSIEMに監査イベントをストリーミングでき、GitLabには決して表示されないストリーミング専用イベントを受信できます。

監査イベントの表示

PremiumおよびUltimateでは、設定を行わなくても監査イベントを表示できます:

• GitLab UIのグループ、プロジェクト、インスタンスレベルで表示できます。インスタンスレベルの監査イベントは、GitLab Self-ManagedおよびGitLab Dedicatedで利用できます。
• 監査イベントAPIを使用すると、UIと同じイベントが返されます。

Freeでは、表示できる唯一の監査イベントは、ユーザープロファイルの認証ログにある自分自身のサインインイベントのみです。

監査イベントの表示は、スポットチェックや、事後に特定のユーザーやプロジェクトを調査するには十分です。検出には、いくつかの理由から十分ではありません:

• 各クエリは30日間のウィンドウに制限されており、UIではイベントの詳細を検索できません。
• 一部のイベントタイプはストリーミング専用であり、GitLabには決して表示されません。
• イベントに対してアラートを設定したり、他のデータと関連付けたり、保持期間を制御したりすることはできません。

監査イベントをストリーミングできない場合は、スケジュールに従ってAPIから取得し、ログプラットフォームに読み込むことができます。これにより、遅延が発生し、ストリーミング専用イベントは含まれないものの、検索可能なコピーと検出の基盤を得ることができます。

監査イベントのストリーミング

監査イベントのストリーミングは、監査イベントが発生するとすぐに、管理下にある宛先にすべての監査イベントを送信するため、SIEMは完全な、ほぼリアルタイムの記録を保持します。ストリーミングは、すべての提供形態で監査イベントを収集するための推奨方法であり、ストリーミング専用イベントを受信する唯一の方法です。

ストリーミング専用イベント

一部の監査イベントタイプはストリーミング専用です。これらはGitLabに保存されず、ストリーミング先を設定している場合にのみ受信できます。それらの多くは機密データへの読み取りアクセスを記録するため、検出に特に役立ちます。例:

これは完全なリストではありません。すべてのストリーミング専用イベントについては、利用可能な監査イベントタイプのリストにあるデータベースに保存列を参照してください。

ストリーミングの設定

ストリーミングを設定する場所は、提供形態によって異なります:

ストリーミングは、HTTPエンドポイント、Google Cloud Logging、Amazon S3の3つの宛先タイプをサポートします。複数の宛先を追加し、イベントタイプごとに各宛先をフィルタリングできます。

受信側を設計する際は、以下を考慮してください:

• 時折重複した配信が発生することを想定し、イベントのidで重複排除してください。
• GitLab.comでは、宛先側でGitLab.com IP範囲からのトラフィックを許可してください。
• 宛先は機密情報として扱ってください。ストリーミングされるイベントには、完全なイベントの詳細が含まれます。
• 多数の宛先を計画している場合は、宛先の上限を確認してください。

アプリケーションログの収集

監査イベントは、アクションが発生したことを示します。アプリケーションログは、その方法を示します。これらは、監査イベントが要約するリクエストレベルの詳細を提供し、失敗したリクエスト、レート制限されたリクエスト、監査対象外のエンドポイントへのリクエスト、各リクエストの完全なパラメータなど、監査イベントがまったく存在しない、セキュリティに関連する大量の活動を記録します。アプリケーションログを収集できる場合は、収集してください。

セキュリティに関連するログ

次のログは、セキュリティモニタリングに最も関連性があります。パスは、Linuxパッケージインストールでは/var/log/gitlab/からの相対パスです。ログシステムのドキュメントでは、Helmチャートインストールで同じログを見つける場所について説明しています。

ログ間でリクエストを追跡する

GitLabが処理するすべてのリクエストには相関IDが付与され、WorkhorseからRails、Gitaly、Sidekiqに至るまで、そのリクエストが関係するすべてのログに同じIDが表示されます。1つのログで不審なエントリを見つけた場合は、すべてのログでその相関IDを検索し、リクエスト全体を再構築してください。詳細については、相関IDを使用して関連するログエントリを見つけるを参照してください。

アプリケーションログをプラットフォームに転送する

GitLab Self-Managedの場合: 各ノードからログプラットフォームへ、選択したログシッパーを使用してログを転送します。GitLabはログをローカルでローテーションし、最終的には古いファイルを削除するため、ローテーションによってログが削除される前に転送してください。ローテーションを調整するには、ログ記録の設定を参照してください。マルチノードのデプロイでは、相関IDの検索がリクエスト全体をカバーするように、プラットフォームがすべてのノードからログを集約していることを確認してください。

GitLab Dedicatedの場合: GitLabは、AWSアカウント内のAmazon S3バケットにアプリケーションおよびインフラストラクチャのログを配信し、1年間保持します。Switchboardでログコレクターにバケットへの読み取りアクセスを許可してください。1年以上ログが必要な場合は、独自のストレージにコピーしてください。設定手順については、GitLab Dedicatedのアプリケーションログを参照してください。

その他のセキュリティデータのソース

監査イベントおよびアプリケーションログに加えて、いくつかのGitLab機能は、直接確認したり検出に取り込んだりできるセキュリティ関連のデータを記録します。それらのほとんどは、収集の設定なしでGitLab UIで利用でき、いくつかはすべてのプランで利用できます。

次の手順

テレメトリがSIEMまたはログプラットフォームに到達した後:

• 監視する信号を決定し、TLDR検出ルールをデプロイするには、検出機能の構築を参照してください。
• 検出が依存するイベントタイプ、特にストリーミング専用のものが、プラットフォームに到達していることを確認してください。ストリーミングではなくAPIで監査イベントを収集している場合は、受信していないイベントに依存する検出がないか確認してください。
• 調査とコンプライアンスのニーズを満たす保持期間を定義してください。GitLabは保存された監査イベントを無期限に保持しますが、実際に検索できる内容はストリーミング先とログプラットフォームによって定義されます。

関連トピック

• セキュリティインシデント
• GitLabを保護する