先生と生徒の会話形式で理解しよう

生徒

「AzureでWebアプリを公開したのですが、正常なアクセスなのにWAFにブロックされてエラーが出てしまいます。これって故障ですか？」

先生

「それは故障ではなく、誤検知（ごけんち）という現象かもしれません。セキュリティーを厳しくしすぎると、安全な通信も攻撃だと勘違いされてしまうことがあるんです。」

生徒

「そうなんですね！どうすれば正しいアクセスだけを通せるようになりますか？」

先生

「除外（じょがい）リストの設定やチューニングという作業が必要です。初心者の方でも分かりやすく手順を解説しますね！」

1. Azure WAF（ウェブアプリケーションファイアウォール）とは？

Azure WAF（アジュール・ウェブ・アプリケーション・ファイアウォール）は、Microsoftが提供するクラウド型のセキュリティーサービスです。主に、SQLインジェクションやクロスサイトスクリプティング（XSS）といった、Webサイトを狙った悪意のある攻撃からアプリケーションを保護する役割を持っています。

通常のファイアウォールがネットワークの出入り口を見張るのに対し、WAFは「HTTP/HTTPS」というWebの通信内容を深く解析します。しかし、その解析が精密すぎるあまり、一般的なユーザーの入力内容を「攻撃のパターンに似ている」と判断して遮断（しゃだん）してしまうことがあります。これが誤検知（False Positive：フォールス・ポジティブ）です。

誤検知が発生すると、ユーザーはサイトを閲覧できなくなったり、フォームの送信に失敗したりするため、適切な設定変更（チューニング）が必要不可欠となります。

2. 誤検知（False Positive）が発生する仕組みと原因

なぜ誤検知は起こるのでしょうか。Azure WAFには「コアルールセット（CRS）」という、攻撃パターンの辞書のようなものが搭載されています。例えば、入力フォームに「SELECT」や「UNION」といったデータベース操作に関連する単語が含まれていると、WAFは「データベースを盗み見ようとする攻撃だ！」と判定します。

しかし、ブログの投稿内容や、システムの設定画面でこれらの単語を扱うことは珍しくありません。このように、業務上必要な通信が攻撃のシグネチャ（特徴）と一致してしまった場合に、アクセスが拒否されるのです。特に、リクエストヘッダーやCookie（クッキー）、POSTデータの解析中に多く発生します。

3. ログを確認して原因となるルールIDを特定する

誤検知を解消するための第一歩は、どのルールが通信をブロックしているのかを特定することです。Azureの「Log Analytics（ログ・アナリティクス）」を使用して、拒否されたログを調査します。ログには必ず「ruleId（ルールアイディー）」という番号が記載されており、これが原因の特定に役立ちます。

以下は、Log AnalyticsでWAFの遮断ログを検索するためのKusto（クスト）クエリの例です。これで、直近にブロックされた通信の詳細をリストアップできます。


AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked"
| project TimeGenerated, clientIp_s, requestUri_s, ruleId_s, Message
| order by TimeGenerated desc;

実行結果のイメージは以下のようになります。


TimeGenerated          | clientIp_s    | requestUri_s      | ruleId_s | Message
-----------------------+---------------+-------------------+----------+-------------------------
2026-03-30 10:00:00    | 192.168.1.1   | /api/update       | 942100   | SQL Injection Detected
2026-03-30 10:05:00    | 203.0.113.5   | /search?q=union   | 942110   | SQL Hex Character
2026-03-30 10:10:00    | 192.168.1.1   | /admin/login      | 932130   | Remote Command Execution

4. 除外リスト（Exclusion List）を設定する手順

原因となるルールIDやパラメータが判明したら、「除外（じょがい）リスト」を設定します。これは、「特定の場所にある特定の文字については、検査をスキップしてください」とWAFにお願いする設定です。

例えば、リクエストの「ArgsName（引数名）」に「comment」という名前が含まれる場合に、その中身を検査対象から外すといった設定が可能です。これにより、コメント欄に何を書いたとしても、その部分だけはWAFのチェックをスルーできるようになります。ただし、除外範囲を広げすぎるとセキュリティーホールになるため、最小限に留めるのがコツです。

5. 特定のルールを無効化（ディセーブル）する方法

除外リストだけでは対応できない場合、特定のルールそのものをオフにすることもできます。例えば、「ルール番号 942100」が頻繁に誤検知を起こし、かつそのルールが自分の環境では不要だと判断した場合は、ポリシーの設定画面から特定のルールを無効化します。

無効化する際は、必ずそのルールがどのような攻撃を防ぐものなのかを確認してください。Azureポータルの「管理ルール」セクションから、該当するルールセットを展開し、チェックボックスを外すだけで簡単に設定できます。設定変更後は「保存」を忘れないようにしましょう。

