ケーススタディで学ぶ、AWS WAFの導入における考慮点

AWS WAFについて「どのような防御を行うか？」「どのAWSリソースと関連付けるか？」を考えます。

− はじめに
− AWS WAFについて
− ケーススタディ
−− どのような防御を行うか？
−− どのAWSリソースと関連付けるか？
− まとめ

この記事は Eureka Advent Calendar 2022 の 11日目の記事です。

はじめに

こんにちは、エウレカ SREチームの@MoneyForestです。

※うちのうさぎ（トトロ♂4歳）です

私は今年からBackend EngineerからSREに転身しました。

アプリケーションコード以外でどのようなセキュリティ対策ができるかについて自身の解像度が低かったので、AWS WAFについて個人的に調べてみました。時期的にもアドベントカレンダーのネタに丁度いいかなと思い、ケーススタディを考えてみました。

それでは本題に参りましょう。

AWS WAFについて

AWS WAFはアプリケーションレイヤーにおいて悪意あるリクエストからアプリケーションを守るためのサービスです。

適用したルールに基づいてHTTP(S)トラフィックをフィルタリングすることで、SQLインジェクション、XSS、L7レイヤでのDDoSなどの悪意のあるリクエストからアプリケーションを防御することができます。

AWS WAFは、CloudFront、API Gateway、Application Load Balancer、AppSyncなどのAWSリソースに関連付けることができます。

関連付けられたAWSリソースは、TCP/TLS 接続を終端させ、受信したHTTP リクエストを処理してからフィルタリングのためにリクエストを AWS WAF に渡すようです。（参考）

ケーススタディ

それでは、以下のようなアーキテクチャにおいてAWS WAFを導入するケースについて考えてみましょう。

どのような防御を行うか？

AWS WAFを導入するにあたり一番最初に考えるのは、AWS WAFでどのような防御を行うかということでしょう。

AWS WAFの実装については デベロッパーガイド や、AWS Whitepapersの Guidelines for Implementing AWS WAF が詳しいですが、具体的にどのようなルールを設定するのが良いのでしょうか。

今回のケースにおいて、どのようなルールを適用すべきか考えてみましょう。

マネージドルールグループ

AWS WAF では、マネージドルールグループというAWS および AWS Marketplace 販売者がマネージドするルールのコレクションを使用することができます。

そのうち、AWSがマネージドするルールグループは無料で使用できます。（一部ルールを除く）

ルールの管理およびメンテナンスはAWS（もしくはAWS Marketplace 販売者）が行ってくれるため、低コストで導入・運用することができます。

AWSマネージドルールグループの中で、今回のケースで活用できそうなものについて見ていきましょう。

コアルールセット (CRS) マネージドルールグループ（AWSManagedRulesCommonRuleSet）

OWASP Top Ten に記載のあるような、一般的な脆弱性に対する防御内容がまとまったAWSマネージドルールグループです。「すべての AWS WAF ユースケースでこのルールグループを使用することを検討してください。」とドキュメントに記載がある通り、ほとんどのケースで有効です。

SQL データベースマネージドルールグループ（AWSManagedRulesSQLiRuleSet）

SQL インジェクションに対する防御内容がまとまったAWSマネージドルールグループです。今回のケースのように、オリジンがデータベースと接続する場合は有効です。

Linux オペレーティングシステムマネージドルールグループ（AWSManagedRulesLinuxRuleSet）

Linux 固有の脆弱性に対する防御内容がまとまったAWSマネージドルールグループです。今回のケースのように、EC2のマシンイメージがLinuxベースの場合は有効です。

POSIX オペレーティングシステムマネージドルールグループ（AWSManagedRulesUnixRuleSet）

Unixのコマンドインジェクションなどの脆弱性に対する防御内容がまとまったAWSマネージドルールグループです。今回のケースのように、EC2のマシンイメージがUnixベースの場合は有効です。

独自ルールグループ

AWS WAF では、独自ルールグループを作成することも可能です。

