セキュリティインシデントへの対応

セキュリティインシデントが発生した場合は、主に組織で定義されたプロセスに従う必要があります。GitLabセキュリティオペレーションチームは、このガイドを作成しました:

• GitLab Self-ManagedインスタンスおよびGitLab.com上のグループの管理者とメンテナー向け。
• GitLabサービスに関連する様々なセキュリティインシデントへの対応方法に関する追加情報とベストプラクティスを提供するため。
• セキュリティインシデントを処理するために組織で定義されたプロセスを補足するものとして。これはnot a replacement。

このガイドを使用することで、GitLabに関連するセキュリティインシデントの処理に自信を持てるようになるはずです。必要に応じて、このガイドはGitLabドキュメントの他の部分にリンクしています。

一般的なセキュリティインシデントのシナリオ

公開インターネットへの認証情報の露出

このシナリオは、設定ミスまたは人為的なミスにより、認証または認可に関する機密情報がインターネットに公開されたセキュリティイベントを指します。このような情報には、以下が含まれる可能性があります:

• パスワード。
• パーソナルアクセストークン。
• グループ/プロジェクトアクセストークン。
• Runnerトークン。
• パイプライントリガートークン。
• SSHキー。

このシナリオには、GitLabサービスを介した第三者の認証情報に関する機密情報の漏洩も含まれる場合があります。漏洩は、たとえば公開GitLabプロジェクトへの誤ったコミット、またはCI/CD設定の設定ミスによって発生する可能性があります。詳細については、以下を参照してください:

• GitLabトークンの概要
• GitLab CI/CD変数セキュリティ

レスポンス

認証情報の漏洩に関連するセキュリティインシデントは、トークンの種類とその関連権限によって、低から重大までの重大度で異なる場合があります。このようなインシデントに対応する際には、次のことを行う必要があります:

• トークンの種類とスコープを特定します。
• トークン情報に基づいて、トークンのオーナーと関連チームを特定します。
  • パーソナルアクセストークンの場合、パーソナルアクセストークンAPIを使用してトークンの詳細を迅速に取得することができます。
• トークンのスコープと潜在的な影響を評価した後、トークンを失効するかローテーションします。本番環境トークンの失効は、公開されたトークンによってもたらされるセキュリティリスクと、トークンの失効によって引き起こされる可能性のある可用性リスクとのバランスです。トークンを失効するのは、以下の条件を満たす場合のみです:
  • トークンの失効の潜在的な影響について十分に理解している。
  • 自社のセキュリティインシデント対応ガイドラインに従っている。
• 認証情報の漏洩時刻と認証情報を失効した時刻を記録します。
• GitLab監査ログをレビューし、公開されたトークンに関連する不正なアクティビティを特定します。トークンのスコープと種類に応じて、次の監査イベントを検索します:
  • 新規作成されたユーザー。
  • トークン。
  • 悪意のあるパイプライン。
  • コードへの変更。
  • プロジェクト設定への変更。

イベントの種類

• グループまたはネームスペースで利用可能な監査イベントをレビューします。
• 攻撃者は、永続性を維持するためにトークン、SSHキー、またはユーザーアカウントの作成を試みる場合があります。これらのアクティビティに関連する監査イベントを確認します。
• CI関連の監査イベントに焦点を当て、CI/CD変数への変更を特定します。
• 攻撃者によって実行されたパイプラインのジョブログを確認します。

侵害された可能性のあるユーザーアカウント

レスポンス

ユーザーアカウントまたはボットアカウントが侵害されたと疑われる場合は、次のことを行う必要があります:

• 現在のリスクを軽減するためにユーザーをブロックします。
• ユーザーがアクセスできた可能性のあるすべての認証情報をリセットします。たとえば、メンテナーまたはオーナーのロールを持つユーザーは、保護されたCI/CD変数とRunner登録トークンを表示できます。
• ユーザーパスワードをリセットします。
• ユーザーに2要素認証 （2FA）を有効にさせ、インスタンスまたはグループで2FAを強制することを検討します。
• 調査を完了し、影響を軽減した後、ユーザーのブロックを解除します。

イベントの種類

利用可能な監査イベントを確認して、不審なアカウントの動作を特定します。例:

