6. WAFはシンプルに使いたい

ユーザーによっては、DMZ（DeMilitarized Zone、非武装地帯）にあるWebサーバーすべてをWAF経由でアクセスさせようとする運用担当者もいます。しかし、ちょっと待ってください。DMZにあるWebサーバーの用途は、特定されているでしょうか。

Webサーバーには、社外への公開用や、社内イントラ用、社外からの認証権限付きアクセス用など、さまざまな用途があります。これらのサーバーを一斉に1つのWAFにつなぐと、トラブルが発生した際の解決を困難にしてしまいます。用途ごとに複数のWAFを導入し、問題の切り分けを容易にしておくことを勧めます。

例えば、DMZに存在するWebサーバーと、DMZに存在するリバース・プロキシを介してアクセスする社内LAN上のWebサーバーは、別々のWAFを用意した方がよいでしょう。WAFを別々に用意することで、トラブル発生時の問題解決が格段に容易になります。

しかし、「費用の関係で、1台のWAFで何とか運用したい」というケースもあります。この場合うは、十分な時間をかけてネットワークを設計しておくことが必要です。あらかじめ十分な時間をかけて設計しておかないと、問題が潜在化し、運用後に解決困難なトラブルとして顕在化することが考えられます。

「目先の費用の安さに惑わされた挙げ句、トータルでみたら高い買い物になってしまった」ということは避けなければなりません。

7. WAFを導入する際の、もう1つの忘れもの

WAFを導入するということは、外部からWebサーバーに直接アクセスできなくなるということです。つまり、保守作業のためにWebサーバーやDBサーバーへ接続できる経路が、WAFによって遮断される可能性があるのです。

特に、ロード・バランサやSSLアクセラレータを兼用してプロキシ方式で導入した場合は、メンテナンス用の経路を別途用意しておかないと、接続が遮断される可能性が高くなります。後で経路を追加しようすると、ネットワークの設計のうえで無理が生じる可能性があります。最初からメンテナンス経路も含めて、WAF導入のためのネットワークを設計しましょう。

次回（最終回）は、セキュリティ診断の現場から、Webサイトに潜む脆弱性個所を指摘し、対処方法を解説します。お楽しみに。