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

生徒

「AzureでWebサイトを公開したのですが、サイバー攻撃が怖いです。Azure WAF（アジュール・ウェブ・アプリケーション・ファイアウォール）を導入すれば安心ですか？」

先生

「WAF（ワフ）は非常に強力な味方ですよ。でも、設定を間違えると、普通のユーザーのアクセスまでブロックしてしまうことがあるんです。だから、検出（けんしゅつ）モードと防止（ぼうし）モードの使い分けが重要になります。」

生徒

「いきなりブロックしてサイトが見られなくなったら大変ですね。安全に切り替えるステップを教えてください！」

先生

「もちろんです。今回は初心者の方でも失敗しない、WAFの運用と移行の流れをじっくり解説しますね！」

1. Azure WAF（アジュール・ワフ）とは？

Azure WAFとは、WebアプリケーションをSQLインジェクションやクロスサイトスクリプティング（XSS）といった一般的な脆弱（ぜいじゃく）性から保護するためのセキュリティサービスです。通常のファイアウォールがネットワーク全体の出入り口を見張るのに対し、WAFはWebサイトへの通信内容を深く検査するのが特徴です。

例えば、悪意のある攻撃者が入力フォームに変なプログラムを書き込もうとしたとき、WAFがその内容をチェックして「これは攻撃だ！」と判断して守ってくれます。Azureでは、Application Gateway（アプリケーション・ゲートウェイ）やFront Door（フロント・ドア）というサービスと一緒に組み合わせて利用するのが一般的です。

2. 検出モードと防止モードの違いを徹底解説

Azure WAFには、大きく分けて2つの動作モードがあります。この違いを理解することが、安全な運用の第一歩です。

モード名	動作の内容	メリット
検出モード（Detection）	攻撃を検知するが、遮断はせずにログに記録する	正常な通信を止めるリスクがない
防止モード（Prevention）	攻撃を検知し、その通信を即座に遮断する	リアルタイムで攻撃から守れる

検出モードは、いわば「監視カメラ」の状態です。不審な人が来ても記録するだけで、中には通します。一方で防止モードは「警備員」がいる状態で、不審な人をその場で追い返します。本番環境では最終的に防止モードを目指しますが、いきなり設定すると、必要な通信まで止めてしまう「誤検知（ごけんち）」が発生するリスクがあります。

3. 本番環境で失敗しない！安全な移行の4ステップ

本番環境で稼働中のシステムにWAFを導入する場合、以下の手順を踏むのがセオリーです。これを守ることで、サイトが突然閲覧不能になるトラブルを防げます。

ステップ1：検出モードで開始する
まずは検出モードで数日から1週間ほど運用します。これにより、どのような通信がWAFのルールに引っかかるかを確認します。

ステップ2：ログの分析と除外設定
記録されたログを見て、正常なアクセスなのにブロック対象（誤検知）になっていないか調べます。もし誤検知があれば、特定のルールを無効にしたり、除外リストに追加したりします。

ステップ3：防止モードへの切り替え
ログがきれいになり、攻撃だけが検知される状態になったら、いよいよ防止モードに切り替えます。

ステップ4：継続的なモニタリング
切り替え後も定期的にログをチェックし、新しい攻撃手法やアプリのアップデートによる影響がないか確認します。

4. ログを確認するための準備（Log Analytics）

WAFが何を検知したかを知るには、ログを保存する場所が必要です。Azureでは「Log Analytics（ログ・アナリティクス）ワークスペース」という場所を使います。ここでは、Kusto（クスト）クエリという言語を使ってログを抽出します。

初心者の方向けに、どのような攻撃（あるいは誤検知）があったかを確認する簡単なクエリを紹介します。


// WAFのログからブロック（または検出）された履歴を取得する
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Matched" or action_s == "Blocked"
| project TimeGenerated, clientIp_s, requestUri_s, ruleName_s, action_s
| order by TimeGenerated desc

このクエリを実行すると、いつ、どのIPアドレスから、どのページに対して、どのルールが反応したかが一覧で表示されます。`action_s`が`Matched`なら検出モードでの検知、`Blocked`なら防止モードでの遮断を意味します。

5. 特定のルールを除外する方法（カスタマイズ）

例えば、WordPressなどの管理画面で記事を保存しようとすると、WAFが「スクリプトの注入攻撃だ！」と勘違いして保存を邪魔することがあります。これを防ぐには、ルールのIDを指定して無効化します。

