mcpField
A
azure-waf

azure-waf

github.com/vinayaklattheセキュリティ17842 回インストール19 週間前に更新
リポジトリ

azure-waf について

azure-wafは、Azure Web Application Firewallの導入と運用を計画するスキルです。セキュリティチームやアプリチーム向けに、ホストの選定、ポリシー調整、WebアプリとAPIの保護を支援します。

主な機能

  1. 01Front DoorとApplication Gatewayの選定
  2. 02検出モードから防止モードへの移行
  3. 03URIやパラメーター単位の除外調整
  4. 04カスタムルールとレート制限の作成
  5. 05ログ分析と運用責任の計画

活用シーン

  1. 01新規公開アプリに適したWAFホストの選定
  2. 02ポリシーを段階的に防止モードへ移行
  3. 03誤検知の調査と除外レビュー手順の策定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill azure-waf

インストール後、Claude Code で/azure-wafを入力して読み込まれたか確認します。

詳細

Azure Web Application Firewall（WAF）

Azure WAF は OWASP に準拠したアプリケーションレイヤーのファイアウォールで、次の 2 つのホストサービスで利用できます。

  • Azure Front Door（Premium / Standard） — グローバルなエニーキャスト方式のエッジ層です。エッジ拠点と組み込みのキャッシュを活用できる、インターネット公開アプリや API に最適です。
  • Azure Application Gateway（WAF v2） — バックエンドプールと統合されたリージョナルサービスです。すでに App Gateway で終端している、アプリ内部向けまたは VNet に接続されたワークロードに最適です。

使用する場面

SQLi、XSS、RCE パターン、自動スキャナー、クレデンシャルスタッフィング、スクレイピング、ボットの悪用など、レイヤー 7 の攻撃から公開 Web アプリケーションと API を保護する場合に使用します。ホストの選定、ポリシーの作成、除外設定の調整、運用上の責任者の決定にこのスキルを使用してください。

このスキルは使用しないでください。レイヤー 3/4 の DDoS（azure-ddos-protection）、東西方向の通信／非 HTTP トラフィック（azure-firewall）、または非 HTTP プロトコルには使用しないでください。

ホストを選ぶ

ホスト最適な用途
Front Door Premium WAFグローバルなエッジ、アドバンスドボットマネージャー、JS/JSON チャレンジ、プライベートリンクのバックエンドを必要とするインターネット向けアプリ／API
Front Door Standard WAFマネージドルールセットの Default Rule Set とカスタムルールを使用する、コスト重視のインターネット向けアプリ
App Gateway WAF v2すでに App Gateway を使用しているリージョナルアプリ、VNet 内部向けアプリ、独自証明書の使用やゾーン要件がある場合

経験則： 新規構築のインターネット公開アプリには Front Door Premium を選択します。既存の App Gateway を使用していて、継続利用すべき明確な理由がある場合は App Gateway WAF を選択します。

アプローチ

  1. まず Detection（監査）モードで開始します。 例外なく必ず開始してください。Prevention に切り替える前に、最低 2 週間分の本番トラフィックを確認します（季節性のあるアプリではさらに長い期間が必要です）。

  2. Microsoft の Default Rule Set（DRS）を適用します。 新規デプロイでは、旧来の OWASP CRS よりも現行世代のルールセットを推奨します。Front Door Premium では Bot Manager ルールセットを有効にします。

  3. まず認証を考慮したルールを適用します。

    • 匿名エンドポイント（ログイン、検索、サインアップ）にレート制限を適用します。ログインの場合、一般的な設定は IP ごとに 100 回／分です。
    • サービス対象外の国を地域ブロックします。ただし、VPN コンセントレーターやパートナーのリージョンは許可リストに追加します。
    • 不審なボットスコアに対してJSON／JS チャレンジ（Premium）を適用します。ヘッドレスブラウザーを目立たない形でフィルタリングできます。

  4. 除外を段階的に調整します。 これは運用の中核となる作業であり、ほとんどの WAF が「いつまでも Detection のまま」になる理由でもあります。次の手順で進めます。

    1. Detection モードの検知結果を AzureDiagnostics／AGCWAFLogs から取得します。
    2. ルール ID、URI、パラメーターごとにグループ化します。
    3. 正当なトラフィックであることを確認します（例：< 文字を含む正当な SOAP 本文、SQL キーワードを正当に含む API）。
    4. 該当する URI／パラメーターに対して、そのルールに限定した除外を追加します。ルール全体をグローバルに無効化してはいけません。
    5. 毎週、ベースラインを再設定します。

  5. すべてのルールを一度にではなく、ルールごとに Prevention に移行します。誤検知が少なく確度の高いルール（RCE パターン、コマンドインジェクション）から開始します。誤検知が多いルール（XSS、プロトコル違反）は、除外が安定するまで保留します。

  6. ビジネスロジックにはカスタムルールを使用します。 例：

    • ペネトレーションテストの実施期間中に特定のユーザーエージェントをブロックします。
    • パートナーの CIDR に対し、レート制限を回避できるようにします。
    • 内部 API に特定のヘッダーを必須とします。
    • 管理者用パスでは、想定される国以外をすべて地域ブロックします。

  7. ログ記録と分析を行います。 WAF ログを Log Analytics（および Sentinel）に送信します。次の項目を作成します。

    • ブロックされたルールの上位項目と、誤検知の可能性が高い項目（対応キュー）。
    • ブロックされたトラフィックの地理的な分布。
    • エンドポイントごとのレート制限の検知数。
    • ボットマネージャーによる分類の傾向。

  8. 運用上の責任者を明確にします。 アプリチームの責任者が決まっていない WAF は、次第に管理が行き届かなくなります。毎月、次の作業を行います。

    • Microsoft からの新しいルールセットの更新を確認します（デフォルトで自動適用されるため、ログの差分を確認します）。
    • リクエストの形式が変わるアプリのデプロイ後に、除外のベースラインを再設定します。
    • Prevention の適用範囲を検証します（気付かないまま無効化されているルールがないことを確認します）。

  9. フロントドアのパブリック IP／App Gateway のパブリック IP に対して、DDoS Protection と併用します。WAF は L7、DDoS は L3/4 を保護します。価値の高い公開ワークロードには、常に両方を適用してください。

