AWS WAF Bot Control のチューニングと最適化

awswaf:managed:aws:bot-control:bot:category:search_engine
awswaf:managed:aws:bot-control:bot:name:scrapy
awswaf:managed:aws:bot-control:bot:verified
awswaf:managed:aws:bot-control:signal:non_browser_user_agent

Bot Control を始めるためのベストプラクティス

Bot Control を有効にして、デフォルトの Block アクションでウェブリソースの保護を開始できますが、最初にルールグループのすべてのルールを Count アクションに切り替えることができます。これにより、次のことが実現されます。

ラベルは Amazon CloudWatch メトリクスや AWS WAF ログから確認でき、そこからすぐに、特定のシナリオに対応するための例外やカスタムルールの必要性について計画することができます。この投稿では、「典型的なユースケース」のセクションで、それらを検討します。

さらに、AWS WAF はルールを順番に処理するため、Bot Control のルールグループが Web ACL のどこに位置しているかを考慮する必要があります。不要と確信できるリクエストをフィルタするために、評価順序で Bot Control ルールグループの前に、Amazon IP Reputation List などの AWS Managed Rules ルールグループを配置することができます。これにより、Bot Control が処理するリクエスト数が減少し、費用対効果が高まります。同時に、次の要件がある場合には、Bot Control は早い段階のルールで評価されるよう配置すべきでしょう。

AWS WAF Bot Control のチューニングは、最近リリースされたAWS WAF の一連の機能なしには、完備かつ設定可能とは言えません。それらを紐解いてみましょう。

CloudWatch メトリクスと AWS WAF ログにおけるラベルの動作

生成されたラベルは CloudWatch のメトリクスを生成し、 AWS WAF のログに記録されます。これにより、ウェブサイトにヒットしたボットやカテゴリ、それに関連するラベルを確認でき、チューニングに利用することができます。

CloudWatch メトリクスは以下のようなディメンジョンとメトリクスで生成されます。

AWS WAF は Overview ページのトップに、図 1 のように関連する CloudWatch メトリクスへのショートカットがあります。

または、CloudWatch メトリクスの WAFV2 サービスカテゴリで確認することができます。

CloudWatch は、生成されたラベル、日時ごとのボリュームをメトリクスとして取得できるため、評価の上、ルールの構成や誤検出への対処について、情報に基づいた判断を下すことができます。図 2 は、私のウェブサイトへのボットからのリクエストに対して、生成されたラベルを示しています。この例では、明示的な Allow アクションをいくつか設定しただけなので、ほとんどがブロックされました。図 2 の上段には、選択された2つのラベルのメトリクスを示しています。

AWS WAF ログでは、ラベルは labels フィールドの配列として記録されます。図 3 に、labels 配列を含むリクエストの例を示します。

この例では、同じリクエストに対して 3 つのラベルが生成されています。uptimerobot は monitoring カテゴリラベルに従います。この 2 つのラベルを組み合わせることは、それらに基づく設定に柔軟性を持たせるのに有効です。カテゴリ全体を使うこともできますし、特定のボットのラベルを使ってフォーカスすることもできます。この投稿の後半で、このことがどのように、そしてなぜ重要であるかを説明します。3つ目のラベル、non_browser_user_agent は、通常とは異なるヘッダを持ったリクエストのシグナルです。ラベルと組み合わせてボットから保護するために、特定のリクエストに対してアプリケーションで特別なスキャンを構築できます。

スコープダウンステートメントとは

Bot Control はプレミアム機能であり、有料の AWS Managed Rules であることを考えれば、コストを抑えられるかどうかは非常に重要です。スコープダウンステートメントでは、Bot Control による検査を必要としないトラフィックをフィルタすることで、コストを最適化できます。

このゴールのために、2 つの大まかなシナリオで、スコープダウンステートメントを使用できます。

リソースの特定の部分を Bot Contorl によるスキャンから除外することができます。ウェブサイトのうち、ボットにアクセスされても構わない箇所を考えてみましょう。一般的には、画像や CSS ファイルなどの静的コンテンツがこれにあたります。それ以外の API やログインページなどの部分には保護を残します。また、安全と思われる IP レンジを除外することもできます。例えば、自社組織から発信されていることが分かっているトラフィックや、パートナーや顧客等の閲覧者です。

また、視点を変えて、リソースのごく一部にのみボット管理を適用することも可能です。例えば、ログインページや機密性の高い API を Bot Control で保護し、それ以外は対象外にできます。

これらを駆使して、ユースケースとシナリオを掘り下げてみましょう。

AWS WAF Bot Control のチューニングの典型的なユースケース

Bot Control を、よりニーズに合うようチューニングする方法はいくつかあります。このセクションでは、使用できるいくつかの方法を紹介します。

クロールレートの制限

場合によっては、ウェブサイトへのボットのアクセスを許可する必要があります。例えば、検索エンジンのボットは、ウェブサイトをクロールしてインデックスを作成します。検索エンジンの最適化がビジネスにとって重要である一方、ウェブリソースへのリクエストが多すぎて負荷がかかりすぎている場合、必要以上にブロックすることなくクローラーの速度を下げる方法についてジレンマに直面することがあります。Bot Control の検知ロジックと、レスポンスのステータスコードやヘッダでクローラーに意図を伝えるレートベースルールを組み合わせることで、これを解決できます。有用と判断されるほとんどのクローラーは、負荷の増加を検知した際に、クロールレートを低下させるメカニズムを持っています。

ウェブリソースに悪影響を及ぼす可能性のある制限値以下にクロールレートを設定する

この設定により、Bot Control は必要なラベルを設定し、それをレートベースルールのスコープダウンステートメントで使用することで、特定のボットからのリクエスト数の上限を設定するだけでなく、ボットのクロールレートが高すぎるときにはボットに伝達することができます。ボットがそのレスポンスを尊重し、レートを下げない場合、ルールが一時的にボットをブロックし、ウェブリソースを過負荷から保護します。

