Azure Front DoorのWAFでサービスタグの条件が正式に 許可の書き方に注意

Azure Front DoorのWAFで、接続元のIPアドレスが、どのAzureのサービスのものかで判定できるようになりました。Microsoftは「サービスタグ」の条件を正式に提供し、IPアドレスの一覧を自分で持たずに、Azureのサービスからの通信を許可・遮断できるとしています。便利な一方、許可のルールの書き方を誤ると守りが弱くなるため、Microsoftは注意点も示しています。Azureの更新情報とMicrosoft Learnの説明から整理します。

何ができるようになったか

Azureの更新情報(2026年10月20日掲載)によると、Azure Front Door PremiumのWAFのカスタムルールで、要求の接続元のIPアドレスを、サービスタグと照らせるようになりました。サービスタグは、Azureのサービスが使うIPアドレスの範囲をまとめたもので、アドレスが変わるとMicrosoftが自動で更新します。

Microsoftは、次のような使い方を挙げています。

• 監視や死活の確認など、アプリが頼っているAzureのサービスを通す
• アプリに要求を送ってくるはずのないAzureのサービスからの通信を止める
• 管理画面などの大事な道を、サービスタグとURI・ホスト・要求の種類の条件を組み合わせて絞る
• 遮断ではなく、Azureのサービスからの通信の回数を制限する

設定は、カスタムルールの照合の項目を「SocketAddr」か「RemoteAddr」に、演算子を「ServiceTagMatch」にして、タグの名前を選びます。複数のタグを選べ、どれかに入れば一致します。タグの名前は完全一致で、ワイルドカードや一部の一致は使えません。

SocketAddrとRemoteAddrの違い

照合の項目は2つあり、違いが大事です。

SocketAddrは、Front Doorに実際につないだTCPの接続元のアドレスで、サービスタグのルールではふつうこちらを使います。RemoteAddrは、X-Forwarded-Forのヘッダーから取った元の利用者のアドレスです。このヘッダーは送る側が自由に書けるため、RemoteAddrで許可するルールは、SocketAddrより偽りやすいとMicrosoftは注意しています。

許可のルールで気をつけること

Microsoftの説明書は、サービスタグでルールを作るときの注意点を、次のようにまとめています。

• タグはサービスを表し、利用者を表さない。タグには、そのサービスのすべての利用者のアドレスが入ります。タグを許可すると、そのサービスを通じて通信を送れる誰からでも通るため、本人の確認ではなく、粗いふるいとして扱います
• タグだけでは守りにならない。そのサービスがどんな通信を送るかを理解したうえで許可し、ほかの守りも残します
• いちばん狭いタグを使う。AzureCloudのような広いタグは、思わぬ範囲まで届きます
• タグの中身は変わる。今日と明日で、一致するアドレスは同じではありません
• まずは記録だけで試す。新しいルールは、ログの動作か、WAFのポリシーの検出のモードで入れ、ログを見てから遮断に切り替えます。とくに許可のルールは、誤りが目に見える障害にならず、守りが静かに弱くなるため大事です
• 条件を組み合わせる。URIの道、ホスト、要求の種類の条件と組み合わせ、影響する範囲を絞ります

あわせて、許可(Allow)の動作は、その要求について既定のルールセットとボットの保護のルールセットの判定を止めるとしています。許可のルールは、できるだけ狭く作ります。

影響する会社・しない会社

• 影響する: Azure Front Door PremiumのWAFで、Webのサービスを守っている会社です。監視のサービスのためにIPの一覧で例外を作っている場合は、サービスタグに置き換えて管理を軽くできます。
• 影響する: WAFの例外の作り方を、社内の決まりで定めている会社です。許可のルールの範囲の決め方を見直すきっかけになります。
• 影響しない: Front DoorのStandardや、ほかのWAFだけを使っている会社です。今回の説明の対象は、Front Door PremiumのWAFです。

情シスが今日やること

• 今のIPの例外を洗い出す。Front DoorのWAFのカスタムルールで、Azureのサービスのために作ったIPアドレスの一覧の例外を探し、サービスタグで置き換えられるかを確かめます。
• AzureCloudのような広いタグで許可しない。許可は、目的に合う狭いタグと、道やホストの条件を組み合わせて作ります。広いタグの許可は、Azureの上で動く誰の通信でも通しうると考えます。
• SocketAddrを基本にする。RemoteAddrで許可するルールは、なりすましに弱いため、使う理由を書き残します。
• 記録のモードで試してから遮断に。新しいルールはまずログの動作で入れ、数日の記録を見てから切り替えます。許可のルールは、既定のルールセットとボットの保護を飛ばす点も、変更の承認のときに確かめます。