WAFを導入しただけで安心していませんか？ファイアウォールやIPS/IDSとの違い、よくある問題と正しい対応方法

WAFとは？

WAFとは「Web Application Firewall」の略で、ファイアウォールの一種です。読み方としては「ワフ」と呼ばれています。

WAFは、可用性、セキュリティ侵害、リソースの過剰消費に影響を与えるようなWebの脆弱性を悪用した一般的な攻撃やボットからWebアプリケーションまたはAPIを保護する役割を果たします。Webアプリケーションの脆弱性には、SQLインジェクションやクロスサイト・スクリプティング攻撃（XSS）など、Webアプリケーションを構成するシステムやプログラムの実装上の不備なども含まれます。

WAFの導入が増えている背景

WAFは、金融など高度なセキュリティが求められる業界だけでなく、各業界のガイドラインでIDS/IPS（後述）とともに導入が推奨されています。2018年に個人情報保護委員会が注意喚起を出し、2019にはIPA（独立行政法人 情報処理推進機構）がWebアプリケーションのセキュリティ対策のポイントをまとめています。

また、3大クラウドサービスであるAmazon Web ServiceやGoogle Cloud Platform、Microsoft Azureの普及により、クラウドサービス内にWAFがサービスとして提供されるようになりました。これにより、導入が容易になったこともWAFの利用が増えている背景にあると考えられます。

WAFの仕組み

まずは、WAFの仕組みをおさらいしましょう。WAFはシグネチャでWebアプリケーションへの不正アクセスを防止します。シグネチャとは直訳すると「署名」という意味ですが、セキュリティ用語では「さまざまな攻撃を識別するためのルールや符号」を表し、既知の不正な通信や攻撃パターンを識別するためのルール集です。

ブラックリスト方式

ブラックリスト方式では、あらかじめ設定した不正パターンに該当する通信をブロックします。ブラックリスト方式は、正常な通信を妨げないというメリットがあります。ただし、ブラックリストに登録されていない新たな攻撃には対応できません。そのため、定期的にシグネチャを更新する必要があります。一般的には、このブラックリスト方式が採用されています。

ホワイトリスト方式

ホワイトリスト方式では、許可すべきパターンのみを通してそれ以外の通信をブロックします。不正アクセスを確実に遮断できるメリットがある反面、事前に許可すべきパターンをすべて定義しておかなければ、正常なアクセスもブロックされてしまいます。ブラックリスト方式と比較すると定義のアップデートは少なくて済みますが、最初に正しく定義するのが大変です。

ファイアウォールとの違い

一般的なファイアウォールは、送信元情報（IPアドレス）とポート番号をもとに通信を制御します。しかし、ファイアウォールは正常な通信と攻撃を見分けることができず、3大クラウドサービスを含めて外部に公開しているアプリケーションで外部アクセスを厳しく遮断するのは現実的ではありません。そこで有効なのが、シグネチャを使って不正な通信を見分けて防御するWAFというわけです。一般的なファイアウォールとは、防御するレイヤーが異なります。

IPS/IDSとの違い

WAFとよく一緒に使われる言葉に「IDS/IPS」があります。IDSは「 Intrusion Detection System」の略で「侵入検知システム」のことで、IPSは「Intrusion Prevention System」の略で「侵入防御システム」のことです。IDSは侵入を検知して、IPSは検知した後に遮断も行うという違いがあります。

IDS/IPSはOSやミドルウェアレベルの防御を担います。WAFはそれよりも上位のレイヤーで動作するため、どちらかだけあればいいというものではありません。どちらも適切に設定する必要があります。

WAFを「導入して終わり」の企業が多い

WAFは重要なセキュリティツールである一方、「導入したらあとは勝手にサービスが良い感じに運用してくれる」と考えている企業が多いように感じています。自社でWAFを導入している場合だけでなく、外部にWAFの運用を委託している場合でも丸投げとなっている事例が少なくありません。「導入して終わり」になっていると、WAFが原因でさまざまな問題が発生する可能性があります。

誤検知の問題

代表的な問題が、誤検知です。