6. 運用開始前の検出モード（Detection Mode）の活用

新しいシステムを公開する際、いきなり通信を遮断する「防止（Prevention）モード」で動かすのは危険です。まずは「検出（Detection）モード」で運用することをおすすめします。

検出モードでは、攻撃と思われる通信を見つけても、ログに記録するだけで実際にはブロックしません。この間にログを収集し、誤検知が発生していないかを確認して、除外設定やルールの無効化を事前に行います。これを「チューニング期間」と呼びます。数日から数週間ほど様子を見て、問題がないことを確認してから防止モードへ切り替えるのが、プロのエンジニアの鉄則です。

7. PowerShellを使用したWAFポリシーの確認

GUIだけでなく、コマンドラインからもWAFの状態を確認できると便利です。特に大規模な環境では、スクリプトを使って一括で設定を確認することがあります。以下は、Azure PowerShell（アジュール・パワーシェル）を使って現在のWAFポリシー情報を取得するコマンドです。


Get-AzApplicationGatewayWebApplicationFirewallConfiguration -ApplicationGateway $AppGw
# 実行結果として、有効なルールやモード（Enabled/Detection）が表示されます。

また、特定のIPアドレスからの通信がブロックされているか、Linuxのcurl（カール）コマンドを使ってシミュレーションテストを行うこともあります。以下のコマンドは、あえて怪しい文字列を含めてリクエストを送り、WAFが反応するかを確認する例です。


curl -I "https://your-site.com/?id=1' OR '1'='1"
HTTP/1.1 403 Forbidden

上記のように「403 Forbidden（フォービドゥン）」が返ってくれば、WAFが正しく攻撃をブロックしていることがわかります。

8. 除外設定の対象となる変数の種類

除外設定を行う際に指定できる変数（検査対象の場所）には、いくつか種類があります。これらを正しく使い分けることで、精度の高いチューニングが可能になります。

変数名	意味・内容
Request Header Name	HTTPリクエストのヘッダー名（User-Agentなど）
Request Cookie Name	Cookie（クッキー）の名前
Query String Arg Name	URLの「?」以降に含まれるパラメータ名
Post Arg Name	POSTメソッドで送信されるフォームの項目名

これらの変数を正確に指定することで、システム全体の安全性を保ちつつ、誤検知だけをピンポイントで回避することができます。

9. チューニングのベストプラクティス

WAFの運用で最も大切なのは、一度設定して終わりではないということです。アプリケーションのアップデートによって新しい入力項目が増えると、再び誤検知が発生する可能性があります。定期的にLog Analyticsを確認し、不要なブロックが起きていないかチェックする習慣をつけましょう。

また、Microsoftは定期的にコアルールセット（CRS）の新しいバージョンを公開しています。最新の攻撃に対応するためには、新しいバージョンへのアップグレードも検討すべきですが、その際も「検出モード」による再チューニングを忘れないでください。安全で快適なWebサイト運営のために、WAFとの上手な付き合い方をマスターしましょう！

まとめ

今回の解説では、Azure WAF（ウェブアプリケーションファイアウォール）における誤検知の解消方法と、効率的なチューニングの手順について詳しく見てきました。Azure WAFは、SQLインジェクションやクロスサイトスクリプティングといった深刻な攻撃からウェブアプリケーションを守る強力な盾ですが、その防御力の高さゆえに、通常の業務通信を誤って遮断してしまう「誤検知（False Positive）」が発生することがあります。

運用の要点は、まず「Log Analytics」を活用して、どのルールID（ruleId）が原因でブロックが発生しているのかを正確に把握することです。ログを確認せずに勘で設定を変更すると、セキュリティホールを作ってしまうリスクがあるため、必ずデータに基づいた判断を行いましょう。原因が特定できたら、特定のパラメータを除外する「除外リスト（Exclusion List）」の設定や、どうしても環境に合わない「ルールの無効化」を検討します。

C#によるログ解析補助ツールの例

大量のログから特定のルールIDやIPアドレスを抽出して集計する場合、C#を使って簡単な解析コンソールアプリを作成すると便利です。例えば、CSV形式で書き出したログファイルを読み込み、ルールごとに集計するコードは以下のようになります。


using System;
using System.Collections.Generic;
using System.Linq;

