CDP:WAF Proxyパターン

Revision as of 15:42, 15 April 2012

高価なWeb Application Firewallの効率的な活用

解決したい課題

Eコマースサイトなど重要な個人情報(クレジットカード情報など)を扱うWebサイトは、セキュリティを高めるためにWAF(Web Application Firewall)を導入することが多い。 しかしクラウド上のシステムではスモールスタートしたシステムが多く、殆どの場合、最初からWAFを導入は考慮されていない。またスケールアウト/インによる(Web)サーバの増減を前提としたシステムも多く、その場合、必要なライセンス数も確定せず非常にWAFの導入は非常に困難な状態となってしまう。

クラウドでの解決/パターンの説明

従来サーバの増加(スケールアウト)は、そもそもサーバの調達に時間がかかったので頻繁には行わず、その(Web/App)サーバに導入するWAFのライセンス数も決定でき、サーバ自体にWAFを導入しても特に問題は起きなかった。 しかし、時間単位でサーバの増減が行われることもあるクラウド環境では、それらのサーバにWAFを導入するのは現実的でなく、むしろ、その上流にプロキシーサーバを導入し、WAFをインストールする方が効果的である。 WAFのみが機能するプロキシーサーバは、負荷も計算できサーバの増減を行う必要も少ないため、必要最低限のライセンス数のみで運用するすることが可能となる。

実装

AWSにはELBと呼ばれるロードバランサーがあるので、WebサーバとELBの間にWAFがインストールされたプロキシーサーバを冗長化のため複数(のAZに)導入するのが効果的である。

• ELBとWeb/Appサーバの間にWAFをインストールしたプロキシサーバを用意する。
• プロキシサーバには必要に応じて(WAFにその機能がない場合)HAProxyなどの負荷分散を行うミドルウェアも導入する。

構造

利点

• Web/Appに手を入れずに、WAFの機能を導入できる。
• 必要ライセンス数がWeb/Appサーバではなく、より少ないプロキシサーバ数となる。

注意点

• SPOFを作らないようにするために、プロキシサーバも複数のAZにまたがるように複数台用意する。
• Web/AppサーバはELBに対して間接的に配置されるのでAuto ScalingによるのELBへの自動アタッチが利用できなくなってしまう。

その他

寄贈したアーキテクト

Ninja of Three