注意: scraping_framework のようなカテゴリラベルを使用すると、そのラベルを持つすべてのボットがレートベースのルールでカウントされます。同じラベルを使用するボットの意図しないブロックを避けるには、正確な bot:name: ラベルで特定のボットに絞り込むか、Rate limit を高くして余裕を持たせるかのどちらかを選択します。

Bot Control  をアプリケーションの一部にだけ適用する

前述のとおり、ウェブリソースの一部を Bot Control の保護の対象から除外し、到達するリクエストのサブセットに焦点をあてることで、実行コストを削減できます。このアプローチを利用する一般的なシナリオがいくつかあります。

動的な部分へのトラフィックだけに  Bot Control を適用する

文字列マッチングを使用する代替案

文字列マッチングの Match type の代わりに、正規表現パターンセットを使用できます。もし正規表現パターンセットを作成していない場合は、以下のガイドに従って作成してください。

注意: このパターンは、典型的なウェブリソースの静的ファイルに関連付けられた、最も一般的なファイル拡張子にマッチします。異なるファイルがある場合には、パターンセットをカスタマイズできます。

アプリケーションの最も機密性の高い部分だけに Bot Control を適用する

アプリケーションの最も機密性の高い部分だけに Bot Control を有効にすることで、他のほとんどすべての部分を除外することもできます。例えばログインページなどです。

注意: 実際の URL path はアプリケーションの構造によって異なります。

アプリケーションの複数の箇所を Bot Control から除外する

複数の箇所を除外する場合、OR ステートメントを使用して、スコープダウンステートメント内で除外する箇所をリストアップできます。

図 9 は、先述の完全一致の例に OR ステートメントを追加して、payment という API を保護するようにしたものです。

注意: コンソール上でのビジュアルエディターでは、最大 5 個のステートメントをサポートしています。それ以上追加するには、コンソール上で JSON を編集するか、API を使用します。

ブロックしたくない検証済みボットに優先順位をつける

検証済みボットは、デフォルトではブロックされないため、ほとんどの場合はボットを通過させるために追加でロジックを適用する必要はありません。しかし、他の AWS WAF ルールが検証済みボットからのリクエストのいくつかの要素に一致し、ブロックしてしまうシナリオは起こりえます。それによって、 SEO のメトリクスにダメージを与えたり、リンクが伝播しソーシャルメディアに表示されるのを妨害したりすることがあります。もしそれがビジネスにとって重要であれば、AWS WAF で明示的に許可することによって、検証済みボットを確実に通過させたいと考えるかも知れません。

検証済みボットカテゴリを優先順位付けする

特定のボットを許可する

ラベルを使用することで、ブロックされたカテゴリの中から、ブロックしたくないボットを選び出すこともできます。代表的な例では、お客様のウェブリソースを監視するサードパーティボットがあります。

UptimeRobot を使って、特定のボットを許可するシナリオを見てみましょう。このボットは、 bot:category:monitoring で、デフォルトではブロックされるカテゴリに該当します。カテゴリ全体を除外することもできますが、リソースに必要以上に大きな影響を与える可能性があります。UptimeRobot だけを許可することもできます。

特定のボットを明示的に許可する

注意: この方法は、誤検知の状況を分析し、必要に応じて対処するためのベストプラクティスです。一意の bot:name: ラベルに基づき、任意の、または複数のボットを除外できます。

特定のボットからのリクエストにカスタムヘッダを挿入する

特定のリクエストをさらに処理・分析したい場合や、下流のシステムが提供するロジックを実装したい場合があります。このようなときに、AWS WAF Bot Control を使用すると、リクエストを分類できます。後工程のアプリケーションでは、カテゴリ内のすべてのような幅広い範囲、特定のボットのような狭い範囲のいずれにも、意図したロジックを適用できます。

カスタムヘッダを挿入する

Bot Control の後に配置されたカスタムルールによって、セキュリティカテゴリ内のボットからであるというラベルが付けられたすべてのリクエストに対してヘッダが挿入されるようになりました。さらに、AWS WAF の下流のセキュリティアプライアンスでは、ヘッダに基づいて都度処理が実行されます。

この実装は、別のシナリオにも対応できます。例えば、特定のコンテンツのキャッシュの利用を明示的に禁止するために、オリジンと通信するカスタムヘッダを使用できます。これにより、ボットは常にオリジンから取得します。挿入されたヘッダは、AWS Lambda@Edge や CloudFront Functions からアクセスでき、より高度なシナリオも実現できます。

まとめ

本記事では、Bot Control 活用のための主な構成要素と、様々なシナリオに対応するために、これらをどう組み合わせてカスタマイズできるのかを紹介しました。Bot Control のチューニングのユースケースを完全に網羅したわけではありませんが、ここで紹介した例が、他の実装の参考やアイデアにつながることを願っています。

すでにウェブリソースに AWS WAF を関連付けている場合、サービスに処理されているリクエストのサンプルに基づいて、アプリケーションのボットトラフィックの現在の推定値を表示できます。AWS WAF コンソールから、Bot overview dashboard を開いてみてください。この投稿から学んだことを実装し、ボット対策を改善するための良いスタート地点になるでしょう。

この機能はまだ初期段階にあり、今後も多くの機能を追加していきますので、ぜひご期待ください。

この投稿について質問がある場合は、AWS WAF re:Post のスレッドを立ち上げるか、AWS サポートにお問い合わせください。

AWS セキュリティに関するニュースをもっと知りたいですか？ツイッターでフォローしてください。

翻訳はソリューションアーキテクト 駒原 が担当しました。原文はこちらです。