正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

送信リクエストをフィルタリングする

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

データ損失と漏洩のリスクから保護するために、GitLabのインスタンスの管理者は、送信リクエストフィルタリングコントロールを使用して、GitLabインスタンスによって行われる特定の送信リクエストを制限できるようになりました。

Webhookとインテグレーションの保護

少なくともメンテナーロールを持つユーザーは、プロジェクトまたはグループで特定の変更が発生したときにトリガーされるwebhooksをセットアップできます。トリガーされると、POST HTTPリクエストがURLに送信されます。Webhookは通常、特定の外部Webサービスにデータを送信するように構成されており、そのWebサービスは適切な方法でデータを処理します。

ただし、Webhookは、外部Webサービスの代わりに、内部WebサービスのURLで構成できます。Webhookがトリガーされると、GitLabサーバーまたはそのローカルネットワーク上で実行されているGitLab以外のWebサービスが、悪用される可能性があります。

Webhookリクエストは、GitLabサーバー自体によって作成され、認可のために、ユーザートークンまたはリポジトリ固有のトークンの代わりに、フックごとに1つのオプションのシークレットトークンを使用します:

  • ユーザートークン。
  • リポジトリ固有のトークン。

その結果、これらのリクエストは、意図されているよりも広範なアクセスを持つ可能性があり、Webhookをホストするサーバー上で実行されているすべてのもの（以下を含む）へのアクセスが含まれます:

  • GitLabサーバー。
  • API自体。
  • 一部のWebhookの場合、そのWebhookサーバーのローカルネットワーク内の他のサーバーへのネットワークアクセス。これらのサービスが保護されていて、外部からアクセスできない場合でも同様です。

Webhookを使用して、認証を必要としないWebサービスを使用して破壊的なコマンドをトリガーできます。これらのWebhookは、GitLabサーバーにPOST HTTPリクエストをリソースを削除するエンドポイントに送信させることができます。

Webhookとインテグレーションからのローカルネットワークへのリクエストを許可する

前提要件:

  • インスタンスへの管理者アクセス権が必要です。

脆弱なな内部Webサービスが悪用されるのを防ぐため、次のローカルネットワークアドレスへのすべてのWebhookおよびインテグレーションリクエストは許可されていません:

  • 現在のGitLabインスタンスサーバーアドレス。
  • 127.0.0.1、::1、0.0.0.0、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16などのプライベートネットワークアドレス、およびIPv6サイトローカル（ffc0::/10）アドレス。

これらのアドレスへのアクセスを許可するには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開する。
  4. ウェブフックとインテグレーションからローカルネットワークへの要求を許可するチェックボックスを選択します。

システムフックからのローカルネットワークへのリクエストを禁止する

前提要件:

  • インスタンスへの管理者アクセス権が必要です。

システムフックは、デフォルトでローカルネットワークにリクエストを行うことができます。ローカルネットワークへのシステムフックリクエストを防ぐには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開する。
  4. システムフックからのローカルネットワークへのリクエストを許可するチェックボックスをオフにします。

DNSリバインディング攻撃保護の実施

前提要件:

  • インスタンスへの管理者アクセス権が必要です。

DNSリバインディングは、悪意のあるドメイン名がローカルネットワークアクセス制限を回避するために、内部ネットワークリソースに解決されるようにする手法です。GitLabには、この攻撃に対する保護がデフォルトで有効になっています。この保護を無効にするには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開する。
  4. DNSリバインディング攻撃の保護を実施するチェックボックスをオフにします。

リクエストのフィルタリング

前提要件:

  • GitLabインスタンスへの管理者アクセス権が必要です。

多数のリクエストをブロックすることでリクエストをフィルタリングするには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開する。
  4. 許可リストで定義されているIPアドレス、IP範囲、およびドメイン名を除くすべてのリクエストをブロックで定義されているIPアドレス、IP範囲、およびドメイン名を除くすべてのリクエストをブロックするチェックボックスを選択します。

このチェックボックスがオンになっている場合でも、次のリクエストはブロックされません:

  • Geo、Git、GitLab Shell、Gitaly、PostgreSQL、Redisなどのコアサービス。
  • オブジェクトストレージ。
  • 許可リストにあるIPアドレスとドメイン。

