- 効果的なWAFは、ブロックリストモデル、許可リスト、および頻度ベースのルールを組み合わせて、ログ記録、カウント、またはブロックを行うタイミングを決定します。
- ホワイトリスト、例外処理、シミュレーションモードなどを活用して誤検知を微調整することが、正当なトラフィックへの影響を回避する鍵となります。
- アプリケーションやサービスごとにポリシーをセグメント化し、SIEMや自動化と統合することで、セキュリティと運用性の現実的なバランスを実現できます。
- WAAPプラットフォームへの進化は、APIへの保護を拡大し、記録のコンテキストを改善し、より正確なブロック決定を容易にします。
WAFにおけるログ記録とブロックの適切なバランスを見つけることは、セキュリティチームと運用チームにとって最もよくある悩みの種の一つとなっています。Webアプリケーションファイアウォールは非常に深刻な攻撃を阻止できますが、設定が厳しすぎると、正当な購入、アクセス、またはAPI呼び出しをブロックしてしまう可能性があります。逆に設定が緩すぎると、ほとんど飾り物になってしまいます。重要なのは、ログ記録、カウント、許可、ブロックのタイミングを慎重に調整することです。
この記事では、 AWS WAF、ModSecurity、クラウドベースのWAF、オンプレミスソリューションの具体的な例を交えながら、最新のWAF機能（許可リスト、頻度ベースのルール、学習モード、SIEM統合、機械学習など）を活用して、このバランスを実現する方法を詳しく解説します。保護レベルを下げずに誤検知を制限する方法、アプリケーションごとにポリシーを整理する方法、ログを常に管理不能なノイズ源としてではなく、味方として活用する方法などをご紹介します。
WAFとは何ですか？また、登録がなぜそれほど重要なのでしょうか？
ウェブアプリケーションファイアウォール（WAF）は、ユーザーとサーバー間のインテリジェントなレイヤーとして機能し、HTTP/HTTPSトラフィックをリアルタイムで分析します。ポートやIPアドレスを監視する従来のネットワークファイアウォールとは異なり、WAFはURL、パラメータ、リクエストボディ、ヘッダー、Cookie、HTTPメソッドなど、より詳細な情報を監視します。
その使命は、 SQLインジェクション、XSS、LFI/RFI、アクセス制御への攻撃、APIの悪用、積極的なスクレイピング、ブルートフォース攻撃、さらには特定のアプリケーションレベルのDDoS攻撃パターンといった、典型的なレイヤー7攻撃を検知し阻止することです。そのためには、常に更新される一連のルール、シグネチャ、およびセキュリティポリシーに依存しています。
ログ記録は、その裏返しです。WAF のあらゆる決定（許可、ブロック、カウントのみ）には、ログに詳細なイベントが記録されます。これらのログによって、以下のことが可能になります。
- 事件を調査する何が起こったのか、そしてどのように脆弱性を悪用しようとしたのかを再構築する。
- ルールを調整する: WAFがブロックしている正当なリクエストを確認することで、誤検知を検出します。
- 規制を遵守する: 有効な管理策が存在することを証明する（PCI DSS、GDPR、内部監査など）。
- SIEMへの給餌アプリケーション攻撃とネットワーク、システム、IDなどのイベントを関連付ける。
問題は、WAFの調整が不十分だと、ログに何千もの無関係なイベントが記録されてしまい、重要な情報を見つけることが不可能になるだけでなく、正当なトラフィックが不当に拒否されてしまうことです。そこで、ログ記録、カウント、ブロックモードを巧みに調整する技術が重要になってきます。
WAFにおけるセキュリティモデル：ブロックリスト、許可リスト、およびハイブリッドアプローチ
最新のWAFのほとんどは、複数のフィルタリング手法を組み合わせており、それがリクエストのログ記録とブロック方法に直接影響を与えます。大まかに言えば、2つの古典的な考え方と、非常に一般的なハイブリッドモデルが挙げられます。
ブロックリストベースのWAFは、ネガティブセキュリティモデルを採用しています。その基本原則は、「悪意のあるものと分かっているもの以外はすべて許可する」というものです。既知の攻撃（SQLインジェクション、XSS、ボットパターンなど）のシグネチャと、疑わしいとみなされるものを定義するルールを用いて機能します。初期導入は容易ですが、このモデルだけに頼ると、新たな攻撃ベクトルや亜種が検出されずにすり抜けてしまうリスクがあります。
許可リストを備えたWAFは、これとは逆の仕組みで動作します。「明示的に許可されたもの以外はすべてブロックする」というものです。これはポジティブセキュリティモデルに基づいています。定義された正当な動作（経路、方法、パラメータ、フォーマット、サイズなど）に合致するトラフィックのみが受け入れられます。セキュリティははるかに高いものの、綿密な調整が必要であり、適切な準備を怠ると初期段階で誤検知が発生する可能性があります。
各アプローチにはそれぞれ長所と短所があるため、許可リストとブロックリストを組み合わせたハイブリッドモデルがますます一般的になっています。このシナリオでは、想定されるトラフィックプロファイル（例えば、通常のログインや支払いリクエストを構成するもの）が定義され、シグネチャとヒューリスティックが同時に適用されて、典型的な悪意のあるパターンが検出されます。ログ記録の目的で、このハイブリッドアプローチでは次のことが可能になります。
- としてマークする 高リスクイベント 許可品目リストに違反するもの。
- として扱う 中低優先度アラート 一般的なブロックリストのパターン。
- ブロックを有効にする前に、「カウント」モードを使用して、何がルール違反になるかを確認してください。
ネットワーク、ホスト上、クラウドにおけるWAF：ログ記録とロックへの影響
WAFの導入モデルは、トラフィックのログ記録とブロックの処理方法に大きな影響を与えます。ネットワークデバイス上でリクエストをログに記録することと、サーバー内のエージェントやマネージドクラウドサービス上でログに記録することは異なります。
ネットワークベースのWAFは通常、インフラストラクチャ内のインターネットとアプリケーションの間に、物理アプライアンスまたは仮想アプライアンスとして導入されます。これはF5などのメーカーが採用している従来のアプローチです。高性能と細かな制御という利点がありますが、構成と管理は複雑になる場合があります。ログは通常syslogまたは中央SIEMに送信され、ストレージや分析ツールの過負荷を防ぎ、 IPネットワークやDNSネットワークの問題を診断するために、保存するログを慎重にフィルタリングすることが重要です。
ホストベースのWAFは、アプリケーションが稼働するサーバー（またはコンテナ）上で、モジュールまたはエージェントとして動作します（例えば、ModSecurityはNginxやApacheに統合されており、SELinuxを使用したLinuxのセキュリティ強化と組み合わせることでセキュリティ体制が向上します）。このモデルでは、より詳細なアプリケーションコンテキストとサービスごとの非常に具体的なルール設定が可能になりますが、ローカルリソースの消費と、より分散型のログ管理が必要となるというデメリットがあります。ログはローカルファイルに保存してから転送することも、集中ログサービスと統合することも可能です。
クラウドベースのWAF （Cloudflare、Akamai、Imperva Cloud、AWS WAFなど）は、ロードバランサー、CDN、仮想ネットワークと統合されます。プロバイダーは通常、ダッシュボードを提供し、ログをS3、BigQuery、リモートsyslog、またはSIEMにエクスポートします。一般的にセットアップは簡単ですが、イベントの種類、保持期間、重要度フィルタなど、プロバイダーのモデルに合わせてログポリシーを調整する必要があります。
どちらのモデルを選択するかは、技術的な決定だけでなく、ログ記録とロックのバランスをどのように取るかという問題でもあります。クラウド管理サービスは多くの側面を簡素化しますが、コンプライアンスや機密保持ポリシーのためにログの保存場所を完全に制御したい場合、オンプレミスまたはハイブリッドモデルを選択することになるでしょう。
利用規約、ルール、Web ACL：WAFがブロック、許可、または登録のみを決定する方法
メーカーに関わらず、最新のWAFはすべてアクセス条件、ルール、ポリシーという概念に基づいています。これを理解することが、本番環境でカウント、ログ記録、ロックモードを効果的に使用するための鍵となります。
条件では、リクエストのどの部分を検査するかを定義します。例えば、送信元IPアドレス、特定のHTTPヘッダー（Host、User-Agent、Accept、Content-Typeなど）、クエリパラメータ、リクエストボディ、Cookie、HTTPメソッド、送信元国などです。例えば、AWS WAF Classicでは、最大10.000個のアドレスまたは範囲を指定してIP条件を定義したり、URLの一部に対して文字列一致条件を定義したりすることができます。
ルールは、1つ以上の条件を組み合わせて、許可、ブロック、カウントといった意図を割り当てます。ルールに複数の条件がある場合、それらは通常、論理ANDで評価されます。つまり、ルールが実行されるには、すべての条件を満たす必要があります。条件のない通常のルールは、実際には何も一致しないため、そのアクションは実行されません。
AWS WAFを含む多くのWAFには、レートベースのルールも備わっています。これらのルールは、例えば5分間といった時間枠内で、特定のIPアドレス（または特定の条件を満たすIPアドレスのセット）から到着したリクエスト数をカウントします。しきい値（例えば5分間に1.000件のリクエスト）を超えると、ルールが有効になり、ブロックまたは単にカウントが行われます。これは次のような場合に非常に役立ちます。
- コントロールする ログインフォームへの総当たり攻撃.
- 攻撃的なスクレイピングや無礼なボットを制限してください。
- アプリケーションレベルで特定の種類のDDoS攻撃を軽減する。
次のレベルはWeb ACL（アクセス制御リスト）です。ここでは、ルールがグループ化され、評価順序とデフォルトアクション（許可またはブロック）が定義されます。リクエストは順番にルールを通過し、いずれかのルールに一致すると、そのルールのアクションが適用され、残りのルールの評価は停止されます。どのルールにも一致しない場合は、ACLで定義されたデフォルトアクションが適用されます。
ログ記録とブロックのバランスに関して言えば、ACLは、システムをデフォルトで寛容に（許可し、特定のルールでのみブロックする）するか、非常に制限的に（例外的な場合を除いてブロックする）するかを決定する場所です。さらに、多くのソリューションでは、ACL内でルールを「カウント」モードで設定できるため、一致するトラフィックをログに記録しますが、ブロックは行いません。これはチューニング段階に最適です。
ログにおけるホワイトリストとノイズ低減
許可リストは、誤検知やログのノイズを削減するための基本的なツールです。その考え方はシンプルです。特定の状況において、WAFに対し、既に信頼できると分類したトラフィック、あるいは通常とは異なるものの正当なトラフィックに対して、特定の指示やルールセットを適用しないように指示します。
例えば、AWS WAFでは、特定のIPアドレスまたは範囲からのリクエスト、あるいは既知のURLパターンとHTTPメソッドに一致するリクエストに対して、特定の署名検査を適用しないようにする許可リストルールを作成できます。これは、次のような場合に役立ちます。
- 「奇妙な」パターンを使用する内部APIを防止する 常に偽陽性を生成する.
- 既に信頼できると判断しているトラフィックにおいて、詳細な検査によって発生する遅延を削減します。
- WAFログ内の不要なレコードの量を削減する。
ModSecurityのようなプラットフォームでは、標準ルール（OWASP Core Rule Setなど）を変更するのではなく、ルールIDごとに特定のパラメータ、パス、またはユーザーを除外する設定を作成することが推奨されます。これにより、サイト全体のルールを無効にすることで大きな脆弱性を生み出すことなく、全体的な保護を維持できます。
重要なのは、包括的なアプローチではなく、許可リストを的確に設定することです。ルールXを全体的に無効にするよりも、特定の組み合わせ（URL Z内のルールXとパラメータY）を除外する方がはるかに効果的です。そうすることで、ログ記録は引き続き有用であり、不要な盲点が生じるのを防ぐことができます。
プロトコルのルールと制限：ブロックすべき時、警告すべき時
多くのWAF（Webアプリケーションファイアウォール）には、不正なトラフィックや疑わしいトラフィックを最初にフィルタリングするHTTPプロトコルサニタイズルールが組み込まれています。これらのルールは、必須ヘッダー、メソッド、引数のサイズなどをチェックしますが、正しく理解されていないと、効果的な保護と誤検知の両方の原因となることがよくあります。
ごく一般的な例をいくつか挙げます。
- Acceptヘッダーがありません （Acceptヘッダーの欠落）：これは厳密にはRFC違反ではありませんが、このヘッダーのないリクエストの多くは、自動化ツールや不適切なスクリプトから発生しています。カスタムAPIや、このヘッダーを送信しないクライアントに影響を与える可能性があります。多くの環境では、ブロックするよりもログ記録とカウントを行う方が望ましいです。
- ホストヘッダーがありませんHTTP/1.1規格では、Hostヘッダーは必須です。WAFも、適用するポリシーを判断するためにHostヘッダーを必要とします。通常、ここでブロックすることは妥当ですが、テスト中や内部トラフィックの設定ミスにより誤検知が発生する可能性があります。厳密なブロックを有効にする前に、ログを監視することをお勧めします。
- User-Agentヘッダーがありませんこのルールは、基本的なボットや正体不明のトラフィックを抑制することを目的としています。問題は、多くの正当な API が User-Agent を送信しない可能性があることです。最も賢明なアプローチは通常、ログを記録し、一貫性のある正当な API が検出された場合、 IPアドレスまたはパターンを許可リストに追加する.
- GET/HEADリクエストのボディによる検証RFCではGETリクエストやHEADリクエストにボディを送信することを厳密には禁止していませんが、これは一般的な慣行ではなく、回避策の試みを示している可能性があります。多くの場合、まずこれらのリクエストをすべてログに記録し、疑わしい異常が見つかった場合はブロックするのが最善策です。
- 本文にContent-Typeがありません本文は存在するもののContent-Typeが存在しない場合、それはプロトコルの不適切な使用、あるいは分析を回避しようとする試みであることを明確に示しています。このような場合、特にインターネットに接続された環境では、より積極的なブロック措置が有効な場合が多いでしょう。
これらのプロトコル規則に加えて、引数の制限は、アプリケーションレベルのフラッド攻撃やDoS攻撃から保護するためによく用いられます。例えば、次のようになります。
- リクエストあたりの引数の最大数（一部のWAFではデフォルトで255）。
- 個々の引数の最大長（例：400文字）。
- すべての引数の合計サイズ（例：64.000バイト）。
これらの値は多くのアプリケーションにとって妥当ですが、複雑なフォームアップロード、高度なフィルタ、大規模なJSONデータの読み込みなど、誤検知が発生するケースもあります。そのような場合、最も賢明なアプローチは、まずログを記録してカウントし、どのエンドポイントが制限を超えているかを確認し、サイト全体の制限を解除するのではなく、制限を超えているルートのみを調整することです。
偽陽性：それを検出して、失敗せずに済む方法
誤検知とは、WAFが正当なリクエストを悪意のあるものとして識別し、ブロックしたり攻撃としてフラグを立てたりする現象です。OWASP CRSのような包括的なルールセットを有効にしている場合は特に避けられませんが、専門家による適切な管理を行うことで、日々の悩みの種にならないようにすることができます。
誤検知の検出は、ログの綿密なレビューから始まります。これには、どのリクエストがブロックされているか、どのルールがそれらをトリガーしているか、そしてそれらが発生したコンテキスト（URL、パラメータ、ユーザー、オリジンなど）を調べることが含まれます。視覚的なツールやダッシュボードは、403エラーの急増や異常なパターンを特定するのに役立ちます。
クラウドプロバイダーとModSecurityコミュニティの両方から強く推奨されている方法は、シミュレーションモードまたはカウントモードを使用することです。このモードでは、テスト対象のルールは一致するリクエストをログに記録しますが、ブロックは行いません。これにより、例えば、新しいSQLインジェクション対策ルールを本番環境で有効化する前に、そのルールがどれだけの正当なリクエストをブロックしていたかを確認できます。
実際のトラフィックまたはシミュレーションされたトラフィックを受信するステージング環境やプレプロダクション環境でルールをテストすることも有効です。OWASP ZAPやトラフィック再生スクリプトなどのツールを使用すると、正当なパターンや既知の攻撃をシミュレートしてWAFの動作をテストできます。
さらに、誤検知が業務や評判に及ぼす影響を考慮することも重要です。支払いの中断、ユーザー登録の失敗、説明のないまま失敗する重要なAPI呼び出しなど、これらはすべて収益やブランドイメージに直接的な損失をもたらす可能性があります。また、誤検知が多すぎると、セキュリティチームは価値のないアラートに圧倒され、真のインシデントを特定することが困難になります。
規則の調整と登録簿の賢明な利用に関する戦略
誤検知への対処は、「すべてが正常に動作する」までルールを無効にすることではなく、WAFを外科手術のような精密さで微調整することです。ここで、以下のような優れた実践方法が役立ちます。
まず、ルールをグローバルに無効化することは避けてください。特定のルート、特定のパラメータ、または内部トラフィックに対してのみルールIDを除外するなど、非常に具体的な例外を作成するのが望ましいです。こうすることで、アプリケーションの他の部分ではセキュリティが維持され、有用なログも保持されます。
次に、ブロックする前にカウントモードを活用しましょう。新しいルールを最初にログモードでのみ有効化することで、影響を受ける正当なリクエストの数を測定できます。さらに、SIEMのアラート機能を使えば、ルールが異常な量のマッチを生成しているかどうかを迅速に検出できます。
第三に、WAFをSIEMまたは集中ログプラットフォームと統合します。これにより、WAFイベントとその他の指標（異常なシステムアクティビティ、大量の認証失敗、不審な構成変更など）との関連付けが容易になります。また、イベントの深刻度と頻度に基づいて、どのルールを優先的に調整すべきかを判断するのにも役立ちます。
第四に、すべての変更を文書化してください。どのルールを微調整したのか、どのエンドポイントに対して、どのような根拠に基づいて、どのような証拠に基づいて変更したのかを記録してください。サーバーのマニュアルを参照すると役立ちます。この文書化は、内部統制の維持に役立つだけでなく、セキュリティ監査やレビューにおいて、制御が安易に無効化されていないことを証明する上で非常に貴重な資料となります。
WAFにおける自動化、機械学習、および適応型ルール
アプリケーションが拡大し、トラフィックが複雑化するにつれて、WAFを手動で管理することは非現実的になります。そこで、自動化、高度なログ分析、そして場合によっては機械学習が重要になってきます。
まず、SIEMとの統合により、相関ルールと自動応答を構築できます。たとえば、一連のIPアドレスが繰り返しインジェクションやXSSルールをトリガーした場合、それらのIPアドレスを一時的なブロックリストに追加したり、検査レベルを強化したりする自動アクションを生成できます。
第二に、一部のWAFは、一定期間にわたって正当なトラフィックを監視する機械学習モードを組み込んでいます。このデータに基づいて、正常な動作の閾値、パターン、プロファイルを提案または調整します。これにより、ルールがブロックモードに切り替わった際の誤検知を減らし、その後のトラフィックの逸脱を検出するのに役立ちます。
研究や実験室環境では、教師あり学習の手法を用いて、正当なトラフィックと悪意のあるトラフィックを区別するモデルを訓練し、本番環境で使用されるポリシーを改良してきました。この手法は万能薬ではありませんが、従来のシグネチャベースのルールでは容易に検出できない微妙なパターンを明らかにするのに役立ちます。
最後に、 OWASP ZAP、カスタムスクリプト、CI/CDパイプラインなどのツールを用いた継続的な自動テストにより、WAFへの変更が重要な機能を損なったり、明らかな脆弱性を残したりしないことを検証できます。これらのテストをデプロイメントサイクルに組み込むことで、セキュリティは開発フローの自然な一部となり、土壇場でのパッチ適用ではなくなります。
アプリケーションごとのポリシー設計とサービスごとのブラックリスト
ホスティングプロバイダーやISPなどの複雑な環境では、特にシャドウITが関わっている場合、単一のWAFポリシーでは不十分です。同じロードバランサーの背後に複数のドメインやアプリケーションが存在し、それぞれセキュリティ要件やトラフィックプロファイルが異なることはよくあります。このような状況では、サービス固有のポリシーとリストを設計することが不可欠になります。
具体例としては、単一の仮想IPアドレスの背後にある複数のサイト（例：www.company1.comとwww.company2.com）に対してリバースプロキシとして機能するHTTP/Sロードバランサーが挙げられます。このシナリオでは、WAFはリクエストがロードバランシングモジュールに到達する前であっても、リクエストが到着するとすぐにホストヘッダーと送信元IPアドレスを評価するように構成できます。
ロジックは次のようになります。WAFは、SERVER_NAME（ホスト名）とクライアントIPの組み合わせがサイト固有のブラックリストに一致するかどうかを確認します。IPがwww.company2.comではブロックされているがwww.company1.comではブロックされていない場合、403 Forbidden応答は最初のケースでのみ送信されます。「クリーン」なトラフィックはロードバランシングモジュールに渡され、どのバックエンドがリクエストを処理するかが決定されます。
これにより、アクセスポイント全体に対して単一のグローバルリストを使用するのではなく、例えばドメイン固有のブラックリストを維持することが可能になります。ログレベルでは、拒否された各項目は、ルールID、一致した条件、URL、ホスト、クライアントのIPアドレスなどの詳細情報とともにsyslogに記録されるため、その後の分析やリストの拡張、デバッグが容易になります。
この話の教訓は、ポリシーを細分化すればするほど（アプリケーション別、環境別、ユーザータイプ別など）、ログ記録とブロックのバランスをより細かく調整できるということです。例えば、管理ポータルでは非常に厳格な設定を行い、情報提供サイトではやや柔軟な設定にすることができます。その際、各決定が下された理由を常にログに記録しておくことが重要です。
従来のWAFを超えて：WAAPとAPIの保護
脅威の状況は絶えず変化しています。今日では、多くのアプリケーションがクラウドネイティブであり、マイクロサービスアーキテクチャを採用し、パブリックAPIとプライベートAPIを公開しているため、攻撃者にとって格好の標的となっています。従来のWAFは、WAAP（WebアプリケーションおよびAPI保護）またはWAAS（WebアプリケーションおよびAPIセキュリティ）と呼ばれる、より広範なプラットフォームへと進化しました。
これらのソリューションは、Webアプリケーションを自動的に検出するだけでなく、APIエンドポイントを特定し、OpenAPIやSwaggerなどの仕様を受け入れ、その定義を使用してリクエストの準拠性（想定されるデータ型、許可されるパラメータ、サイズ制限など）をチェックします。エンドポイント（例えば、機密性の高いデータを扱うエンドポイント）によっては、より高度な監視とブロックを適用することも可能です。
ログレベルでは、WAAPはコンテキストが豊富なイベントを生成する傾向があります。具体的には、どのAPIエンドポイントが攻撃されたか、どの操作（GET、POST、PUTなど）が行われたか、どのユーザーまたはトークンが関与したか、仕様のどの部分が違反されたかなどです。これにより、一般的なペイロードパターンだけに頼るのではなく、より正確なブロック判断が可能になります。
さらに、多くのWAAPツールには、アプリケーションおよびAPI固有のDoS攻撃対策、位置情報フィルタリング、IPレピュテーション管理、ボットおよびスクレイピングの検出、サービスごとのアラートレベルのカスタマイズオプションなどが含まれています。ここでも重要なのは、より堅牢なアプローチを採用したい箇所と、スムーズな運用を優先したい箇所を柔軟に選択できることであり、同時に、あらゆるインシデントを調査するための堅牢なログデータベースを維持できることです。
総合的に見ると、適切に調整されたWAF（従来型、WAAPベース、クラウドエコシステムに統合されたものなど）は、詳細なログ記録、インテリジェントなブロック、変化する脅威環境への継続的な適応を組み合わせることができるため、現代のアプリケーションおよびAPI防御に不可欠な要素となります。