• 不審なサインインイベント。
• パーソナルアクセストークン、プロジェクトアクセストークン、グループアクセストークンの作成または削除。
• SSHキーまたはGPGキーの作成または削除。
• 2要素認証の作成、変更、または削除。
• リポジトリへの変更。
• グループまたはプロジェクトの設定への変更。
• Runnerの追加または変更。
• WebhookまたはGitフックの追加または変更。
• 認可されたOAuthアプリケーションの追加または変更。
• 接続されたSAML Identity Providerへの変更。
• メールアドレスまたは通知への変更。

CI/CD関連のセキュリティインシデント

CI/CDワークフローは、現代のソフトウェア開発の不可欠な部分であり、主にデベロッパーとSREによってコードをビルドする、テストし、本番環境にデプロイするために使用されます。これらのワークフローは本番環境に接続されているため、CI/CDパイプライン内の機密シークレットへのアクセスが必要となることがよくあります。CI/CDに関連するセキュリティインシデントは、設定によって異なる場合がありますが、大きく分けて次のとおりです:

• 公開されたGitLab CI/CDジョブトークンに関連するセキュリティインシデント。
• 設定ミスによって公開されたGitLab CI/CDを介したシークレット。

レスポンス

公開されたGitLab CI/CDジョブトークン

パイプラインジョブが実行されようとすると、GitLabは一意のトークンを生成し、それをCI_JOB_TOKEN 定義済み変数として挿入します。GitLab CI/CDジョブトークンを使用して、特定のAPIエンドポイントで認証することができます。このトークンは、ジョブを実行させたユーザーと同じ権限でAPIにアクセスできます。このトークンは、パイプラインジョブの実行中にのみ有効です。ジョブが終了すると、トークンは有効期限切れになり、使用できなくなります。

通常の状況では、CI_JOB_TOKENはジョブログに表示されません。ただし、意図せずこのデータを公開してしまう可能性があります:

• パイプラインで詳細ログを有効にする。
• Shell環境変数をコンソールにエコーするコマンドを実行する。
• Runnerインフラストラクチャを適切に保護できない場合、このデータが意図せず公開される可能性があります。

このような場合は、次のことを行う必要があります:

• リポジトリ内のソースコードに最近の変更があるかどうかを確認します。変更を行ったアクターを特定するために、変更されたファイルのコミット履歴を確認できます。不審な編集が疑われる場合は、侵害された可能性のあるユーザーアカウントガイドを使用してユーザーアクティビティを調査します。
• そのファイルによって呼び出されるコードへの不審な変更は、問題を引き起こす可能性があり、調査されるべきであり、公開されたシークレットにつながる可能性があります。
• 失効の本番環境への影響を判断した後、公開されたシークレットのローテーションを検討します。
• ユーザーとプロジェクトの設定への不審な変更がないか、利用可能な監査ログを確認します。

設定ミスによって公開されたGitLab CI/CDを介したシークレット

CI変数として保存されているシークレットがマスクするされていない場合、それらはジョブログで公開される可能性があります。たとえば、環境変数をエコーしたり、詳細なエラーメッセージに遭遇したりする場合です。プロジェクトの表示レベルによっては、ジョブログが社内でアクセス可能な場合や、プロジェクトが公開されている場合はインターネット経由でアクセス可能である場合があります。このタイプのセキュリティインシデントを軽減するには、次のことを行う必要があります:

• 公開されたシークレットを公開されたシークレットのガイドに従って失効するします。
• 変数をマスクすることを検討します。これにより、それらがジョブログに直接反映されることを防ぐことができます。しかし、マスクは完全ではありません。たとえば、マスクされた変数はアーティファクトファイルに書き込まれたり、リモートシステムに送信されたりする可能性があります。
• 変数を保護することを検討します。これにより、それらが保護ブランチでのみ利用可能になります。
• ジョブログとアーティファクトへの公開アクセスを防ぐために、公開パイプラインを無効にすることを検討します。
• アーティファクトの保持と有効期限のポリシーを確認します。
• ベストプラクティスに関する詳細については、CI/CD ジョブトークンのセキュリティガイドに従ってください。
• 公開されたシークレットシステム（AWSのCloudTrailログやGCPのCloudAuditログなど）の監査ログを確認し、公開時に不審な変更が行われたかどうかを判断します。
• ユーザーとプロジェクトの設定への不審な変更がないか、利用可能な監査ログを再確認します。

侵害された可能性のあるインスタンス

GitLab Self-Managedのお客様と管理者は以下の責任を負います:

• 基盤となるインフラストラクチャのセキュリティ。
• GitLabインストールを最新の状態に保つこと。

