Front DoorのHTTP DDoS防御：Allowで回避できない評価順序とDRの学習待ちを検証する

結論：許可通信と防御の準備状態を別々に受け入れる

編集上の判断：Azure Front Door PremiumにHTTP DDoS防御を導入する変更は、WAFの設定追加と疎通設計の変更を一体で審査してください。外形監視が失敗したとき、オリジン障害とWAFの判定を切り分けられる状態を完了条件にします。

編集上の設計パターン：通常の公開API、監視用エンドポイント、負荷試験を区別し、期待する通過・記録・遮断を試験票に記載します。広い許可で一度に解決する方法は、意図しない通信まで検査対象から外す原因になるため、例外の所有者と終了条件も決めます。

背景と技術的要因：Allowと例外は同じ制御ではない

確認済み事実：HTTP DDoSはカスタムルールより先に評価されます。カスタムAllowはHTTP DDoSを回避せず、ほかのWAF検査を回避します。信頼する要求をHTTP DDoSから外すには、例外を使用します。出典：HTTP DDoSルールセット、WAF例外一覧。

確認済み事実：例外はリモートIP、URI、要求ヘッダーを使って要求を識別し、特定のルール等へ範囲を限定できます。要求の一部分の検査を省くexclusionsと、対象ルールの評価を省く例外は区別されます。出典：WAF例外一覧。

編集上の分析：監視サービスからのアクセスを既存Allowで許可していても、HTTP DDoS追加後の挙動は再確認が必要です。また、URIや自己申告ヘッダーだけの一致を認証として扱わず、なりすまし可能性とオリジン側の認可を別途検証します。

適用期日・数値・対象リソース／APIバージョン

確認済み事実：対象はFront Door PremiumのMicrosoft_HTTPDDoSRuleSet_1.0です。500100・500110は一般提供、geoの500310・500320はプレビューです。割当て時はLog・中感度が既定です。出典：HTTP DDoSルールセット。

確認済み事実：過去7日間の少なくとも50%でトラフィックを受け取るプロファイルでは、24～36時間以内に学習して検出を開始すると説明されています。履歴が不足すると検出・緩和せず、同一ポリシーでもしきい値はプロファイル別に学習します。出典：HTTP DDoSルールセット。

日付の区別：HTTP DDoS資料の表示更新日＝2026-10-22。一般提供の初回公表日＝null、一般提供の正確な開始日＝null、既存環境への一律強制適用日＝null、非推奨化期日＝nullです。24～36時間は条件付きの学習目安であり、自社環境の復旧保証時間ではありません。記事公開日・確認日＝2026-11-04。

確認済み事実：本記事で参照するIaCスキーマはMicrosoft.Network/FrontDoorWebApplicationFirewallPoliciesのAPIバージョン2026-04-01です。この版の資料にはmanagedRules.exceptionsListとpolicySettings.modeが定義されています。APIバージョンの文字列を機能の公表日や必須移行期限として扱いません。出典：Bicep・ARM・Terraform AzAPIリファレンス。

アーキテクチャ・IaC：例外、アクション、適用先を明示する

確認済み事実：例外一覧の公式説明は、次世代WAFエンジンとDRS 2.1以降を前提としています。例外は各WAFポリシーで最大60件、Front Door全体でも関連ポリシーを合計して最大60件です。出典：WAF例外一覧。

確認済み事実：Detectionモードは記録のみで、Preventionモードでは一致したルールの指定アクションを実行します。ポリシーがDisabledなら検査は停止します。ルールのアクションとpolicySettings.mode、enabledStateを併せて確認してください。出典：WAFポリシー設定。

編集上の提案：最初にPremiumのSKU、WAFポリシーID、関連付け先、既存DRS、カスタムAllow、ルールごとの状態・アクション・感度を採取します。Terraform/Bicepの宣言と実リソースを照合し、管理されていないポータル変更を残さないようにします。

編集上の実装確認：例外のmatchVariable、matchValues、scopes、ruleSetType、ruleSetVersion、ruleIdを、採用するAPI版のスキーマで検証してください。表示名Microsoft_HTTPDDoSRuleSet_1.0をruleSetTypeへそのまま転記せず、サービスから取得した値と照合します。使用中のTerraformプロバイダーが必要な属性を扱えるかも確認します。

編集上の受入条件：planまたはwhat-ifで既存ルールの消失、対象拡大、意図しないモード変更を点検します。検証環境で再適用し、保存後のGET結果を宣言と比較してください。例外が残ったことに加え、例外対象外の要求では防御が維持されることを試験します。

運用・監視・フェイルオーバー・責任分界

確認済み事実：HTTP DDoS資料は、学習が完了し対処可能になるとIs Activeメトリックが1になると説明しています。監視データ資料にはWAF要求数のPolicyName、RuleName、Actionディメンションがあります。出典：HTTP DDoSルールセット、監視データリファレンス。

編集上の監視案：学習状態、ルール一致、実際の遮断、正当な要求の成功率を別々に記録します。Is Active＝1だけでは、Logから遮断へ変更したことや、すべての正常通信が通ることを証明できません。外形監視の失敗とWAFログ、オリジンの応答を時刻で突き合わせます。

編集上のDR検証：待機中の別プロファイルや新規再作成先について、本番と同じ設定でも学習済みとは仮定しません。切替前後の学習状態と疎通を確認し、未学習期間に利用するレート制限、オリジンへのアクセス制限、容量管理を設計します。これらを組み合わせても同等の防御を保証するものではありません。

編集上の責任分界案：Microsoftが提供する学習機能に対し、適用先・例外・アクションの管理は基盤担当、正常通信の定義はアプリ担当、誤検知時の変更承認と証跡保全は運用・セキュリティ担当で分担します。監視サービスや取引先の送信元変更も変更管理の対象にします。

適用上の前提：本記事は個別環境の設計保証や法的助言を行うものではありません。実装適用にあたっては、検証環境での事前テストおよび契約・業務範囲の確認が必要です。以下のチェックリストは編集上の提案であり、試験量・合格値・切戻し条件は自社環境で定義してください。