一般的なものとしては、送信元 IP アドレスごとにリクエストのレートを制限するルール（レートリミット）の追加が考えられます。

こちらは実装が必要ですが、ナレッジセンター（AWS WAF の特定のリクエストパラメータまたは URI にレート制限を適用する方法を教えてください。）にレートリミットの設定手順があります。

他には、社内IPアドレスなど、信頼できることがわかっているIPについてホワイトリストを作成したり、逆にブラックリストを作成することでIPベースでのアクセスコントロールができます。

Lambdaを活用してログを解析しブラックリストを更新することで、オリジンで異常なエラーを発生させているIPアドレスや、ハニーポットにアクセスしてきたIPアドレスを遮断するなど、動的な防御も可能です。（参考: AWS ソリューションライブラリ）

どのAWSリソースと関連付けるか？

次に考えるのは、AWS WAFをどのAWSリソースと関連付けて運用するかということでしょう。

AWS Whitepapersによると、特別な理由がなければCloudFrontに関連付けることを推奨しているようです。（攻撃者に一番近いエッジでの防御が推奨されるのは違和感がありませんね。）

CloudFrontに関連付ける場合は、ALBへのアクセスをCloudFrontからのみ許可するような設定にするのがよいでしょう。

※ CloudFront デベロッパーガイド にユーザーが ALBに直接アクセスできないようにし、CloudFront 経由のアクセスのみ許可する方法について記載があります。

今回のケースにおいて他に候補となるのはALBですが、コストを抑えたい場合はこちらに関連付けることも考えられます。

AWS WAFの導入により生じるコストは以下のようなものが挙げられます。

・AWS WAFのリクエストによる従量課金

AWS WAFではリクエスト量に応じて課金されます。AWS WAF の料金 によると、東京リージョンでは 100 万リクエストあたり 0.60USDとなっています。

・ログの転送・保管コスト

AWS WAFはログ記録先として以下を設定できます。

• CloudWatch Logs
• Amazon S3 バケット
• Kinesis Data Firehose

それぞれの転送・保管において生じるコストを考慮する必要があります。

・ログの分析コスト

運用の中で、AWS WAFがどのような攻撃をどれくらいブロックしたかを分析する要件がある場合、ログの分析にかかるコストについても考慮する必要があります。

例としてS3バケットに転送したWAFログをAWS Athenaでクエリする場合のコストを見てみると、TB あたり$5.00 となっています。（Amazon Athena pricing）

ひとつひとつのコストは大きなものではありませんが、アプリケーションの規模や作りによってはCloudFrontのリクエスト量はALBの何倍にもなるため、ALBにAWS WAFを関連付けるケースも考えられそうです。

余談ですが、本ケーススタディのようなアーキテクチャで、ALBにAWS WAFを関連付けたときに注意する点があります。

AWS WAFでIPアドレスを評価するルールにおいて、送信元 IP アドレスがCloudFrontのIPアドレスになってしまうため、リクエストヘッダのX-Forwarder-forを参照する必要があります。

※ CloudFront デベロッパーガイド にクライアント IP アドレスの取り扱いについて記載があり、X-Forwarder-forにクライアント IP アドレスを設定する際の挙動が記載されています。

まとめ

本ケーススタディでは、AWS WAFを導入する際に「どのような防御を行うか？」ということと、「どのAWSリソースと関連付けるか？」について考えてみました。

本ケーススタディでは、引用しているドキュメントはすべてAWSが公式に提供しているものになっているので、信頼して活用することができます。

AWS WAFを活用することで様々な脅威からアプリケーションを防御することができますが、例えばAWS WAFでSQLインジェクションの防御をしたからといって、SQLインジェクションが可能なアプリケーションコードを書いていいかというと、そうではありません。

あくまで各レイヤの責務でそれぞれ適切な防御を行うことが大切です。

ここまで読んでいただいてありがとうございます。この記事がこれからAWS WAFを活用するどなたかの参考になれば幸いです。

明日は @daichiharada さんの「エウレカのDevSecOps」についてです！！