やってみなけりゃ分からない? WAFの「活用メリット」と「落とし穴」

4. 忘れがちなサーバー証明書

WAFは、パケットの中身を見て、攻撃かどうかを判断します。つまり、SSL（Secure Sockets Layer）などによってエンド・ツー・エンドで暗号化がなされている場合は、パケットの中身をチェックできないため、攻撃かどうかを判断できません。しかし、現実のWebサイトの多くは、SSLを使用しています。WAFはどうやって通信の中身をチェックしているのでしょうか。

WAFは、WAF本体に「SSLサーバー証明書」を登録し、クライアントから送られてくるパケットを復号してチェックします。つまり、WebサーバーにSSLサーバー証明書を入れて運用していて、後付けでWAFを入れる場合には、Webサーバーのサーバー証明書をWAFに移す必要があるのです。この際に、いくつか注意が必要です。

WAFの故障などを想定して、Webサーバーにサーバー証明書を残す場合、証明書の発行会社によっては追加のライセンスが必要になります（このあたりは、証明書発行会社によって異なりますので、発行会社に確認してください）。

もう1つ注意が必要なのは「ワイルドカード証明書」です。

証明書発行会社の中には、ワイルドカード証明書という名称で、同一ドメインの複数サーバーの証明書を一括して安く発行しているケースがあります。しかし、WAFによっては、ワイルドカード証明書に対応していないケースがあります。この場合、サーバー1台ごとに証明書を購入する必要があります。このため、コンテンツごとに細かくサーバーを分けて運営しているケースでは、証明書のライセンス費用が一気に増えかねません。

ワイルドカード証明書を使用している場合は、証明書の追加ライセンス費用を見込みながら、費用を軽減する方法を検討ください。例えば、サーバーの台数を整理・統合する方法や、サーバー証明書が不要なサーバーを洗い出して証明書の契約を廃止する方法などがあります。

5. 機能を活用して安価にしたつもりが・・・

WAFの配置方法はさまざまですが、一般的には、WAFが備える2つのネットワーク・ポートを使って、ネットワーク経路上に設置します。この設置形態は、ネットワークの構成によって「ブリッジ型」（アクセス透過型）と「プロキシ型」の2通りに分かれます。

ブリッジ型では、WAFがつながっている、WAN側のネットワークとLAN側のネットワークが、同じセグメントになります。つまり、ネットワーク的にブリッジとして動作します。この一方、プロキシ型では、WAN側のネットワークとLAN側のネットワークが、異なるセグメントになっています。つまり、ネットワーク的にファイアウォールとして動作します。

ブリッジ型かプロキシ型かは、基本的に、導入するネットワークに合わせて決定します。既存のネットワーク構成に変更を加えることなく導入できるのは、ブリッジ型です。ブリッジ型であれば、ネットワーク経路上に、それこそブリッジと同様に追加するだけで利用できます。クライアントやサーバーは、ブリッジの存在を意識することなく、直接相手のIPアドレスを指定して通信できます。

購入前にWAFを試用するケースでは、ブリッジ型でログの収集だけで動作させるとよいでしょう。または、スイッチのミラー・ポートからパケットをキャプチャする方法も適切です。これらの方法は、既存のシステム環境に影響を及ぼすことがないため、簡単に導入できます。

予算の都合でハードウエアを2重化するHA構成（高可用性構成）がとれない場合も、ブリッジ型は有効です。一般的にWAFのNICはバイパス機能を備えるため、WAFが故障した場合でも、Webサイトへのアクセスが止まることがありません。もちろん、WAFが故障している場合は、攻撃コードの検知や遮断は行えません。

もう一点、注意しておくべきポイントがあります。それは、「SSLアクセラレータ」や「ロード・バランサ」（負荷分散）の機能です。WAFの中には、これらの機能を兼ね備えた製品もあります。こうした製品を購入することで、WAF、ロード・バランサ、SSLアクセラレータなどを個別に購入するよりも安くつくケースがあります。

ただし、これらの機能を使用した場合は、一般的な製品では、プロキシ型しか使えなくなります（ブリッジ型＝トランスペアレント型プロキシでこれらの機能を使えるようにしているケースは、あまりありません）。プロキシ型では、WAFに障害が発生すると、Webサイトへのアクセスができなくなります。このため、WAFを2重化するか、障害発生時にWebサイトが一時的に不通になることを容認するしかありません。

WAFの機能を利用してコストを下げる場合は、障害時の対応も考えに入れて検討しましょう。