クラウドサービス

Azure Web Application Firewall

SQL インジェクションや XSS などの Web 攻撃を L7 で防ぐマネージド WAF。Application Gateway や Front Door に統合し、OWASP ベースのルールで防御する。AWS WAF に相当。

中級セキュリティ信頼性運用上の優秀性
3つの要点
  1. OWASP ルールセットで SQL インジェクションや XSS など L7 攻撃を防ぐマネージド WAF。
  2. Application Gateway(リージョン)か Front Door(グローバル)に紐づけて使う。
  3. AWS WAF に相当し、まず検出モードで誤検知を確認してから防御モードへ切り替える。

解決する課題

Azure Web Application Firewall(WAF)は、HTTP/HTTPS リクエストの中身を検査し、よく知られた Web 攻撃を入口でブロックするマネージドのファイアウォールです。アプリ側のコードを変えずに、既知の脅威への防御を一括で前段に持てます。

  • SQL インジェクションや XSS(クロスサイトスクリプティング)などのOWASP Top 10 系の攻撃を遮断したい
  • 攻撃シグネチャを自前で書かずに、ベンダーが更新するマネージドルールで守りたい
  • 特定の国・IP・リクエストパターンに対するカスタムルールやレート制限をかけたい
  • 悪意あるボットやスクレイパーをボット対策ルールで緩和したい
  • アプリ層の防御状況をログとして可視化し、攻撃の傾向を把握したい

WAF は単独のリソースではなく、Application Gateway(リージョン内の L7)または Front Door(グローバルなエッジ)に紐づけて動作します。どちらに載せるかで適用範囲やルールの世代が変わります。

主要概念と用語

  • WAF ポリシー (WAF policy): ルール・モード・設定をまとめた中心リソース。Application Gateway や Front Door のエンドポイント、リスナー、パスに関連付ける
  • マネージドルールセット (Managed rule set): Microsoft が提供・更新する既知攻撃向けのルール群。OWASP の Core Rule Set(CRS)をベースにしたものが代表
  • カスタムルール (Custom rule): IP アドレス、地理的な国、HTTP ヘッダ、クエリ文字列などの条件で許可・拒否・レート制限を定義する利用者作成のルール
  • レート制限ルール (Rate limit rule): 一定時間あたりのリクエスト数がしきい値を超えたクライアントをブロックし、ボリューム攻撃や総当たりを緩和する
  • ボット対策ルール (Bot protection): 既知の良性・悪性ボットを分類し、悪性ボットのアクセスを制御するマネージドルール
  • 検出モード (Detection): ルールに一致してもブロックせずログだけ記録するモード。誤検知の確認に使う
  • 防御モード (Prevention): ルールに一致した要求を実際にブロックするモード
  • 除外 (Exclusion) / 無効化ルール: 正常な要求を誤って遮断する場合に、特定のルールやパラメータを評価対象から外す設定
  • 異常スコア (Anomaly scoring): CRS で各ルール一致に重みを与えて合算し、しきい値を超えたらブロックする評価方式

仕様・制限・クォータ

  • WAF はスタンドアロンでは動かず、Application Gateway(WAF_v2 SKU)または Front Door(Premium、およびカスタムルールに限れば Standard)に関連付けて使う
  • マネージドルールは OWASP の Core Rule Set をベースに複数バージョンが提供され、新しい世代ほど対応攻撃や精度が向上する。利用側でバージョンを選べる
  • 検出モードと防御モードを切り替えられ、まず検出で誤検知を確認するのが定石
  • カスタムルールは Application Gateway 側と Front Door 側で記述方式や上限が異なる。同じ「WAF」でも基盤が別物である点に注意
  • レート制限とボット対策に対応するが、利用可能な機能やルールの粒度は紐づけ先と SKU で差がある(Front Door はマネージドルールに Premium が必要など)
  • ポリシー数、カスタムルール数、条件数、リクエストボディの検査サイズなどに上限がある。具体的な数値は変動するため最新の公式ドキュメントで確認する

内部の仕組み

WAF は前段のプロキシ(Application Gateway または Front Door)がTLS を終端した後の平文 HTTP 要求を検査します。暗号化されたままでは中身を見られないため、復号後・バックエンド転送前のタイミングで評価されます。

  • 受信要求の URL・ヘッダ・クエリ文字列・本文(ボディ)を、マネージドルールとカスタムルールに照らして評価する
  • CRS は各ルール一致に重みを与えて異常スコアを合算し、しきい値を超えると要求をブロックする(異常スコアリング方式)
  • カスタムルールはマネージドルールより優先して評価され、明示的な許可・拒否・レート制限を先に適用できる
  • 検出モードではルールに一致してもブロックせずログのみ記録し、防御モードでは実際に遮断する
  • Front Door に載せた WAF は世界中のエッジ(POP)で評価され、Application Gateway に載せた WAF はそのリージョンのゲートウェイで評価される
TLS を終端しないと検査できない

WAF は復号後の HTTP を見て判定します。エンドツーエンドで暗号化したまま素通しする経路では中身を検査できません。検査を効かせるには、前段の Application Gateway や Front Door で必ず TLS を終端する構成にします。

横にスクロール

Application GatewayまたはFront Doorで復号したHTTP要求をWAFのカスタム規則と管理規則で評価し、許可要求だけをWebアプリへ送る処理図
WAF は検出モードのログで誤検知を調整してから防止モードへ移します。規則全体を無効化せず、要求の特定箇所だけを狭く除外し、送信元が WAF を迂回できないようオリジンも制限します。