GitLabを定期的に更新し、オペレーティングシステムとそのソフトウェアを更新し、ベンダーのガイダンスに従ってホストを強化することが重要です。

レスポンス

GitLabインスタンスが侵害された可能性があると疑われる場合は、次のことを行う必要があります:

• 利用可能な監査イベントを確認して、不審なアカウントの動作を特定します。
• 必要に応じて、すべてのユーザー （管理者ルートユーザーを含む）を確認し、侵害された可能性のあるユーザーアカウントガイドの手順に従います。
• 利用可能な場合は、認証情報インベントリを確認します。
• 機密認証情報、変数、トークン、およびシークレットを変更します。たとえば、インスタンス設定、データベース、CI/CDパイプライン、またはその他の場所にあるものです。
• GitLabの最新バージョンに更新し、セキュリティパッチリリース後に更新する計画を採用します。
• さらに、悪意のあるアクターによってサーバーが侵害された場合のインシデント対応計画でよく取られる手順は次のとおりです:
  1. サーバーの状態とログを一度だけ書き込める場所に保存し、後で調査できるようにします。
  2. 認識されていないバックグラウンドプロセスを探します。
  3. システム上のオープンポートを確認します。弊社のデフォルトポートガイドを出発点として使用できます。
  4. 既知の良好なバックアップからホストを再構築するか、ゼロから構築し、すべての最新セキュリティパッチを適用します。
  5. 異常なトラフィックがないかネットワークログを確認します。
  6. ネットワークモニタリングとネットワークレベルの制御を確立します。
  7. 受信および送信ネットワークアクセスを、認可されたユーザーとサーバーのみに制限します。
  8. すべてのログが独立した書き込み専用のデータストアにルーティングされていることを確認します。

イベントの種類

システムアクセス監査イベントを確認して、システム設定、ユーザー権限、ユーザーログインイベントに関連する変更を判断します。

プロジェクトまたはグループの設定ミス

不適切に設定されたプロジェクトまたはグループの設定の結果としてセキュリティインシデントが発生する可能性があり、機密データまたは専有データへの不正アクセスにつながる可能性があります。これらのインシデントには以下が含まれますが、これらに限定されるものではありません:

• プロジェクトの表示レベルの変更。
• MR承認設定の変更。
• プロジェクトの削除。
• プロジェクトへの不審なWebhookの追加。
• 保護ブランチ設定の変更。

レスポンス

プロジェクト設定への不正な変更を疑う場合は、次の手順を実行することを検討します:

• まず利用可能な監査イベントを確認して、アクションを担当したユーザーを特定します。
• ユーザーアカウントが不審な場合は、侵害された可能性のあるユーザーアカウントガイドに記載されている手順に従います。
• 監査イベントを参照し、プロジェクトオーナーとメンテナーにガイダンスを求めて、設定を元の状態に戻すことを検討します。

イベントの種類

• 監査ログはtarget_typeフィールドに基づいてフィルタリングできます。セキュリティインシデントのコンテキストに基づいて、このフィールドにフィルターを適用してスコープを絞り込みます。
• コンプライアンス管理の特定の監査イベントとグループとプロジェクトの監査イベントを探します。

セキュリティインシデントに関するGitLabからの支援の依頼

GitLabに助けを求める前に、GitLabドキュメントを検索してください。初期調査を完了し、追加の質問があるか支援が必要な場合にサポートを利用してください。GitLabサポートからの支援の資格はライセンスによって決定されます。

セキュリティベストプラクティス

環境を管理するための提案については、GitLabセキュリティドキュメントを確認してください。

強化の推奨事項

GitLab環境におけるセキュリティ対策状況を改善する方法については、強化に関する推奨事項をご覧ください。

乱用レート制限については、Git乱用レート制限に詳述されているとおり、実装を検討することもできます。乱用レート制限を設定すると、特定のセキュリティインシデントを自動的に軽減するのに役立つ場合があります。

検出

GitLab SIRTは、GitLab SIRT公開プロジェクトで検出のアクティブなリポジトリを維持しています。

このリポジトリの検出は、監査イベントと一般的なSigmaルール形式に基づいています。sigmaルールコンバーターを使用して、希望の形式でルールを取得できます。Sigma形式とその関連ツールに関する詳細については、リポジトリを参照してください。GitLab監査ログがSIEMにインジェストするされていることを確認してください。監査イベントストリーミングガイドに従って、自身のSelf-Managedインスタンス向けまたはGitLab.comトップレベルグループに監査イベントをストリーミングしてください。