CDP:WAF Proxyパターン

From AWS-CloudDesignPattern
Revision as of 15:44, 15 April 2012 by KenTamagawa (Talk | contribs)
Jump to: navigation, search

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

Contents

解決したい課題

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などの負荷分散を行うミドルウェアも導入する。

構造

6wNg0ISJczU5Pz1m-87A06.png

利点

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

注意点

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

その他

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox