お役立ちコラム

WAFの仕組みをわかりやすく解説:脆弱性診断との補完関係と導入・運用の要点

はじめに

WAFはHTTP通信の内容を詳細に検査し、アプリケーション固有の脅威を食い止める仕組みを持っています。Webサイトやアプリケーションへの攻撃は年々巧妙さを増しており、ネットワーク層の防御だけでは対処しきれない場面が増えています。

この記事では、WAFの仕組みを中心に、防御モデルの種類や導入形態の選び方、脆弱性診断との補完関係、そして運用で陥りやすい失敗と対策のポイントを順に取り上げます。

WAFとは何か――定義と基本的な役割

WAFの定義とWebアプリケーション保護の位置づけ

WAFとはWebアプリケーションファイアウォール(Web Application Firewall)の略で、Webサイト・モバイルアプリ・APIを保護するセキュリティの仕組みです。Webアプリケーションが送受信するデータパケットを監視し、フィルタ処理やブロックを行うことで、脅威からアプリケーションを守ります。Webトラフィックで最も一般的な危険度の高いセキュリティの欠陥を検出し、防止するように設計されています(参照*1)。

WAFはWebアプリケーションとインターネットとの間に保護の盾を作り、一般的な攻撃の多くを緩和する役割を担います(参照*2)。SQLインジェクションやクロスサイトスクリプティングといったアプリケーション層の攻撃は、通常のネットワーク機器では見抜きにくいため、WAFがカバーする領域は広いといえます。自社のWebサービスがどのような通信を受け付けているかを把握したうえで、WAFの導入範囲を検討する流れが基本になります。

ネットワークファイアウォール・IPS・NGFWとの違い

WAFと混同されやすい機器にネットワークファイアウォール、侵入防御システム(IPS)、次世代ファイアウォール(NGFW)があります。ネットワークファイアウォールは下位のレイヤ、つまりIPアドレスやポート番号の層を処理します。一方、WAFはWebアプリケーションがより脆弱となる上位レイヤに焦点を当てます(参照*1)。

IPSはシグネチャベースで対応範囲が広く、レイヤ3およびレイヤ4で動作します。WAFはアプリケーションレイヤであるレイヤ7で動作し、各HTTPリクエストを分析することでWebアプリケーションを保護します(参照*1)。こうしたレイヤの違いを理解しておくと、WAFとネットワーク機器の役割分担を整理しやすくなります。

WAFの仕組み――HTTPリクエスト解析から脅威検知・遮断までの流れ

HTTPリクエストの分析ポイント(ヘッダー・クエリ文字列・ボディ)

WAFの仕組みの出発点は、HTTPリクエストの中身を細かく調べる工程です。WAFはHTTPのリクエストを調査し、事前に定義したルールを適用して悪意のあるトラフィックを特定します。分析対象となるHTTP通信の種類として、サーバーからデータを取得するGETリクエスト、サーバーにデータを送信して状態を変更するPOSTリクエスト、データを更新または作成するPUTリクエスト、データを削除するDELETEリクエストがあります(参照*1)。

これらのリクエストには、ヘッダー情報やURLに含まれるクエリ文字列、POSTやPUTで送られるボディ部分が含まれます。WAFはこれらの各部分を読み取り、攻撃コードが紛れ込んでいないかを照合します。たとえば、クエリ文字列にSQL文の断片が含まれていればSQLインジェクションの疑いありと判定し、ボディにスクリプトタグが混入していればクロスサイトスクリプティングの兆候として扱います。自社のWebアプリケーションがどのHTTPメソッドを使っているかを洗い出すことが、WAFの仕組みを活かす第一歩です。

ルールとルールセットによるマッチングの仕組み

WAFの仕組みの中核にあるのが、ルールとルールセットによるマッチングです。ルールとは、フィルター(条件)と、その条件に一致した着信リクエストに対して実行するアクションを組み合わせたものです。ルールセットは、トラフィックに適用できる順序付けられたルールの集合を指します(参照*2)。

広く使われるルールセットの代表例がOWASP CRS(コアルールセット、Core Rule Set)です。OWASP CRSは、ModSecurityまたは互換性のあるWAFとともに使用するための攻撃検出ルールのセットで、OWASPトップテンを含む幅広い攻撃からWebアプリケーションを保護し、偽警告を最小限に抑えることを目的としています。SQLインジェクション、クロスサイトスクリプティング、ローカルファイルインクルージョンなど一般的な攻撃カテゴリに対する保護を提供します(参照*3)。WAFを導入する際は、どのルールセットを基盤にし、自社固有の条件をどこまでカスタマイズするかを事前に設計しておく必要があります。

