• 侵害された疑いのあるユーザーアカウント
• 侵害が疑われるインスタンス

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

セキュリティ・インシデントが発生したら、組織で定義されたプロセスに従うべきです。ただし、いくつかの追加手順を検討することもできます。これらの提案は、組織内の既存のセキュリティ・インシデント対応プロセスを補完するためのものです。

侵害された疑いのあるユーザーアカウント

ユーザーアカウントまたはボットアカウントが侵害された疑いがある場合は、次の手順を実行してください：

• ユーザーをブロックして、現在のリスクを軽減します。
• 利用可能な監査イベントをレビューして、疑わしいアカウントの動作を特定します。例えば
  • 疑わしいサインインイベント。
  • 個人アクセストークン、プロジェクトアクセストークン、グループアクセストークンの作成または削除。
  • SSHキーまたはGPGキーの作成または削除。
  • 二要素認証の作成、変更、削除。
  • リポジトリの変更。
  • グループまたはプロジェクト設定の変更。
  • ランナーの追加または変更。
  • WebhookやGitフックの追加や変更。
• ユーザーがアクセスできたかもしれない認証情報をリセットします。例えば、少なくともメンテナーのロールを持つユーザーは、保護されたCI/CD 変数と Runner 登録トークンを見ることができます。
• ユーザーのパスワードをリセットします。
• ユーザーに2要素認証(2FA)を有効にしてもらい、インスタンスまたはグループレベルで2FAを実施することを検討します。
• 調査を完了し、影響を緩和した後、ユーザーのブロックを解除します。

侵害が疑われるインスタンス

セルフマネージドGitLabの顧客と管理者は、以下の責任を負います：

• 基盤となるホストのセキュリティ。
• GitLab 自体を最新の状態に保つこと。

GitLabを定期的にアップデートし、オペレーションシステムとそのソフトウェアをアップデートし、ベンダーのガイダンスに従ってホストを堅牢化することが重要です。

GitLabインスタンスへの侵入が疑われる場合は、以下の手順を取ることを検討してください：

• 不審なアカウントの振る舞いがないか、監査イベントをレビューしてください。
• すべてのユーザー（管理ルートユーザーを含む）をレビューし、必要であれば「危険なユーザーアカウントの疑い」の手順に従ってください。
• クレデンシャルインベントリをレビューします。
• 機密性の高いクレデンシャル、変数、トークン、シークレットを変更します。例えば、インスタンス設定、データベース、CI/CDパイプラインなどにあるものです。
• GitLabを最新バージョンにアップグレードし、セキュリティパッチリリースごとにアップグレードする計画を採用しましょう。

さらに、以下の提案は、悪意のある行為者によってサーバーが侵害された場合にインシデント対応計画で取られる一般的なステップです。

• サーバーの状態とログは、後で調査するために、書き込み可能な場所に保存してください。
• 認識されていないバックグラウンドプロセスを探します。
• システムのポートが開いていないか確認します。
• ホストを既知のバックアップから、またはゼロから再構築し、最新のセキュリティパッチをすべて適用します。
• 異常なトラフィックがないか、ネットワークログをレビューします。
• ネットワーク・モニタリングとネットワーク・レベル・コントロールの確立
• インバウンドおよびアウトバウンドのネットワークアクセスを、作成者ユーザおよびサーバのみに制限。
• すべてのログが独立した書き込み専用のデータストアにルーティングされるようにします。