WAF導入・運用のウソ・ホント

Webサイトを運用する人にとって重要なことは、定常的にトラブルなくサービスを提供し続けることです。これを第一とすると、異常パターンを検出して攻撃を遮断するブラックリスト方式は、サイトによっては膨大なパターンを設定する必要があるホワイトリスト方式と比較してWAFを運用する上でアドバンテージがあります。

これは一部正しいのですが、ホワイトリスト方式においても簡単かつ非常に効果的な設定があります。それは、「アクセス可能なURL（ページ）を制限する事」です。

WAFのWAFと言える所以の機能の一つですが、この設定をするのとしないのでは安全性の差は大きくなります。

これらを自動検出する設定で行えるWAFもありますが、事細かに1ページ1ページ設定するよりも、ある程度まるめて設定してしまった方がメンテナンス性もよくなります。良い例として、特定のディレクトリ以下は許可する、特定の拡張子（.htmlや.jspなど）は許可する、等がおすすめです。緩いルールを複数組み合わせて使うところがポイントです。

結論：ブラックリストもホワイトリストも、すべては運用次第。ただ、ホワイトリストだから大変ということはありません。

WAFはWebアプリの脆弱性を防御するツールですが、なんでもかんでもWAFでやるのは間違った使い方です。他のセキュリティ製品と同じですが、多層防御の一部としての利用が正しいあり方だと考えます。

WAFが効果を発揮する場面は、

• Webアプリの問題の修正箇所が膨大である
• Webアプリの修正作業自体に時間がかかる

以上の場合です。

XSS（クロスサイトスクリプティング）の脆弱性のように修正箇所が膨大な場合には、WAFに適切な設定を施すだけでサイト全体に確実に適用されるため、コストを抑えつつ効果を得ることができます。

また、ロジックが入り組んでいてアプリの修正に時間が必要な場合や現在進行形で急速に拡大中のコンピュータワームへの対処など、緊急対処が必要な場合にもまずの一手を打つことができます。

なお、WAFで対処する場合でもアプリを修正する場合でも、最終的な動作検証が必要な事は変わりありません。この点における対策後の時間とコストは始めから見込んでおく必要があります。

WAFが有効な状況として、サポートや補償がなくなったWebアプリへの対処が挙げられることがあります。しかし、恒久的にWAFで対処を行うことは決して安全とは言い難いため（多層防御の考え方からすると何か一点に依存している状況は不安定であるため）、この問題への対処はサポートや保守契約や運用体制などの見直しをおすすめします。この点についてはWAFはあくまで暫定対処として考えるべきでしょう。

結論：WAFは、Webサイトを素早く全体を安全に出来る唯一の方法です。

セキュリティの観点からすれば、WAFは開発部門とは別の部署が扱うことが望ましいと考えます。開発部門は脆弱性などの問題が発覚したのであればアプリの修正作業を行うべきであり、必要に応じてインフラ部門がその問題をWAFによってカバーできるような体制が理想的であるためです。

しかし、他社製品を含めWAFの機能の一部はWebアプリの高度な知識を要求するものがあり、その点でインフラ部門の知識ベースで追いついていない現実があります。弊社ではそのギャップを埋めるためにWAFのルール設定を代行するルールカスタマイズサービスを実施していますが、すべての製品やSIerが手厚くサポートしてくれるわけではないため、その場合は現場のインフラ担当者が悪戦苦闘することになってしまいます。

ただ、前述のように全てをWAFで完璧にする必要はありません。したがって使うWAFの機能についても全てを知り尽くし使いこなす必要もなく、最低限基本的な部分を抑えれば事足りることは多々あります。（これはアプリの修正も行う多層防御が前提の上での話です。）

とはいうものの、HTTPトラフィックの重要性は日増しに高まっていますので、当然そのパフォーマンスやスケーラビリティ、セキュリティも考慮する必要に迫られます。それらを改善する事ができるWAFは、インフラ担当者にとって関係ない話ではありません。

結論：WAFはインフラ部門で。担当者はそろそろHTTPについてもっとよく理解しておく必要が出てくるでしょう。