ガードレール

  • 初日から Prevention モードでデプロイしないでください。 営業時間中に誤検知による停止が発生します。
  • 単一の誤検知に対処するためにルールをグローバルに無効化しないでください。 実際にトリガーされた URI ／パラメーター／Cookie ／ヘッダーに限定した除外を使用してください。
  • 地域ブロックは大まかなツールです。 旅行者、VPN ユーザー、モバイルキャリアの IP は場所が変わります。エンドユーザー向けのパスでは、厳格な地域ブロックよりも、レート制限＋ボットマネージャー＋認証状態の組み合わせを優先してください。
  • ボットマネージャーのスコアは二者択一ではありません。 スコア帯モデル（低 → JS チャレンジ、中 → CAPTCHA、高 → ブロック）を使用してください。中間のスコア帯を厳しくブロックすると、実際のユーザーにも影響します。
  • 共有 NAT の背後にある IP ごとのレート制限（キャリア、企業ネットワーク）では、実際のユーザーにも広く影響します。Cookie ／セッションと組み合わせ、適切な制限値を設定してください。
  • API の前段に WAF を配置しても、API の認証／認可の代わりにはなりません。 多層防御の一環であり、主要な制御ではありません。
  • 複数の WAF を直列に配置すると（サードパーティ CDN WAF ＋ Azure WAF）、すべての設定を二重に調整することになり、エンジニアの負担になります。 どちらか一方を権威あるものとして選んでください。
  • Default Rule Set の更新で新しいルールが追加されることがあります。 ルールの更新によって本番環境が予期せずブロックされないよう、四半期ごとに変更内容を確認してください。

よくあるアンチパターン

  • 「初日から Prevention モード」 — 停止が発生し、チームが WAF 全体を無効化して、そのまま再び有効にしません。結果、何も残りません。
  • 「1 つの URI で誤検知が起きたので、ルール 942100 を無効化」 — ルールクラス全体が無効になります。除外を使用してください。
  • 「レート制限 ＝ 全体で 1000/分」 — ログインエンドポイントでは役に立たず、静的アセットのエンドポイントでは過剰です。エンドポイントごとに調整してください。
  • 「あらゆる場所で地域ブロック」 — 顧客を締め出す一方、意欲的な攻撃者を阻止できません。
  • 「ボットマネージャーで『中』のスコアをすべてブロック」 — 正規のブラウザーのバリエーションやパートナーとの連携をブロックします。
  • 「WAF ログが Sentinel にない」 — 状況を把握できません。
  • 「30 個すべてのアプリで同じ WAF ポリシー」 — 除外の設定が不可能になります。アプリごと、またはアプリファミリーごとにポリシーを設定してください。
  • 「Default Rule Set の更新をスキップ」 — 攻撃が進化する一方で、保護範囲が停滞します。

プロンプトの例

  • サードパーティ WAF から Azure Front Door Premium WAF へ、一般公開されている EC アプリを移行するための設計と切り替え計画を作成してください。
  • 除外調整のワークフローを構築してください。ログクエリ、週次レビュー、アプリチームの承認を含めます。
  • カスタムルールを作成してください。/login は IP ごとに 30/分でレート制限し、ボットスコアが中のときは /api/search に JS チャレンジを適用し、/admin は US/CA 以外をすべて地域ブロックします。
  • Detection モードの WAF ポリシーを、ロールバックのトリガーを設定したうえで、ルールごとに Prevention へ移行してください。
  • Sentinel ワークブックを作成してください。ブロック数の多いルール、誤検知の可能性が高い候補、地域別の分布、ボットマネージャーの傾向を表示します。
  • 地域銀行アプリ向けに、Front Door WAF と App Gateway WAF を比較してください。
  • Foundry でホストされる AI API 向けに、WAF ＋ DDoS ＋ Private Link バックエンドを設計してください。

Microsoft Learn

コメント

Markdown 対応