この記事はアイレット株式会社 クラウドインテグレーション事業部
セキュリティセクション所属、

Japan AWS Top Engineers である田所 隆之氏の監修を受けて作成した記事となっております。

はじめに

こんにちは、25卒の安彦と申します。
みなさん、WAFは使ってますか？

WAF（Web Application Firewall）とは、Webアプリケーションの保護に特化したセキュリティ対策サービスのことです。Webアプリケーションの通信を分析し、SQLインジェクションやクロスサイトスクリプティング（XSS）などの脆弱性を突く攻撃を検知・遮断します。AWSもこのWAFをサービスとして提供しています。
今回はAWSが提供するAWS WAFの仕組み、検知に使われるルールについて解説していこうと思います。

どうやって不正なアクセスを検知するのか

AWS WAFは基本的にApplication Load BalancerやCloudFrontにアタッチされて使用されますが、それだけでは通信を監視することはできません。
AWS WAFに正常なアクセスと不正アクセスを見分けるための「ルール」を付与する必要があります。
例えば「このIPアドレスからの通信はブロック」や「特定の文字列を検知したらブロック」など、遮断する基準を与えることで、この基準に従ってWAFが通信をブロックするようになります。

このルール設定を迂闊に行うと正常なアクセスまで止めてしまう恐れがあるため、注意が必要です。

AWS WAFの構成単位について

1.Web ACL (Web Access Control List)
WAFにおける最上位のコンポーネントです。Web ACLに各種ルールを紐付け、リソースに紐付けることで
対象を不正なアクセスから保護することができます。

2.ルールグループ
複数のルールを論理的にひとまとめにしたものです。
ルールグループを利用することでルールの一元管理が可能です。

3.ルール
不正アクセスの検知条件と、条件に一致した場合の挙動の定義を組み合わせた、WAFの最小構成単位です 。Web ACLに直接追加することも、前述のルールグループに内包して管理することも可能です。

WCU (Web ACL Capacity Units) について
各ルールやルールグループが消費する処理能力を数値化した単位です 。Web ACLごとにWCUの上限が
定められており、デフォルトでは1500 WCU、上限緩和申請により最大5000 WCUまで拡張可能です。
ルールの複雑さや種類によって消費するWCUは異なり、一度作成したルールグループのWCU
キャパシティは後から変更できないため、初期設計段階での慎重な計画が求められます 。

AWS WAFの設定方法（ALB想定）

それでは実際にマネージメントコンソールからWAFを設定する手順を解説していきます。
今回はALBとの連携を前提としてWAFを作成していきます。

(1)  AWSマネジメントコンソールの上部検索バーでWAF & Shieldと入力し、サービスページ
に移動します。
(2)  左側のメニューからWeb ACLsをクリックし、Create web ACLボタン を押します。

(3)  Describe web ACL and associate it to resources の画面に遷移するので、Web ACLの設定を
していきます。
・Resource type: Regional resourcesを選択します。
・Region: 保護したいリソースがあるリージョン（例: Asia Pacific (Tokyo) ）を選択します。
・Name: Web ACLの名前を入力します（例: my-test-alb-waf)
・Description: Web ACLの補足説明を記入します。
・CloudWatch metric name: Amazon CloudWatchが収集するメトリクス名を記入します。

(4)  Associated AWS resourcesセクションでは、実際にAWSリソースとWAFを関連付けていきます。
Add AWS resourcesボタンをクリックします 。
Resource type で Application Load Balancer を選択します 。
同じリージョンにあるALBの一覧が表示されるので、保護したいALBにチェックを入れます。
（今回は事前に作成したALBを選択している）
Addボタンをクリックします。

表示されているALB名に間違いがないことを確認して、Nextをクリックします。

(5)  Add rules and rule groupsセクションではWeb ACLに設定するルールを設定していきます。
たくさんのルールセットが表示されますが、まずは基本として、
AWS managed rule groupsリスト内のFree rule groupsからCore rule setを選択し、
画面下部のAdd rulesをクリックします。

(6)  設定するルール名、使用するWCU の数、デフォルトアクションを確認する画面に移ります。
（デフォルトアクションについては、今回はAllowで設定します。）
内容を確認し、問題なければ、Nextをクリックします。

(7)  Set rule priority セクションではルールの優先度を設定することができます。
今回は使用するルールは一つだけなので特に設定することなくスキップします。

(8)  Configure metrics ではWAFの活動記録を、AWSの監視サービスであるAmazon CloudWatchに送る
ための設定を行うことができます。こちらも現状はデフォルトで進みます。

(9)  最後に作成するWeb ACLのレビュー画面に移ります。設定内容に問題がなければ
画面下部のCreate web ACLをクリックして Web ACLを作成します。

これでWeb ACLの作成は完了です。作成後はWeb ACLs画面からリソースの確認、変更ができるように
なります。

実際の運用について

ルールとアクション

Web ACLに設定されているルールにはアクションを設定できます。
ルールに設定できるアクションにはAllow(許可)、Block(拒否)の他にCount(カウント)という重要な
アクションがあります。Countは、ルールに一致したリクエストをブロックせずにあえて通過させ、
その事実のみをログに記録する機能です 。

