📝

WAFサンドイッチって何だろ？

2022/01/06に公開

AWS

WAF

idea

SAPの勉強中に、WAFサンドイッチという用語が出てきたので調べてみました。

最初に答え

WAFソフトウェアを実装したEC2を2つのELBの間に実装することでした。
以下の画像は、DDoS に対する AWS のベストプラクティスからの引用です。

ホワイトペーパー

DDoS に対する AWS のベストプラクティスのp.19 ~ p.21の内容です。

WAFについて

最初に、一般的なWAFの役割などについて記載されています。

アプリケーションレイヤーで発生する DDoS 攻撃では、インフラストラクチャ攻撃と
比較して、トラフィックのボリュームが低いウェブアプリケーションがよく標的になり
ます。これらのタイプの攻撃を軽減するには、インフラストラクチャの一部にウェブア
プリケーションファイアウォール (WAF) を含めます。

WAF は、ウェブトラフィックにルールセットを適用するフィルターとして機能します。
通常、これらのルールはクロスサイトスクリプト (XSS) や SQL インジェクション
(SQLi) といった弱点に対応しますが、HTTP GET または POST フラッドを軽減して、
DDoS に対する弾力性を構築するためにも役立ちます。

WAFでXSSやDDosなどの攻撃からアプリを守ることができるという、一般的な内容です。

AWSでWAFを使用する方法について

次にAWSでWAFを使用する方法が記載されています。
ん？
「AWS WAF一択だろ！」
と思いましたか？
僕も同感です。

しかし、上記のホワイトペーパーは2015年6月に発行されています。
歴史・年表でみるAWS全サービス一覧－アナウンス日、General Availability(GA)、AWSサービス概要のまとめ－によると、AWS WAFのGAは2015年の10月だそうなので、まだAWS WAFは使えなかったようです。

なので、ホワイトペーパーではEC2を使用する方法が記載されています。

WAF を AWS インフラストラクチャにデプロイするには、最初に AWS Marketplace
で利用可能ないずれかの WAF アプリケーションを選択する必要があります。

WAF ソリューションを選択したら、EC2 インスタンスにソフトウェアをデプロイし、
トラフィックに合わせてスケールするようにインスタンスを設定する必要があります。

WAFアプリの入ったAMIをマーケーットプレイスから選択し、そこからEC2を起動してWAFにしましょうという内容だと思います。

EC2 WAFの問題点について

EC2でWAFを実装する方法では、以下の点が問題であると記載されています。

すべての HTTP リクエストを検査するため、WAF は、アプリケーショントラフィック
の流れの中に設置します。残念ながら、これにより WAF が障害点またはボトルネック
となるシナリオが作成されます。

WAFをアプリケーションの前に設置するとしても、WAF EC2が障害点になったりボトルネックになることへの対応が必要になるということですね。
イメージとして、以下のような構成を考えてみます。

・1台のWAF EC2をパブリックサブネットで実行し、すべてのトラフィックを検査する
・問題のないトラフィックはプライベートなALBに転送する
・プライベートなALBの背後ではAuto Scalingグループで複数のアプリケーションインスタンスが実行されている

解決策

上記の問題点に対する解決策として、以下の方法が記載されています。

トラフィックスパイク中に複数の WAF をオンデマンドで実行する必要があります。WAF 用のこのタイプのスケーリングは、「WAF サンドイッチ」を通じて行われます。

負荷の増加に対応できるように、WAF EC2を複数実行できるような構成を挙げていますね。
そして、WAFサンドイッチについて、以下のような構成が記載されています。

「WAF サンドイッチ」では、WAF ソフトウェアを実行している EC2 インスタンスは
Auto Scaling グループに含まれ、2 つの ELB ロードバランサー間に配置されます。

デフォルト VPC の基本的なロードバランサーは、すべての着信トラフィックを
WAF EC2 インスタンスに分散する、フロントエンドのパブリック側のロードバラン
サーになります。

ここまでの構成を図にしてみましょう。

・パブリックサブネットにALBを設置
・ALBの背後にAuto Scalingグループで複数のWAF EC2を実行

上記の構成にすることで、以下の効果が得られると記載されています。

ELB の背後の Auto Scaling グループで WAF EC2 インスタンスを
実行することで、高いレベルでのトラフィックのスパイクが発生したときに WAF EC2
インスタンスは追加され、インスタンスはスケールできます。

ALBによる負荷分散と、負荷増加時の自動スケールができるようになるということですね。
これで先述の問題を解消することができます。

WAF EC2以降の構成

WAF EC2以降の構成は以下のように記載されています。

トラフィックが検査およびフィルタリングされると、WAF EC2 インスタンスは内部の
バックエンドロードバランサーにトラフィックを転送し、このロードバランサーがトラ
フィックをアプリケーションの EC2 インスタンス間に分散します。

図にしてみましょう。

※下記が冒頭にも紹介した公式の図ですが、少し古いので最新のアイコンとは異なります。

・WAF EC2からプライベートなALBに、フィルタリングされたトラフィックを転送
・プライベートなALBからアプリケーションインスタンスにトラフィックを分散

上記の構成により、以下の効果が得られると記載されています。

WAF EC2 インスタンスは、アプリケーションの EC2 インスタンスの
可用性に影響することなく、スケールしてキャパシティーの要求を満たすことができま
す。

WAF EC2のボトルネック問題は、パブリックなALBによる負荷分散とAuto Scalingで解消され、アプリケーションインスタンスも同様にプライベートなALBとAuto Scalingによって可用性を保つことができています。
負荷が増えてもどちらもスケールできるので、より高い可用性を実現できています。

このようにして、WAF EC2をパブリックなALBとプライベートなALBで挟む構成にすることで、セキュリティと可用性を両立させる方法がWAFサンドイッチということなんですね。

AWS WAFを使った場合

EC2 WAFを採用した場合は、WAFサンドイッチで可用性を向上させました。
ではAWS WAFを使用した場合どうなるのでしょうか？
以下のような構成になるかと思います。

・パブリックなALBの前段にAWS WAFを設置
・AWS WAFですべてのトラフィックを検査、フィルタリングする
・AWS WAFで問題ないトラフィックのみ、パブリックなALBに転送
・パブリックなALBからプライベートなアプリケーションインスタンスに負荷分散

この構成のより、EC2 WAFが不要になるため、スッキリした構成図になりました。
また、AWS WAFはマネージドサービスなので、EC2 WAFのようなスケールなどの問題も考える必要はなくなります。
ただし、AWS WAFにもいくつかの制限はあるので、詳しくはAWS WAF のクォータをご覧下さい。

料金に関してもおそらくAWS WAFの方が安くなるのではないかと思います。

AWS WAFにもWAFサンドイッチの考え方はあるのか

AWS WAF 実装のガイドラインでは、WAFサンドイッチ (WAF Sandwich)という単語はヒットしませんでした。

まとめ

今回はWAFサンドイッチについて調べてました。
AWS WAFがGAされる以前の構成方法で、EC2を使用したWAFの可用性とセキュリティを両立させる方法だったという認識です。
現状ではAWS WAFを使用するのがファーストチョイスだと思いますが、こういった構成方法もあるという勉強になりました。
参考になれば幸いです。

参考資料

・DDoS に対する AWS のベストプラクティス
・歴史・年表でみるAWS全サービス一覧－アナウンス日、General Availability(GA)、AWSサービス概要のまとめ－
・AWS WAF 実装のガイドライン
・AWS WAF のクォータ