ほとんどの企業が、WAFを導入する場合にクラウドサービスが提供するマネージドルールセットを利用したブラックリスト方式を採用しています。「マネージドルールだから、クラウドサービスが自動でさばいてくれている」と考えがちですが、現実はそうではありません。ブラックリスト方式は、あらかじめ定義された不正パターン（シグネチャ）と通信を照合し、一致した通信をブロックします。

このシグネチャは、自社で実装しているWebサイト上のアプリケーションや他社のマーケティングツールのタグによるアプリケーションなど、本来なら正しい挙動であり問題がないにもかかわらず「シグネチャに一致するから」という理由でブロック（誤検知）されてしまうことがあります。

本来、WAFを導入する場合は、この誤検知に対する認識や正しい対処を行う運用の体制がセットであるべきですが、この運用が抜けている企業が少なくありません。運用が欠けていると、WAFは適切な効果を発揮してくれないだけでなく、問題の原因となることもあります。

WAFの運用が不足していてよく起こる問題と、それに対する誤った対応、本来あるべき正しい対応をいくつかご紹介するので、参考にしてください。

問題その1：マーケティングツールが引っかかったケース

誤った対応

「403 Forbidden」は、Webサイトが閲覧禁止になっている場合に表示されるエラーです。権限の設定にミスがあったり、アクセスが集中したりしたときに発生しますが、WAFの誤検知によってアクセスが遮断されてしまうこともあります。

原因となるタグを見つけて無効にするのは一見正しい対応に見えますが、対象のマーケティングツールを無効にすることで、本来得られるはずだったマーケティングツール導入によるメリットを得られなくなります。また、シグネチャの設定を変えていないその場しのぎの対応なので、別のツールで同じ問題が再発するリスクを抱えたままで、解決になっていません。

また、すでに当該のシグネチャに引っかかり403となったユーザーは、例えばCookieにセットされた値が原因だった場合、403から脱出できない状態が続いている可能性があります。

Cookie規制とポストCookieについて整理した資料を公開中です。こちらもぜひご参照ください。

正しい対応

まずは「本当にセキュリティ上の懸念があるのか、誤検知なのか」を調査することが第一です。対象のツールに問題がないのであれば、シグネチャの設定を見直すのが正しい対応です。各種ツールは、必ず何か目的やメリットがあって導入しているはずです。十分な調査をせずに、そのメリットを放棄する対応はおすすめしません。

問題その2：403ページに十分な情報がないケース

誤った対応

403ページがデフォルトのままだと、403ページが表示されたユーザーがどうすればいいかわかりません。対象となったユーザーは「エラーが起きた」というネガティブな体験をしたまま、サイトを離脱することになります。

正しい対応

WAFに引っかかったときに遷移する403ページをカスタマイズして、適切な情報を案内することで、ユーザーの離脱を防止できます。対応方法や問い合わせ先など、共通の案内ページを用意しておきましょう。

問題その3：不正検知に気が付かないケース

誤った対応

「導入して終わり」だと、その後にWAFが不正パターンを検知してもそれに気付かないケースがあります。これは本来必要なアプリケーションが正しく動作せず、ビジネスの機会損失につながったり、ユーザーの体験を損ねている状態を放置することにもつながったりします。

正しい対応

ここでは詳しく触れませんが、検索すればWAFの検知状況をSlackなどのコミュニケーションツールに自動投稿する方法など、参考になる記事がたくさんヒットします。WAFを運用するのであれば、リアルタイムに通知する体制もセットで構築しましょう。

まとめ

WAFはもはや必須といえるソリューションですが、導入後に十分に運用されていないケースが多く見られます。導入直後のマネージドルールセットは暫定的なものと捉え、その後の運用状況を検証しながら調整していくことは必須と考えましょう。

導入後、数日したらある程度の誤検知のパターンが見えてくるはずです。また、新しいタグをセットしたり、Webサイトの改修を行った直後は、導入時と同様に少なくとも数日間は検知状況を注視する必要があります。

誤検知には「偽陽性」と「偽陰性」があります。ここでは偽陽性について触れましたが、不正な処理を正常なものとして通過させてしまう偽陰性についても注意を払う必要があります。WAFの運用をおろそかにせず、適切なセキュリティレベルを保つことが重要です。