Azureポータルの「Web Application Firewall ポリシー」から、マネージド・ルールセットの設定を開き、該当するIDのチェックを外すだけです。ただし、ルールを消しすぎるとセキュリティが弱くなるので、どうしても必要な場合だけに絞りましょう。

以下は、WAFの設定情報をプログラム（Azure CLI）で確認する際のコマンド例です。


az network waf-policy show --name MyWafPolicy --resource-group MyResourceGroup
{
  "location": "japaneast",
  "policySettings": {
    "mode": "Detection",
    "state": "Enabled"
  },
  "status": "Succeeded"
}

6. 除外リストをデータベース的に管理する考え方

大規模な運用では、どのIPアドレスをホワイトリスト（許可リスト）に入れるか、どのURLを検査対象から外すかを整理しておく必要があります。イメージとしては、以下のようなテーブル形式で管理・検討することになります。


id | target_url        | rule_id | reason              | status
---+-------------------+---------+---------------------+-------
1  | /admin/config.php | 942100  | 内部システム通信用   | Excluded
2  | /api/v1/upload    | 941100  | 画像アップロード許可 | Active
3  | /login.html       | 942110  | 誤検知のため除外     | Excluded
4  | /contact.php      | 931100  | 通常の問い合わせ     | Active

このように整理しておくことで、チーム内で「なぜこのルールを止めたのか」が明確になります。むやみに全てのルールを外すと、せっかくのWAFが無意味になってしまいますからね。

7. 防止モードに切り替える際のチェックリスト

防止モードに切り替える直前に、以下の項目を最終確認しましょう。これを怠ると、夜中にアラートで起こされることになりかねません。

過去24時間のログに、一般ユーザーと思われる正常な通信のブロック（Matched）が含まれていないか。
社内拠点や開発メンバーの固定IPアドレスが、誤って遮断対象になっていないか。
ファイルアップロード機能など、大きなデータを送るページでサイズ制限に引っかかっていないか。
WAFの適用範囲（スコープ）が、正しいリスナーやURLパスに紐付いているか。

8. C#を使ったカスタムエラーページの表示

WAFが通信をブロックすると、ユーザーには「403 Forbidden（アクセス拒否）」という愛想のないエラー画面が表示されます。これだとユーザーが驚いてしまうため、C#（ASP.NET Core）などで作成したWebアプリ側で、丁寧な案内を表示するように工夫することもあります。

以下は、エラーが発生した際にカスタムページへ誘導するプログラムのイメージです。


// Startup.cs や Program.cs での設定イメージ
var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    // 例外やエラーが発生した際に特定のパスへリダイレクトする
    app.UseStatusCodePagesWithReExecute("/Error/{0}");
    app.UseExceptionHandler("/Error/General");
}

app.MapGet("/Error/403", () => "申し訳ありません。セキュリティチェックによりアクセスが制限されました。時間を置いて再度お試しください。");

このようにしておけば、万が一WAFが誤作動してユーザーを止めてしまっても、「システムが壊れた！」と思われるのを防ぎ、サポートへの誘導もスムーズになります。

9. 継続的な運用とアップデートの重要性

WAFを一度設定して「はい、終わり」にするのは危険です。サイバー攻撃の手口は日々進化しており、Azure WAFもそれに対抗するために「OWASP（オワスプ）コアルールセット」というルール集を定期的に更新しています。

新しいルールセットが公開されたときは、再度「検出モード」でテストを行い、新しいルールによって正常な通信が止まらないかを確認してから適用するのが、プロのエンジニアの仕事です。常に「安全第一」で、少しずつステップアップしていきましょう！

まとめ

Azure WAF（Web Application Firewall）の導入と運用において、最も重要なのは「段階的な移行」と「継続的なログ監視」です。初期設定でいきなり「防止モード」を選択するのではなく、まずは「検出モード」で数日間から数週間のトラフィックを静観し、正常なユーザーの通信が誤って攻撃と判定されていないか（誤検知）を精査することが不可欠です。Log Analyticsを用いたクエリ分析や、特定のルールIDを柔軟に除外するカスタマイズ設定を組み合わせることで、強固なセキュリティと利便性の高いWebサービスを両立させることができます。