本番環境へ安全にルールを適用するためには、このCountモードの活用は不可欠です。
いきなりBlockで適用すると、正常な通信を誤って遮断してしまうリスクがあります 。
まずCount設定でルールを導入してトラフィックへの影響を監視・分析し、問題がないことを確認して
からBlockに変更する、という段階的な適用を推奨します。

複数のルールを運用する

AWS WAFは非常に有用かつ便利なWAFサービスですが、単一のルールを設定しているだけでは効果を得られない場合があります。複数の防御の仕組みを組み合わせる手法を取る必要があります。

一つのルールで堅牢なセキュリティを実現できるわけではありません。
AWSマネージドルールの他に自分で設定するカスタムルール、サードパーティが提供するMarketplace
ルールなどを組み合わせて運用することで高い効果を発揮できます。

例えばAWSManagedRulesCommonRuleSetのようなルールは様々な要件下で効果を発揮できるため、まず導入を検討すべき基本的なベースラインとして位置づけられています。
このルールセットは、OWASP Top 10で言及されるような一般的なWebアプリケーションの脆弱性や、その他の不要なトラフィックから保護するためにAWSの脅威リサーチチームによって管理されています 。
ほとんどのWeb ACLにおいてこのルールを有効にすることがベストプラクティスとされています 。

その次に、アプリケーションの要件に合わせたルールを選定していきます。
自分でルール内容を記載できるカスタムルールも選択肢に入ってくるかと思います。

そして最後に高度な分析を要し、リクエスト毎のコストが発生する可能性のあるルールを配置します。
これらのルールは、評価対象を特定のパス（例：/loginや/ftp）に限定し、コストとパフォーマンスへの
影響を最小限に抑える対応が必要です。
AWSManagedRulesBotControlRuleSet 、Account Takeover Prevention(ログインページを標的とした不正アクセスの遮断)等のルールセットが該当します。

このようにマネージドルールと自ら作成するカスタムルール、状況に応じてMarketplaceルールを組み合わせて使用していくことが重要です。

継続的な監視の重要性

WAFは「導入して終わり」のツールではありません。その効果を最大限に引き出すためには、導入後の運用が非常に重要です。WAFは、通過した通信のすべてをログとして記録しています。このログを定期的に監視・分析することで、改善点が明らかになります。

ログの監視
(1)  作成したWAFを選択し、Logging and metrics を選択します。

(2)  Enable をクリックし、Logging destination を選択します。
今回はCloudWatch Logsを選択し、Create New をクリックします。

(3)  CloudWatchのロググループ作成画面に遷移します。この画面で
・ロググループ名称
・ログの保持期間
・ログクラス
の3点を設定していきます。

今回は検証用途のためログの保持期間を1日、ログクラスをスタンダードで
作成していきます。

※注意!!
AWS WAFのログをCloudWatch Logsに送信するには、ロググループ名が特定のプレフィックスで始まる必要があります。
Web ACLからログを送信するためには、ロググループ名が「aws-waf-logs-」 で始まる必要があります。
このプレフィックスを誤ると、WAFはロググループを認識できず、ログの送信が失敗してしまいます。

(4)  ロググループの作成が完了するとWAF設定画面に作成したロググループが
表示されるようになります。対象のロググループを選択し、Redacted fields設定に移ります。

Redacted fieldsの設定について
WAFログは、Webトラフィックに関する詳細な情報（ヘッダー、リクエストURIなど）を記録します。この情報の中に、以下のような機密データが含まれる可能性があります。

・認証情報: Authorization ヘッダー
・クッキー: ユーザーセッション情報
・フォームデータ: POSTリクエストのボディに含まれるパスワードや個人情報

Redacted fields項目を設定することで、これらのフィールドの値をログに記録する前に、自動的に REDACTED のようなプレースホルダー文字列に置き換えることができます。
こちらも今回は未設定のままにします。

(5)  画面下部のSaveをクリックし、ロギングを有効化することができます。

 

EX：「Firewall as Code」による自動化と一貫性の確保

少し発展的な内容になりますがAWS WAFの設定はAWS CloudFormation、Terraform、AWS CDKといったIaC ツールを用いてコードとして管理することができます。コード化によって

・変更内容の可視性とトレーサビリティの向上
・Gitなどのバージョン管理システムを用いた設定の変更履歴の管理
・複数の環境に対して、一貫性のあるWAFポリシーを自動でデプロイ

などのメリットを得ることができます。

今回のまとめ

AWS WAFは手軽にWebアプリケーションを保護できる便利なサービスであり、
様々なシナリオに対応できる豊富なルールグループが特徴ですが、使い方を誤ると思った通りの効果を得られないどころか正常なサービスまで阻害してしまう可能性があります。導入の際は通信への影響、それによって起きる業務への影響を十分に考慮して検討するようにしましょう。

私も今回初めてAWS WAFに触れてみて、「奥が深い！難しい！」と感じました。しかし、

「奥が深い」＝「面白い」であると考えています（個人の感想です）。少しづつでもこの奥深いサービスのことを理解していって、適切にサービスを保護できるようになりたいと思います。