この設定は、メインのGitLabアプリケーションでのみ有効です。そのため、Gitalyなどの他のサービスは、ルールを破るリクエストを行うことができます。さらに、GitLabの一部の領域では、送信フィルタリングルールが適用されません。

特定のIPアドレスおよびドメインへの送信リクエストを許可する

前提要件:

  • インスタンスへの管理者アクセス権が必要です。

特定のIPアドレスとドメインへの送信リクエストを許可するには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 設定 > ネットワークを選択します。
  3. アウトバウンドリクエストを展開する。
  4. フックとインテグレーションがアクセスできる、ローカルIPアドレスとドメイン名に、IPアドレスとドメインを入力します。

エントリは、次のようになります:

  • セミコロン、カンマ、または空白（改行を含む）で区切ることができます。
  • ホスト名、IPアドレス、IPアドレス範囲などのさまざまな形式にすることができます。IPv6がサポートされています。Unicode文字を含むホスト名は、Internationalized Domain Names in Applications（IDNA）エンコードを使用する必要があります。
  • ポートを含めます。たとえば、127.0.0.1:8080は、127.0.0.1のポート8080への接続のみを許可します。ポートが指定されていない場合、そのIPアドレスまたはドメイン上のすべてのポートが許可されます。IPアドレス範囲は、その範囲内のすべてのIPアドレスのすべてのポートを許可します。
  • 各エントリに255文字以下の1000個以下のエントリを番号付けします。
  • ワイルドカード（たとえば、*.example.com）を含めないでください。

例:

example.com;gitlab.example.com
127.0.0.1,1:0:0:0:0:0:0:1
127.0.0.0/8 1:0:0:0:0:0:0:0/124
[1:0:0:0:0:0:0:1]:8080
127.0.0.1:8080
example.com:8080

トラブルシューティング

送信リクエストをフィルタリングすると、次のイシューが発生する可能性があります。

構成されたURLがブロックされている

構成されたURLがブロックされない場合、許可リストで定義されているIPアドレス、IP範囲、およびドメイン名を除くすべてのリクエストをブロックで定義されているIPアドレス、IP範囲、およびドメイン名を除くすべてのリクエストをブロックするチェックボックスのみを選択できます。そうでない場合、URLがブロックされているというエラーメッセージが表示されることがあります。

この設定を有効にできない場合は、次のいずれかを実行します:

  • URL設定を無効にします。
  • 別のURLを構成するか、URL設定を空のままにします。
  • 構成されたURLを許可リストに追加します。

パブリックランナーリリースURLがブロックされている

ほとんどのGitLabインスタンスでは、public_runner_releases_urlがhttps://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-runner/releasesに設定されているため、リクエストのフィルタリングを妨げる可能性があります。

このイシューを解決するには、GitLabがGitLab.comからランナーリリースバージョンデータをフェッチしないように構成します。

GitLabサブスクリプション管理がブロックされている

リクエストをフィルタリングすると、GitLabサブスクリプション管理がブロックされます。

この問題を回避するには、customers.gitlab.com:443を許可リストに追加します。

GitLabドキュメントがブロックされている

リクエストをフィルタリングすると、Help page documentation base url is blocked: Requests to hosts and IP addresses not on the Allow List are deniedというエラーが表示されることがあります。このエラーを回避するには、次の手順に従います:

  1. エラーメッセージHelp page documentation base url is blockedが表示されなくなるように、変更を元に戻します。
  2. docs.gitlab.com、またはリダイレクトヘルプドキュメントページURLを許可リストに追加します。
  3. 変更を保存を選択します。

GitLab Duo機能がブロックされている

リクエストをフィルタリングすると、GitLab Duoの機能を使用しようとしたときに、401エラーが表示されることがあります。

このエラーは、GitLabクラウドサーバーへの送信リクエストが許可されていない場合に発生する可能性があります。このエラーを回避するには、次の手順に従います:

  1. https://cloud.gitlab.com:443を許可リストに追加します。
  2. 変更を保存を選択します。
  3. GitLabがクラウドサーバーにアクセスできるようになったら、手動でライセンスを同期します

詳細については、GitLab Duoコード提案のトラブルシューティングドキュメントを参照してください。