検知フェーズと緩和フェーズの二段構成

WAFの仕組みは大きく検知と緩和の2つのフェーズで構成されます。検知フェーズでは、着信リクエストを1つ以上のトラフィック検知にかけ、悪質または悪質の可能性がある活動を特定します。有効化された検知のスコアはセキュリティ分析ダッシュボードで確認でき、セキュリティ状況を分析して適切な緩和ルールを決定できます。緩和フェーズでは、カスタムルール、マネージドルール、レートリミットルールなどを通じてリクエストをブロック、チャレンジ、またはスロットル(速度制限)します(参照*2)。

検知時には攻撃スコア(Attack score)という指標も活用されます。Attack scoreは既知の攻撃の変種や悪意あるペイロード(送信データ)を検知し、トラフィックを1(悪質である可能性が高い)から99(悪質である可能性が低い)までのスケールでスコア付けします(参照*2)。このスコアをもとにブロックの閾値を調整することで、正規の通信を止めずに攻撃だけを遮断する精度を高められます。検知と緩和の二段構成を理解したうえで、自社のトラフィック量や攻撃傾向にあわせて閾値を設定する作業が欠かせません。

防御モデルの種類――ネガティブセキュリティとポジティブセキュリティ

ネガティブセキュリティモデル(ブラックリスト型)の特徴

WAFの防御モデルは大きく2種類に分かれます。1つ目がネガティブセキュリティモデルで、ブラックリスト型とも呼ばれます。伝統的に最も広く使われてきた構成で、脅威や攻撃を含むやり取りを除いてすべてのやり取りを許可する方式です。既知の脅威や攻撃を検知するよう設計されたシグネチャとルールを利用します(参照*4)。

この方式の利点は、通常の通信を広く許可しながら、代表的な攻撃パターンを比較的導入しやすい形で遮断できる点にあります。公開WebサイトやECサイトのように、利用者や入力内容のばらつきが大きい環境でも適用しやすく、既知の攻撃への初期防御として機能しやすいのが特徴です。一方で、未知の攻撃手法や、正規の通信に見せかけた巧妙な攻撃には対応しきれない場合があります。また、検知精度はシグネチャやルールの更新状況に左右されるため、導入後も継続的なチューニングと見直しが欠かせません。そのため、ネガティブセキュリティモデルは単独で万能と考えるのではなく、脆弱性修正や監視運用と組み合わせて活用することが重要です。

ポジティブセキュリティモデル(ホワイトリスト型)の特徴

2つ目がポジティブセキュリティモデル、いわゆるホワイトリスト型です。このモデルはすべてのトラフィックをブロックし、有効かつ安全であると判断されるやり取りのみを許可します。厳密なコンテンツ検証と統計分析に基づいており、ゼロデイ脅威(未公開の脆弱性を突く攻撃)や脆弱性の悪用を防ぐのにより効果的です(参照*4)。

ただし、ポジティブセキュリティモデルが真に効果を発揮するには、アプリケーションとその想定される利用方法についての深い知識が必要です(参照*4)。許可する通信の定義が不十分だと、正規のユーザー操作まで遮断してしまう恐れがあります。自社のアプリケーションがどのようなリクエストパターンを受け付けるかを網羅的に洗い出し、許可リストを設計する工程を事前に確保してください。

WAFの導入形態と選び方の判断基準

ネットワーク型・ホスト型・クラウド型の比較

WAFの導入形態は大きく3つに分かれます。WAFはネットワークベース、ホストベース、またはクラウドベースのソリューションとして展開でき、いずれもHTTPアプリケーションレイヤのデータを可視化します(参照*1)。WAFにはソフトウェア、アプライアンス(専用機器)、サービスの形態があります(参照*1)。

ネットワーク型は専用のハードウェアをネットワーク上に配置する方式で、処理速度に優れる反面、機器の購入や設置の手間がかかります。ホスト型はWebサーバーにソフトウェアとして組み込む方式で、既存環境に追加しやすい一方、サーバーへの負荷に注意が必要です。クラウド型は外部のサービスとして利用する方式で、初期費用を抑えやすく、運用管理の一部をサービス提供者に任せられます。独立行政法人情報処理推進機構(IPA)もWAFの製品やサービスを大別して3つの種類に分け、どのような観点で選択すべきかを3つの観点から解説しています(参照*6)。

選定時に確認すべき3つの観点

WAFの選定では、自社の事業目標との整合性が出発点になります。ビジネス目標を最もよく満たすWAF展開の適切な決定を下すことは難しい場合があり、時間とリソースの必要性は、選択した製品を使いこなすための十分なノウハウと自信の必要性と競合します(参照*4)。

