WAF Proxyパターン
高価なWeb Application Firewallの効率的な活用
目次[非表示] |
解決したい課題
Eコマースサイトなど重要な個人情報（クレジットカード情報など）を扱うWebサイトは、セキュリティを高めるためにWAF（Web Application Firewall） を導入することが多い。 しかしクラウド上のシステムではスモールスタートしたシステムが多く、ほとんどの場合WAFの導入は考慮されていない。 またスケールアウト/インによるサーバーの増減を前提としたシステムも多く、その場合、必要なライセンス数が確定できないのでWAFの導入は困難になってしまう。
クラウドでの解決/パターンの説明
従来はサーバ台数を決定した後に調達を行っていたため、導入するWAFの台数も固定であり、特に問題は起きなかった。 しかし、時間単位でサーバーの増減が行われることもあるクラウド環境では、それらのサーバーにWAFを導入するのは現実的でなく、 むしろ、その上流にプロキシーサーバーを導入し、WAFをインストールする方が効果的である。 WAFのみが機能するプロキシーサーバーを構築すれば、少ない台数で運用できるため、必要最低限のライセンス数のみで運用することが可能となる。
実装
EC2とELBの間にWAFがインストールされたプロキシーサーバーを配置する。冗長化のため複数導入するのがよい。
- ELBとEC2の間にWAFをインストールしたプロキシサーバー（EC2）を用意する。
- プロキシサーバには必要に応じてHAProxyなどの負荷分散を行うミドルウエアも導入する。
構造
利点
- Web/APサーバーに手を入れずに、WAFを導入できる。
- WAFの必要ライセンス数がWeb/APサーバー数ではなく、より少ないプロキシサーバー数となる。
注意点
- SPOFを作らないようにするために、プロキシサーバーも複数用意する。
- Web/APサーバーはELBに対して間接的に配置されるので、サーバー増減の際にAuto ScalingがELBに自動にEC2をアタッチする機能が利用できなくなってしまう。
その他
バックエンドのWebシステムが複数ある場合、Shared Serviceパターンを併用し、ELB/WAFのみを共用のVPCに入れて、各システムのVPCとVPC Peeringすることで、 複数システム間でWAFを効率よく利用する事ができる。
関連ブログ