また、WAFは一度設定すれば完了というものではありません。サイバー攻撃の手口は日々進化しており、Azureが提供するマネージドルールセットも定期的に更新されます。新しいルールが適用される際も、同様に検出モードでの検証ステップを踏むことが推奨されます。C#によるカスタムエラーページの構築や、除外リストのデータベース管理など、多角的なアプローチで運用体制を整えることが、安定したシステム稼働への近道となります。

Azure WAF運用で活用するSQLと実行結果の例

WAFの運用では、除外設定を検討するために、現在の設定状況や検知履歴をデータベース形式で管理することが推奨されます。以下に、除外リストを管理するテーブルの状態と、特定のルールを抽出するSQLの例を示します。


id | rule_id | target_path          | action_type | description
---+---------+----------------------+-------------+-----------------------
1  | 942100  | /api/v1/products     | Allow       | SQLインジェクション誤検知対応
2  | 931100  | /contact/send        | Block       | 不審なOSコマンド注入を遮断
3  | 941100  | /user/profile/upload | Allow       | 画像バイナリデータの誤検知
4  | 920300  | /login               | Block       | 不正なリクエストヘッダー
5  | 942110  | /admin/dashboard     | Allow       | 管理画面の特定スクリプト許可

上記のテーブルから、現在「許可（Allow）」として除外設定を行っているルールのみを抽出して確認するSQLを実行します。


SELECT rule_id, target_path, description
FROM waf_exclusion_settings
WHERE action_type = 'Allow'
ORDER BY rule_id ASC;

実行結果は以下の通りです。


rule_id | target_path          | description
--------+----------------------+-----------------------
941100  | /user/profile/upload | 画像バイナリデータの誤検知
942100  | /api/v1/products     | SQLインジェクション誤検知対応
942110  | /admin/dashboard     | 管理画面の特定スクリプト許可

C#によるWAF検知ログのシミュレーション

アプリケーション側でWAFの動作ログを擬似的に解析し、特定のルールID（例：SQLインジェクション検知の942100）が含まれている場合に警告を出すプログラムの例です。


using System;
using System.Collections.Generic;

namespace WafLogAnalysis
{
    class Program
    {
        static void Main(string[] args)
        {
            List<string> detectedRules = new List<string> { "942100", "941100", "920300" };
            
            Console.WriteLine("WAF検知ルールのスキャンを開始します...");

            foreach (var ruleId in detectedRules)
            {
                if (ruleId == "942100")
                {
                    Console.WriteLine($"警告: ルールID {ruleId} (SQL Injection) が検出されました。設定を確認してください。");
                }
                else
                {
                    Console.WriteLine($"情報: ルールID {ruleId} をスキャンしました。");
                }
            }
        }
    }
}

実行結果は以下の通りです。


WAF検知ルールのスキャンを開始します...
警告: ルールID 942100 (SQL Injection) が検出されました。設定を確認してください。
情報: ルールID 941100 をスキャンしました。
情報: ルールID 920300 をスキャンしました。

LinuxコマンドによるWAF設定確認の自動化

Azure CLIを使用して、現在のWAFポリシーが「検出モード（Detection）」か「防止モード（Prevention）」かを素早く確認するシェルスクリプトの実行例です。


# WAFポリシーの動作モードのみを抽出して表示
az network waf-policy show --name MyWafPolicy --resource-group MyResourceGroup --query "policySettings.mode" -o tsv
Detection

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

生徒

「先生、Azure WAFの導入手順について詳しく教えていただきありがとうございました！まずは検出モードで様子を見るのが、システムを止めないための鉄則なんですね。」

先生

「その通りです。どんなに優れたセキュリティツールでも、正常なビジネスの邪魔をしてしまっては本末転倒ですからね。Log Analyticsを使って、実際のログを読み解く練習はできそうですか？」

生徒

「はい！教えていただいたKustoクエリを使えば、どのIPアドレスから、どのページに対して攻撃と判定されたかが一目瞭然ですね。SQLのようにデータを抽出できるので、馴染みやすかったです。」

先生

「それは素晴らしい。特にC#のコードでも紹介したように、アプリケーション側で403エラーを適切にハンドリングして、ユーザーに不安を与えない工夫も忘れないでくださいね。もし誤検知があったらどう対処しますか？」

生徒

「その時は、特定のルールIDを除外リストに登録してカスタマイズします。でも、何でもかんでも除外するとセキュリティが弱くなってしまうので、除外リストの管理テーブルを作って、理由を明確にしておくことが大切だと学びました。」

先生