namespace WafLogAnalyzer
{
    class Program
    {
        static void Main(string[] args)
        {
            // 擬似的なログデータ
            var logs = new List<WafLog>
            {
                new WafLog { RuleId = "942100", Message = "SQL Injection", ClientIp = "192.168.1.1" },
                new WafLog { RuleId = "942110", Message = "SQL Hex Character", ClientIp = "203.0.113.5" },
                new WafLog { RuleId = "942100", Message = "SQL Injection", ClientIp = "192.168.1.1" }
            };

            var summary = logs.GroupBy(l => l.RuleId)
                              .Select(g => new { RuleId = g.Key, Count = g.Count() });

            Console.WriteLine("【WAF検知ルール集計結果】");
            foreach (var item in summary)
            {
                Console.WriteLine($"ルールID: {item.RuleId} - 検知数: {item.Count}");
            }
        }
    }

    class WafLog
    {
        public string RuleId { get; set; }
        public string Message { get; set; }
        public string ClientIp { get; set; }
    }
}

上記のプログラムを実行すると、以下のような結果が得られます。


【WAF検知ルール集計結果】
ルールID: 942100 - 検知数: 2
ルールID: 942110 - 検知数: 1

SQLによる除外設定状況の管理

除外リストに登録した項目は、データベースで管理しておくと運用の引き継ぎがスムーズになります。現在の設定状況を管理するテーブル構成の例を見てみましょう。


id | rule_id | exclusion_target   | match_variable    | memo
---+---------+--------------------+-------------------+----------------------
1  | 942100  | comment            | PostArgNames      | ブログコメント欄の除外
2  | 932130  | session_id         | RequestCookieNames| セッションIDの誤検知対応
3  | 942110  | search_word        | QueryStringArgNames| 検索ワードの特殊文字許容
4  | 920230  | User-Agent         | RequestHeaderNames| 特定ブラウザのヘッダー対応

特定のルールIDに関連する除外設定を抽出するSQLクエリは以下の通りです。


SELECT exclusion_target, match_variable, memo
FROM waf_exclusion_settings
WHERE rule_id = '942100';

実行結果は以下のようになります。


exclusion_target | match_variable | memo
-----------------+----------------+----------------------
comment          | PostArgNames   | ブログコメント欄の除外

COBOLによるバッチ処理（レガシーシステム連携時）

もし古い基幹システムとAzure上のWebアプリが連携しており、ログデータの整形をCOBOLで行う必要がある場合は、以下のような構造が考えられます。


IDENTIFICATION DIVISION.
PROGRAM-ID. WAF-LOG-SUMMARY.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 WAF-RECORD.
   05 WAF-RULE-ID   PIC X(6).
   05 WAF-ACTION    PIC X(10).
01 COUNTER-942100   PIC 9(4) VALUE 0.

PROCEDURE DIVISION.
    MOVE "942100" TO WAF-RULE-ID.
    MOVE "Blocked" TO WAF-ACTION.
    
    IF WAF-RULE-ID = "942100" AND WAF-ACTION = "Blocked"
        ADD 1 TO COUNTER-942100
    END-IF.
    
    DISPLAY "RULE 942100 BLOCKED COUNT: " COUNTER-942100.
    STOP RUN.

最後になりますが、WAFの運用で最も重要なのは「検出モード」と「防止モード」の使い分けです。本番環境に反映する前に、必ず検出モードで数日間運用し、必要な通信が止まっていないかを確認する「チューニング期間」を設けてください。これにより、セキュリティの向上とユーザーの利便性を高いレベルで両立させることができます。Azure WAFを正しく設定し、安全で信頼性の高いウェブサービスの提供を目指しましょう。

先生と生徒の振り返り会話

生徒

「先生、ありがとうございました！WAFが通信をブロックするのは故障じゃなくて、一生懸命守ってくれている証拠だったんですね。でも、誤検知をそのままにしておくとユーザーが困ってしまうということもよく分かりました。」

先生

「その通りです。セキュリティは強ければ強いほど良いと思われがちですが、実際には『業務に必要な通信を邪魔しない』というバランスがとても大切なんです。Log Analyticsの使い方は覚えられましたか？」

生徒

「はい！Kustoクエリを使ってruleIdを特定して、どの部分が引っかかっているのかを調べるんですよね。SQLのSELECT文に似ているので、イメージしやすかったです。あと、いきなり防止モードにするのではなく、まずは検出モードで様子を見るというのも驚きでした。」

先生

「それは『プロのエンジニアの知恵』ですね。急がば回れです。除外リストを設定するときも、何でもかんでも除外するのではなく、特定のパラメータだけに絞ることで、安全性を保ちながら誤検知を回避できるんですよ。」

生徒

「なるほど。Request Header NameやQuery String Arg Nameなど、場所を特定して除外するのがコツなんですね。C#やSQLでの管理方法も教えてもらったので、運用のイメージが湧きました！」

先生