Azure Web Application Firewall (WAF) は、SQL インジェクション、クロスサイト スクリプティング (XSS)、パス トラバーサルなどの一般的な HTTP 層攻撃から Web アプリケーションを保護します。 ネットワーク レベルの脅威についてレイヤー 3 から 7 のトラフィックを検査するAzure Firewallとは異なり、WAF はレイヤー 7 でのみ動作し、要求ヘッダー、クエリ文字列、要求本文、Cookie などの HTTP セマンティクスを理解します。 WAF をAzure Application Gateway (リージョン) またはAzure Front Door (グローバル エッジ) にアタッチされたポリシーとしてデプロイし、保護スコープとアプリケーション アーキテクチャを一致させます。 Web Application Firewallは、Azure FirewallおよびAzure DDoS Protectionと並ぶ3つのコアAzureネットワークセキュリティサービスのうちの一つです。
この記事の内容
この記事では、Azure Web Application Firewallを使用した HTTP 層保護について説明します。 以下について学習します。
- Application Gateway v2 上の WAF と Azure Front Door 上の WAF のプラットフォーム比較。
- 既定の規則セット (DRS) とコア 規則セット (CRS) を含む OWASP ベースの規則セット。
- 検出モードと防止モード、および各モードを使用するタイミング。
- WAF ポリシー スコープ のオプション: グローバル、サイトごと、リスナーごとの関連付け。
- レート制限、geo フィルタリング、およびアプリケーション固有のロジックのカスタム ルール。
- WAF (レイヤー 7 HTTP) と Azure Firewall (レイヤー 3 ~ 7 ネットワーク) の違い。
この記事が必要なユーザー
ワークロードが次の条件の 1 つ以上を満たしている場合は、WAF をデプロイします。
- 一般向け Web アプリケーション: アプリケーションは、インターネットからの受信 HTTP/HTTPS トラフィックを受け入れ、インジェクション攻撃、認証の悪用の破損、機密データの漏洩の試行など、OWASP 上位 10 の脆弱性にさらされます。
- コンプライアンス要件: PCI DSS (Payment Card Industry Data Security Standard) などの規制フレームワークでは、支払いカード データを処理するアプリケーションの前に Web アプリケーション ファイアウォールが必要です。
- API 保護: API はパブリックにアクセス可能であり、要求の密輸、特大のペイロード、ネットワーク ファイアウォールが検査しないプロトコル レベルの攻撃に対する保護を必要とします。
- ボットの軽減策: 正当なクローラーと監視サービスを許可しながら、自動化されたトラフィックを分類して制御し、悪意のあるボットをブロックする必要があります。
HTTP 要求検査なしでネットワーク レベルのトラフィック フィルタリング (IP、ポート、プロトコル) のみを必要とする組織では、代わりに Azure Firewall または NSG を使用する必要があります。
リフトアンドシフトフォーカス: リホストされた内部アプリの多くは、インターネットのイングレスがなく、WAF を必要としません。 WAF を追加するのは、移行中または移行後に Web アプリをインターネットに公開する場合のみです。
モダナイズの重点: グローバル向けアプリの場合は Azure Front Door 上の WAF を、単一リージョン向けアプリの場合は Application Gateway 上の WAF を、Front Door と Traffic Manager の配信方法の選択に合わせて、フロントエンドの顧客向け Web アプリに適用します。
クラウド間のフォーカス:移行されたパブリック Web アプリのスポーク内の Application Gateway にレイヤー 7 WAF を配置し、他のクラウドの Web 保護 (Google Cloud Armor など) を Azure WAF にマップします。
AZURE WAF プラットフォームの比較
Azure WAF は 2 つのプラットフォームで使用できます。 各プラットフォームは、WAF 検査をトラフィック フロー内の異なるポイントに統合します。
| 能力 | Application Gateway v2 上の WAF | Azure Front Door での WAF |
|---|---|---|
| 配備の範囲 | リージョン (単一の Azure リージョン) | グローバル（世界各地に192か所以上のエッジPoPを展開） |
| 検査ポイント | トラフィックがお客様のリージョンに到達した後 | エッジ PoP で、トラフィックがオリジンに到達する前に |
| サポートされているルール セット | DRS 2.2、DRS 2.1、CRS 3.2 | DRS 2.2、DRS 2.1、DRS 2.0 |
| カスタム規則 | ✔ | ✔ |
| ボット保護 | ✔ | ✔ (Premium レベルのみ) |
| レート制限 | ✔ | ✔ |
| Geo-filtering | ✔ | ✔ |
| サイトごとのポリシー | ✔ (リスナー単位、パス単位) | ✔ (エンドポイントごと) |
| マネージド ルール セット | ✔ | ✔ (Premium レベルのみ。Standard では、カスタム ルールのみがサポートされます) |
| 要求本文の検査 | 最大 128 KB (構成可能) | 最大 128 KB (構成可能) |
| Private Link配信元のサポート | N/A (App Gateway を使用したインライン) | ✔ (プライベートオリジン接続) |
| 最適な用途 | 単一リージョン アプリ、L7 負荷分散 + WAF | マルチリージョンアプリ、グローバルアクセラレーション+WAF |
Note
Azure Front Doorには、Standard と Premium の 2 つのレベルがあります。 マネージド ルール セット (DRS やボット保護を含む) は、Front Door Premium でのみ使用できます。 Front Door Standard では、カスタム ルールのみがサポートされます。 Front Door (クラシック) では、DRS 1.1 以前のみがサポートされます。
WAF プラットフォームを選択する方法
次の決定基準を使用します。
- アプリケーションが 1 つのリージョンにデプロイされ、レイヤー 7 の負荷分散、TLS 終端、またはパスベースのルーティングに Application Gateway を既に使用している場合は、Application Gateway で WAF を選択します。 WAF は、追加のサービス ホップを導入することなく、HTTP 検査をインラインで追加します。
- アプリケーションが複数のリージョンにまたがる場合、グローバル負荷分散が必要な場合、またはコンテンツ配信ネットワーク (CDN) アクセラレーションの利点が必要な場合は、Azure Front Doorで WAF を選択します。 Front Door WAF は、最寄りのエッジのポイント オブ プレゼンス (PoP) でトラフィックを検査します。 サービスは、Azureバックボーンを通過して配信元に到達する前に、悪意のある要求をブロックします。 このアプローチでは、攻撃面の露出を減らし、エッジでボリュームレイヤー7攻撃を吸収します。
- Front Door によって提供されるマルチリージョン アプリケーションでバックエンドごとに異なるリージョン WAF ポリシーも必要な場合は、両方を選択します (階層化)。 Front Door では第 1 行のグローバル保護が提供されますが、Application Gateway WAF では、ワークロードに近いリージョン固有のカスタム規則が適用されます。
設計上の考慮事項
リフトアンドシフト WAF の設計フォーカス
- インターネットからの受信経路がない、内部専用として再ホストされたワークロードには WAF は不要です。アプリをインターネットに公開する際に再検討してください。
- Web アプリを公開する場合は、検出モードで WAF を開始してベースライン トラフィックに切り替え、誤検知を調整した後で防止に切り替えます。
- Application Gateway WAF は、レイヤー 7 ルーティング用の Application Gateway を既に使用している単一リージョンのリホストされた Web アプリに使用します。
- オンプレミスの Web 保護ルール（OWASP カバレッジなど）の考え方を、出発点となるポリシーとして再利用します。
WAF の設計フォーカスを最新化する
- 顧客向けアプリの WAF を最初から防止モードで実行し、最新のマネージド ルール セットを採用して、カバレッジが新しい OWASP の脅威を自動的に追跡できるようにします。
- ボット管理を有効にして、公開アプリを標的とする悪意のある自動化トラフィックと正当なクローラーを区別します。
- WAF ポリシーをコードとして管理し、アクティブ/アクティブなリージョン バックエンドがデプロイ パイプラインを通じて同期を維持できるようにします。
- エッジ WAF とハブ ファイアウォールを組み合わせて多層防御し、VNet で DDoS ネットワーク保護を有効にして Application Gateway WAF の課金割引を有効にします。
クラウド間 WAF の設計に重点を置く
- パブリック IP を仮想マシンに直接接続せずにパブリック Web トラフィックが検査されるように、スポーク VNet 内の Application Gateway でレイヤー 7 WAF をホストします。
- 他のクラウドの既存の Web 保護設定 (たとえば、AWS WAF や Google Cloud Armor) を Azure WAF のマネージド ルール セットにマップして、保護範囲を引き継げるようにします。
- WAF を介して公開通信を検査し、Virtual WAN ハブ ファイアウォールで東西およびクラウド間のトランジット検査を維持します。
- カットオーバー中は、まず検出 (学習) モードで WAF を実行し、正当なトラフィック パターンを確認したら適用します。
Prerequisites
Azure Web Application Firewallをデプロイする前に、次の内容を確認してください。
- Application Gateway v2 または Azure Front Door リソース: WAF は、これらのプラットフォームのいずれかにアタッチされたポリシーとしてデプロイされます。 WAF ポリシーを作成して関連付ける前に、既存の Application Gateway v2 インスタンスまたはAzure Front Door プロファイルをプロビジョニングしておく必要があります。
- 外部向け HTTP/HTTPS ワークロード: アプリケーションは HTTP/HTTPS の受信トラフィックを受け付ける必要があります。 WAF は要求レベルのセマンティクスを検査し、HTTP 以外のワークロードや純粋な内部サービスにはメリットがありません。
- HTTP トラフィック パターンの理解: アプリケーションの通常の要求パターン (ヘッダー、クエリ パラメーター、本文の内容) に関する知識は、除外を構成し、検出から防止モードへの移行中に誤検知を最小限に抑えるようにルールを調整するのに役立ちます。
ルール セットとルールの処理
WAF では、ルール セットを使用して HTTP 要求の悪意のあるパターンを検出します。 ルールの階層と処理順序を理解することは、特定のアプリケーションの WAF を調整するのに役立ちます。
マネージド ルール セット
Microsoftでは、OWASP Core Rule Set (CRS) パターンに基づいてマネージド ルール セットが保持されます。 新しいデプロイに推奨される規則セットは DRS 2.2 (既定の規則セット) です。 DRS 2.2 は OWASP CRS 3.3.4 を基盤とし、Microsoft Threat Intelligence のシグネチャが追加されています。
| ルール セット | に基づいて | プラットフォームのサポート | レコメンデーション |
|---|---|---|---|
| DRS 2.2 | OWASP CRS 3.3.4 + Microsoft Threat Intel | App Gateway v2、Front Door Premium | 新規導入に推奨 |
| DRS 2.1 | OWASP CRS 3.3 | App Gateway v2、Front Door Premium | 前の世代;両方のプラットフォームでサポートされています |
| DRS 2.0 | OWASP CRS 3.2 | Front Door Premium のみ | サポート対象; Front Door N-2 バージョン |
| CRS 3.2 | OWASP CRS 3.2 | App Gateway v2 のみ | サポート;新しいデプロイに DRS 2.2 を使用する |
DRS および CRS ルールセットでは 異常スコアリングを使用します。 一致する各ルールは、要求を直ちにブロックするのではなく、スコアを提供します。 累積異常スコアが構成可能なしきい値を超えると、WAF はアクション (ブロックまたはログ) を実行します。 この方法では、信頼度の低い 1 つの一致では適用がトリガーされないため、個々のルールブロックと比較して誤検知が減少します。
カスタム規則
カスタム ルールは、管理ルール の前に 実行され、優先度番号を使用して評価順序を制御します (数値が小さい = 優先度が高い)。 次の場合にカスタム ルールを使用します。
- レート制限: 資格情報の詰め込みとブルート フォース攻撃を軽減するために、時間枠内に各クライアント IP の要求を制限します。
- geo フィルタリング: クライアントの送信元の国または地域に基づいてトラフィックを許可または拒否します。
- IP 許可リストと拒否リスト: マネージド ルールが評価される前に、既知のパートナー IP を許可するか、既知の不良アクターをブロックします。
- 要求ヘッダー検査: 必須の API キーや想定されるコンテンツ タイプなど、アプリケーション固有の要件を適用します。
ボット保護規則セット
どちらのプラットフォームにも、自動トラフィックを適切なボット (検証済みの検索エンジン)、不適切なボット (既知の悪意のあるスキャナー)、不明なボットに分類するボット保護規則セットが用意されています。 カテゴリごとにアクションを構成します。適切なボットを許可し、不適切なボットをブロックし、レート制限または CAPTCHA を使用して不明なボットにチャレンジします。
検知モード vs. 予防モード
WAF ポリシーは、システムが一致した要求を処理する方法を決定する 2 つのモードのいずれかで動作します。
| Mode | Behavior | 利用シーン |
|---|---|---|
| 検出 | 一致した要求をログに記録しますが、ブロックしません。 要求はバックエンドに続きます。 | 初期デプロイとルールのチューニング。 本番トラフィックに影響を与えることなく、どのルールが発動するかを監視します。 |
| 予防 | 一致した要求をブロックし、403 応答を返します。 ブロックされた要求をログに記録します。 | ルールのチューニングが完了した後の運用ワークロード。 攻撃に対するアクティブな保護。 |
推奨されるチューニング ワークフロー
- 検出モードでデプロイする: 選択したルールセットで WAF を検出モードで有効にします。 WAF を介して運用トラフィックをルーティングします。
- ログの分析: WAF ログを確認して、誤検知を特定します。 正当なアプリケーション トラフィックでトリガーされる規則を決定します。
- 除外の作成: 誤検知を生成するルールの場合は、特定のルールに対してスキップする要求フィールド (ヘッダー、Cookie、クエリ パラメーター) を指定する除外を定義します。
- 防止モードに切り替えます。 誤検知率が許容されるクリーン検出ログの 1 ~ 2 週間後に、アクティブブロックの防止モードに切り替えます。
- 継続的な監視: 防止モードに切り替えた後、ログの監視を続行します。 新しいアプリケーション機能または API の変更により、新しい誤検知パターンが導入される可能性があります。
Important
運用ワークロードは常に防止モードで実行します。 検出モードでは保護が提供されません。 潜在的な攻撃のみをログに記録します。 検出モードは、最初のチューニング フェーズ中、または特定の誤検知の問題のトラブルシューティングを行うときにのみ使用します。
WAF ポリシーのスコープと関連付け
WAF ポリシーは、モードの選択、ルール セットの構成、カスタムルール、除外を含むスタンドアロンのAzure リソースです。 ポリシーを 1 つ以上のターゲットに関連付けて、保護スコープを制御します。
Application Gateway WAF ポリシーのスコープ
Application Gateway で、次の 3 つのレベルの粒度で WAF ポリシーを関連付けます。
- グローバル (ゲートウェイ全体): このポリシーは、Application Gateway のすべてのリスナーとパス規則に適用されます。 ゲートウェイの背後にあるすべてのアプリケーションが同じ保護要件を共有する場合は、グローバル スコープを使用します。
- リスナー レベル: 別の WAF ポリシーが特定のリスナー (ホスト名とポートの組み合わせ) に適用されます。 複数のアプリケーションがゲートウェイを共有しているが、異なるルールのチューニングまたは除外が必要な場合は、リスナー レベルのスコープを使用します。
- パス ルール レベル: WAF ポリシーは、リスナー内の特定の URL パス規則に適用されます。 バックエンドの感度が多様なアプリケーションをきめ細かく制御するために、パス ルール スコープを使用します。
複数のスコープが 1 つの要求に適用される場合、最も具体的なポリシーが優先されます。path-rule はリスナー レベルをオーバーライドし、グローバルをオーバーライドします。
Front Door WAF ポリシーの適用範囲
Front Door では、WAF ポリシーはエンドポイントまたはルート レベルで関連付けられます。 各 Front Door エンドポイントは、独自の WAF ポリシーを持つことができます。 この方法では、1 つの Front Door インスタンス内でアプリケーション固有の保護プロファイルを有効にします。
リソース間でポリシーを共有する
複数の Application Gateway インスタンスまたは Front Door エンドポイント間で 1 つの WAF ポリシーを共有します。 Azure Firewall Managerは、プラットフォームに関係なく、すべての WAF ポリシーで一元的な可視性と管理を提供します。 管理を簡素化し、一貫性のあるセキュリティ体制を維持するために、複数のリソースで同一の保護が必要な場合は、共有ポリシーを使用します。
Azure Firewallとの区別
WAF とAzure Firewallネットワーク スタックのさまざまなレイヤーを保護し、補完的な役割を果たします。 多層防御のために両方をデプロイします。
| Attribute | Web Application Firewall | Azure Firewall |
|---|---|---|
| OSI レイヤー | レイヤー 7 (HTTP/HTTPS のみ) | レイヤー 3 ~ 7 (ネットワークとアプリケーション) |
| トラフィックの種類 | Web アプリケーションへの受信 HTTP/HTTPS 要求 | すべての交通ルート (南北、東西) |
| 検査の重点 | HTTP セマンティクス: ヘッダー、本文、Cookie、URI | IP アドレス、ポート、プロトコル、FQDN、URL |
| ルールエンジン | OWASP ベースのパターン マッチング + 異常スコアリング | ネットワーク 規則、アプリケーション 規則、NAT 規則 |
| デプロイ モデル | App Gateway または Front Door との統合 | UDR ルーティングを使用したハブ サブネットでのスタンドアロン |
| ブロックされる一般的な攻撃 | SQL インジェクション、XSS、CSRF、パス トラバーサル | ポート スキャン、C2 コールバック、DNS 流出 |
一元化されたネットワーク トラフィック検査には、HTTP アプリケーション保護とAzure Firewallに WAF を使用します。 ハブスポーク アーキテクチャでは、インターネットから Web アプリケーションへのトラフィックは、通常、Azure Firewall (DNAT およびネットワーク レベルの検査用) を経由し、WAF を使用して Application Gateway を経由します (HTTP 層検査用)。 ネットワーク レベルコンポーネントのAzure Firewallとトラフィック検査を参照してください。
セキュリティに関する考慮事項
次のセキュリティプラクティスは、WAF からの保護を最大限に高めるのに役立ちます。
- 運用環境の防止モード: 運用環境のワークロードを検出モードのままにしないでください。 検出モードでは可視性は提供されますが、適用は行われません。アプリケーションは攻撃にさらされます。
- ルールのチューニングは進行中です。 アプリケーションは進化します。 新しい API エンドポイント、パラメーター、およびコンテンツ タイプは、既存のルール セットで誤検知をトリガーする可能性があります。 デプロイ後に WAF ログを定期的に確認します。
- Log Analytics統合: WAF 診断ログを Log Analytics ワークスペースに送信します。 ブロックされた要求、トリガーされたルール、および異常スコアの分布を視覚化するには、WAF ブックを使用します。
- DDoS と WAF の組み合わせ: WAF はレイヤー 7 アプリケーション攻撃から保護しますが、帯域幅消費型ネットワーク層 DDoS 攻撃は軽減されません。 WAF と Azure DDoS Protection をペアにして、フル スタック カバレッジを提供します。
- 配信元のロックダウン: Front Door WAF を使用する場合は、Front Door サービス タグからのトラフィックのみを受け入れるように配信元を構成します。 配信元のロックダウンがないと、攻撃者は Front Door をバイパスし、送信元 IP アドレスに直接要求を送信できます。
- 機密データ保護: WAF ログには要求データが含まれている場合があります。 WAF 診断ログの機密フィールド (承認ヘッダー、Cookie、または本文コンテンツ) をマスクするようにログ スクラブルールを構成します。
関連資料
次の記事では、関連するネットワーク セキュリティに関するトピックについて説明します。
- インターネットのイングレスとトラフィック ルーティング: 公開アプリケーションのイングレス パターン。
- アプリケーション配信サービス: 配信プラットフォームとしての Application Gateway と Front Door。
- Azure Firewallとトラフィック検査: WAF レイヤー 7 の保護を補完するネットワーク レベルの検査。
- DDoS 保護: パブリック IP アドレスのボリューム攻撃保護。
- Azureネットワークセキュリティとは?:Azure Firewall、DDoS保護、Web Application Firewallを比較する概要ハブです。
詳細情報
- Azure Web Application Firewall の概要
- Application Gateway 上の WAF
- Azure Front Door の WAF
- WAF ポリシーの概要
- Web アプリケーション ファイアウォールの CRS 規則グループと規則
- Azure Front Door の Web アプリケーション ファイアウォールの調整
次のステップ
Tip
あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。
リフトアンドシフト体験の次の手順:
移行されたネットワークの監視を設定する: Web アプリケーション ファイアウォールを構成した後、接続とパフォーマンスを検証します。
次に、最新化の取り組みを行います。
パブリック エンドポイントの DDoS 保護を有効にする: 分散型サービス拒否攻撃からパブリック IP リソースを保護します。
マルチクラウドへの移行における次のステップ:
移行したアプリケーションを提供する: AWS と Google Cloud のロード バランサーを、クロスクラウド ワークロードと同等のAzureにマップします。