設計パターン / ベストプラクティス

  • 適用範囲で紐づけ先を選ぶ: リージョン内の L7 防御なら Application Gateway WAF_v2、グローバルなエッジ防御なら Front Door の WAF を使う
  • まず検出モードで運用開始し、ログで誤検知(フォールスポジティブ)を洗い出してから防御モードへ切り替える
  • 誤検知は除外ルールで個別に外す。ルールセット全体を無効化せず、影響するルールやパラメータだけを評価対象から外す
  • カスタムルールで地理・IP・パターンの制御を加える。マネージドルールでは拾えない業務固有の脅威に対応する
  • レート制限を併用して総当たりやボリューム攻撃を緩和する
  • ポリシーを共通化して再利用し、複数のアプリやエンドポイントに同じ防御基準を適用して運用を揃える

運用・監視

  • WAF ログを Log Analytics や Storage、Event Hub に出力し、どのルールが何をブロック・検出したかを継続的に確認する
  • Azure Monitor のメトリクスで一致数やブロック数の推移を監視し、攻撃の急増を検知する
  • ルールセットを更新したら、検出モードで一定期間ならし運転してから防御モードに上げると安全
  • 正常な業務リクエストがブロックされたら、ログで該当ルール ID を特定し除外を追加する
  • ボット対策やレート制限の効果をログとメトリクスで定期的に見直し、しきい値を実トラフィックに合わせる

コスト

WAF は紐づけ先の料金体系に組み込まれます。Application Gateway では WAF_v2 SKU の固定時間課金とキャパシティユニットの従量課金に WAF 分が含まれ、Front Door では WAF ポリシーとマネージドルールの利用に応じた課金が加わります。マネージドルールを本格的に使う場合、Front Door では上位 SKU が前提になる点に注意します。

コスト最適化

WAF 単独でコストを最小化するより、紐づけ先(Application Gateway か Front Door)の選定がコストを左右します。リージョン内防御で足りるのにグローバル配信基盤を抱える、あるいはその逆、といったミスマッチを避けましょう。マネージドルールが要るかどうかで Front Door の必要 SKU が変わる点も事前に見積もります。

セキュリティ

  • マネージドルール(OWASP ベースの CRS)を有効化し、SQL インジェクションや XSS など既知の L7 攻撃を遮断する
  • ボット対策ルールで悪性ボットやスクレイパーを緩和する
  • カスタムルールとレート制限で、地理ブロック・IP 制限・総当たり緩和など業務固有の防御を足す
  • オリジン(バックエンド)への直接アクセスを塞ぐ。WAF を迂回されないよう、Front Door なら X-Azure-FDID 検証やサービスタグ、Private Link で前段経由のみ許可する
  • L3/L4 の大規模 DDoS には Azure DDoS Protection を併用し、WAF は L7 の攻撃緩和に専念させる
アンチパターン

WAF を前段に置いても、バックエンドが公衆インターネットに直接公開されたままだと、攻撃者は WAF を迂回してオリジンを直撃できます。WAF の効果を出すには、オリジンへの直接到達を必ず遮断し、すべての通信を WAF 経由に強制してください。

関連サービス・比較

Azure の WAF は載せる基盤が 2 つあり、リージョン内かグローバルかで使い分けます。AWS の AWS WAF が CloudFront や ALB などに関連付けて使う構成に近く、対応を押さえると選定が速くなります。

観点Application Gateway WAFFront Door WAF
適用範囲リージョン内の L7グローバルなエッジ(POP)
紐づけ先 SKUWAF_v2Premium(カスタムのみ Standard)
評価される場所リージョンのゲートウェイ世界中のエッジ
マネージドルールOWASP ベースの CRSOWASP ベースの CRS
レート制限・ボット対策対応対応
AWS の相当AWS WAF と ALB の組み合わせAWS WAF と CloudFront の組み合わせ

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Application Gateway 向けの WAF ポリシーを作成
az network application-gateway waf-policy create \
  --resource-group demo-rg \
  --name demo-waf-policy

# まずは検出モードに設定(誤検知の確認用)
az network application-gateway waf-policy policy-setting update \
  --resource-group demo-rg \
  --policy-name demo-waf-policy \
  --mode Detection \
  --state Enabled

# OWASP ベースのマネージドルールセットを有効化
az network application-gateway waf-policy managed-rule rule-set add \
  --resource-group demo-rg \
  --policy-name demo-waf-policy \
  --type OWASP \
  --version 3.2

# 特定の国からのアクセスを拒否するカスタムルールを追加
az network application-gateway waf-policy custom-rule create \
  --resource-group demo-rg \
  --policy-name demo-waf-policy \
  --name BlockByCountry \
  --priority 10 \
  --rule-type MatchRule \
  --action Block

# 誤検知の確認後、防御モードへ切り替え
az network application-gateway waf-policy policy-setting update \
  --resource-group demo-rg \
  --policy-name demo-waf-policy \
  --mode Prevention \
  --state Enabled

Azure Service

Azure Web Application Firewallを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

ネットワーキング

比較で見る軸

クラウド: Azure / カテゴリ: ネットワーキング / 難易度: intermediate

導入後に効く点

Application Gateway(リージョン)か Front Door(グローバル)に紐づけて使う。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
ネットワーキング
難易度
intermediate
関連資格
設計柱
security / reliability / operational

判断チェックリスト

  • 自社の用途が「ネットワーキング / security」に近いか確認する。
  • 強みである「OWASP ルールセットで SQL インジェクションや XSS など L7 攻撃を防ぐマネージド WAF。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

ネットワーキングsecurityreliabilityoperational