次の方法で共有


CloudEvents スキーマを使用したエンドポイントの検証

Webhook は、Azure Event Grid からイベントを受信する多数ある方法の 1 つです。 新しいイベントの準備ができるたびに、Event Grid サービスは、本文にイベント情報が含まれる HTTP 要求を構成済み HTTP エンドポイントに POST します。

Webhook をサポートする他の多くのサービスと同様に、Event Grid を使用するには、Webhook エンドポイントへのイベントの配信を開始する前に、そのエンドポイントの所有権を証明する必要があります。 この要件により、悪意のあるユーザーはエンドポイントをイベントで氾濫させることができなくなります。

CloudEvents v1.0 を使用したエンドポイントの検証

CloudEvents v1.0 では、HTTP OPTIONS メソッドを使用して、独自の不正使用防止のセマンティクスが実装されます。 出力に CloudEvents スキーマを使用すると、Event Grid では、Event Grid の検証イベント メカニズムではなく CloudEvents v1.0 の不正使用防止が使用されます。

CloudEvent v1.0 の不正使用保護

任意の HTTP エンドポイントへの通知の登録と配信を許可するあらゆるシステムは、そのような要求を予期していない、および登録者側がそのような登録を実行する権限を持たないシステムのアドレスを、悪意を持って、または誤って登録するように悪用されるおそれがあります。 極端なケースでは、任意の Web サイトに対してサービス拒否攻撃を開始するために通知インフラストラクチャが悪用される場合があります。

このような方法で送信者が悪用されないようにするには、正当な配信先が、配信される通知に同意することを示す必要があります。

配信の同意への到達は、次の検証ハンドシェイクを使用すると実現します。 ハンドシェイクは、登録時に直ちに実行することも、配信の直前に "プレフライト" 要求として実行することもできます。

ハンドシェイクは認証または認可コンテキストの確立を目的としていないことを理解しておくことが重要です。 これは、トラフィックを予期していない宛先にプッシュするように指示されることから送信者を保護するためだけに機能します。 この仕様では承認モデルの使用が義務付けられていますが、その Web サイトがアクセス制御を実装していないために Authorization ヘッダーを無視する場合、この要求は不要なトラフィックから任意の Web サイトを保護するのに十分ではありません。

配信先は、不正使用保護機能をサポートしている必要があります。 対象がこの機能をサポートしていない場合、送信者は宛先に送信しないか、または非常に低い要求レートでのみ送信することを選択できます。

検証要求

検証要求では、HTTP OPTIONS メソッドが使用されます。 要求は、登録されている正確なリソース ターゲット URI に送信されます。 検証要求を使用すると、送信者は対象に通知を送信するアクセス許可を要求し、望ましい要求レート (1 分あたりの要求数) を宣言できます。 配信先は、アクセス許可ステートメントと許可された要求レートで応答します。 次に、検証要求に含めるためのヘッダー フィールドをいくつか示します。

WebHook-Request-Origin

WebHook-Request-Origin ヘッダーは検証要求に含める必要があり、この送信者から通知を送信する許可を要求し、送信システムを識別するドメイン ネーム システム (DNS) 式 (例: eventemitter.example.com) を含みます。 この値は、個々のホストではなく、特定のシステムの代わりに動作するすべての送信者インスタンスを要約して識別するためのものです。

ハンドシェイクの後、許可が与えられた場合、送信者は各配信リクエストにOrigin 要求ヘッダーを、このヘッダーの値と一致する値で使う必要があります。

例:

WebHook-Request-Origin: eventemitter.example.com

検証応答

配信先でイベントの配信が許可されている場合にのみ、WebHook-Allowed-OriginWebHook-Allowed-Rate ヘッダーを含めて要求に応答する必要があります。 配信先がコールバックによってアクセス許可を付与することを選択した場合、応答ヘッダーは保持されます。

配信先がイベントの配信を許可しない場合、またはイベントの配信が予期されていないが、HTTP OPTIONS メソッドを処理する場合は、既存の応答を同意として解釈しないようにする必要があるため、ハンドシェイクは状態コードに依存できません。 配信先が HTTP OPTIONS メソッドを処理しない場合は、OPTIONS がサポートされていないかのように、HTTP 状態コード 405 で応答する必要があります。

OPTIONS 応答には、POST メソッドが許可されていることを示す Allow ヘッダーを含める必要があります。 リソースに対して他のメソッドが許可される場合がありますが、その機能はこの仕様の範囲外です。

WebHook-Allowed-Origin

配信先が配信元サービスによる通知配信に同意した場合、WebHook-Allowed-Origin ヘッダーを返す必要があります。 その値は、配信先がすべての配信元からの通知をサポートしていることを示す、WebHook-Request-Origin ヘッダーで指定された配信元名か、単一のアスタリスク文字 ('*') である必要があります。

WebHook-Allowed-Origin: eventemitter.example.com

または

WebHook-Request-Origin: *

重要

不正使用の保護の詳細については、イベント配信仕様の HTTP 1.1 Web フックでの不正使用の保護に関するページを参照してください。

イベント サブスクリプション検証をトラブルシューティングする方法については、イベント サブスクリプション検証のトラブルシューティングに関する記事を参照してください。