IPAはWAFの製品やサービスの選択基準として3つの観点を挙げ、具体的な選択基準を示した表も公開しています(参照*6)。選定作業を進める際は、自社のWebアプリケーションの規模やトラフィック量、セキュリティチームの運用体制、導入後のルール更新にかけられるリソースの3点を基準として並べ、各形態の長所と短所を突き合わせて判断する流れが有効です。

脆弱性診断との補完関係

WAFは通信をリアルタイムで監視し攻撃を遮断する仕組みですが、アプリケーション自体の弱点を根本から取り除くものではありません。IPAは「WAFによるウェブアプリケーションの脆弱性対策」として、Webアプリケーションへの攻撃および脆弱性対策の実情と、各機関におけるWAFに関する取り組みを紹介しています。あわせて「WAFについて誤解されていること」として、WAFが適切に攻撃を検知するために必要な運用についても解説しています(参照*6)。

脆弱性診断はアプリケーションのコードや設定に潜む弱点をあぶり出す作業であり、WAFの防御とは対象も手法も異なります。高度なWAFでは脆弱性スキャナー統合の機能を備え、診断結果をWAFのポリシーに反映させる運用も想定されています(参照*4)。WAFで攻撃を受け止めている間に、脆弱性診断で発見した弱点をコード修正で解消するという流れを組み合わせることで、防御と根本対策の両輪が回り始めます。診断の周期とWAFルールの更新タイミングをあわせて管理する運用計画を立てましょう。

導入・運用で陥りやすい失敗と対策のポイント

偽陽性・偽陰性を生むルール設定の落とし穴

WAFのルール設定で最も起きやすい問題が、偽陽性(正規の通信を誤って遮断すること)と偽陰性(攻撃を見逃すこと)です。マネージドルールセットではいくつかのルールがデフォルトで無効になっていることがあり、それは適切な保護と偽陽性の数を減らすバランスを取るためです。利用可能なルールをすべて有効にすることは推奨されておらず、正当なトラフィックに影響を及ぼす可能性があるとされています。概念実証(PoC)を実行してWAFがブロックできるリクエストの種類を理解している場合を除き、一括有効化は避けるべきです(参照*5)。

実運用では、まずログモード(検知だけして遮断しない状態)でトラフィックを観察し、偽陽性の発生パターンを洗い出す手順を踏むのが定石です。そのうえで遮断するルールを段階的に追加し、影響範囲を確認しながら本番適用へ移行する流れを取ってください。

運用体制とポリシー維持に必要なリソースの見積もり

WAFの導入後に見落とされがちなのが、運用フェーズで必要となるリソースの見積もりです。実現性とサポート性を確保する後続の手順の前提を事前に検討することを忘れがちで、これがおそらく最も頻繁に行われるミスだとされています。長期的に本番環境でその解決策を運用する際に、選択した設計と実装モデルの影響を調べずに設計・計画してしまう例が多いのです。脅威、緩和、アプリケーションリリースなどすべての部分からの定期的な変更に直面する環境下で、高度なWAFポリシーを維持するために必要なリソースを過小評価することが共通の失敗例として挙げられています(参照*4)。

IPAもWAF導入における「導入判断」「導入」「運用」の各フェーズで検討すべきポイントを整理しています(参照*6)。導入前にルール更新の担当者、ログ分析の頻度、アプリケーション改修時のポリシー再設定の作業量を具体的に試算し、運用計画書へ落とし込む作業を忘れないでください。

おわりに

WAFの仕組みはHTTPリクエストの解析、ルールによるマッチング、検知と緩和の二段構成という流れで成り立っています。防御モデルや導入形態の選択肢を把握したうえで、脆弱性診断との役割分担を設計することが防御力の底上げにつながります。

導入後も偽陽性・偽陰性の監視やポリシー維持に継続的なリソースが必要です。自社のトラフィック特性と運用体制を踏まえ、ルール設定とリソース配分の両面から定期的に見直す運用サイクルを確立してください。

お知らせ

WAFやその仕組みを理解することは、ITエンジニアにとって、案件選びや求められるスキルを読み解く際の助けになります。業務範囲や必須スキルを確認し、フリーランス向けの最新案件情報も参考にしましょう。
cyseekではフリーランスのITエンジニア向けの案件をご紹介しています。
案件に関する新着情報は、以下のリンクからご覧いただけます。

フリーランス向けセキュリティ案件の紹介サービスcyseekへの個別相談を促すバナー

参照

関連記事