AWS WAFのBot Controlについて

AWS WAF Bot Controlは、AWS WAFで利用できるボット対策用のマネージドルールグループです。

Webサイトやアプリケーションにアクセスしてくるボットを検出・分類し、必要に応じて監視、ブロック、レート制限、CAPTCHA、Challengeなどの対策につなげるために使います。

ボットには、悪質なものだけでなく、検索エンジンのクローラー、SNSのリンクプレビュー、監視サービス、外部サービスの確認用アクセスなど、サイト運営上必要なものも含まれます。

そのため、Bot Controlは「ボットをすべて止める機能」ではありません。

必要なボットは通し、不要なボットや悪質な自動アクセスを適切に制御するための仕組みです。

たとえば、正規のクローラーやリンクプレビュー用のアクセスは、サイト運営に必要な場合があります。

一方で、商品情報を大量取得するスクレイピングボット、ログインフォームを繰り返し叩くボット、脆弱性スキャンを行うボット、プログラムから機械的にアクセスするボットなどは、制限やブロックの対象になります。

AWS WAF Bot Controlでできること

Bot Controlでは、リクエストに含まれる情報をもとにボットの種類を判定し、AWS WAF上で制御に使えるラベルを付与します。

このラベルを活用することで、単純にアクセスを遮断するだけでなく、ボットの種類や挙動に応じて柔軟に対策できます。

クローラー系ボットの識別

Bot Controlでは、検索サービスなどがページを巡回するためのクローラーを識別できます。

このようなボットは、サイトの情報を取得するために必要な場合があります。

そのため、単純にブロックするのではなく、正規のボットかどうかを確認したうえで扱いを決めることが重要です。

特に、User-Agentだけを見て判断すると、正規のボットを装った偽装アクセスを見逃す可能性があります。

Bot Controlでは、検証済みかどうかを示すラベルを活用し、正規のアクセスと偽装アクセスを分けて扱えます。

スクレイピングボットの検出

スクレイピングボットは、商品情報、価格情報、在庫情報、記事、求人情報、不動産情報などを大量に取得する自動アクセスです。

大量のスクレイピングが発生すると、サーバー負荷の増加、コンテンツの無断利用、データの不正収集、競合による監視などにつながる可能性があります。

Bot Controlを使うことで、スクレイピングフレームワーク由来のアクセスや、機械的な取得が疑われるリクエストを検出し、ブロックやレート制限などの対策につなげられます。

HTTPライブラリ系アクセスの判定

Bot Controlでは、Python requests、curl、Go-http-clientなど、ブラウザではなくプログラムやライブラリから送信されるアクセスを検出できます。

このようなアクセスは、不正な自動アクセスである場合もありますが、正規のAPIクライアント、社内ツール、外部連携、監視ツールで使われている可能性もあります。

そのため、HTTPライブラリ系のアクセスをすべてブロックするのは危険です。

API仕様、認証方式、アクセス元、リクエスト先のパスなどを確認したうえで、制限する範囲を決める必要があります。

監視ツールや外部サービスの識別

外形監視サービス、稼働確認ツール、パフォーマンス監視ツール、外部連携サービスなども、ボットとして検出される場合があります。

これらはサイトやシステムの安定運用に必要なアクセスであることが多いため、誤ってブロックすると監視エラーや連携障害につながる可能性があります。

Bot Controlを導入する際は、業務上必要な自動アクセスを事前に整理しておくことが重要です。

SNS・リンクプレビュー系ボットの識別

SNSやチャットツールでURLを共有した際に、タイトル、説明文、画像などを取得するためのボットがアクセスすることがあります。

これらを誤ってブロックすると、リンクを共有したときにプレビューが正常に表示されない可能性があります。

そのため、SNSやチャットツールのリンクプレビューに関係するボットは、不要な自動アクセスとは分けて扱う必要があります。

セキュリティスキャン系ボットの検出

Bot Controlでは、脆弱性スキャンやセキュリティ監査を目的としたボットを検出できます。

自社で契約している診断サービスや監査ツールであれば許可が必要ですが、見知らぬアクセス元からのスキャンは攻撃準備の一部である可能性もあります。

このようなアクセスは、ブロック、レート制限、Challengeなどの対象になります。

AI関連ボットの検出

Bot Controlでは、AI関連のボットを検出できるカテゴリも用意されています。

AI関連ボットは、公開コンテンツを収集する目的でアクセスする場合があります。

これを許可するか制限するかは、サイトの方針によって判断が分かれます。

たとえば、公開情報は許可し、会員限定ページ、価格情報、在庫情報、独自データ、管理画面、APIなどは制限するという考え方もあります。

AI関連ボットは他のカテゴリと挙動が異なる場合があるため、デフォルトのアクションやラベルの扱いを確認したうえで設計することが重要です。

Bot Controlの2つの保護レベル

AWS WAF Bot Controlには、大きく分けて「Common」と「Targeted」の2つの保護レベルがあります。

それぞれ検出できる範囲や対策の強度が異なるため、目的に応じて使い分ける必要があります。

Common protection level

Common protection levelは、基本的なボット検出・分類を行う保護レベルです。

自己識別するボット、既知のボット、クローラー、スクレイピングフレームワーク、HTTPライブラリ、SNS関連ボット、セキュリティスキャン系ボットなどを分類し、ラベルを付与します。

初めてBot Controlを導入する場合は、まずCommonから始めるのが一般的です。

Commonだけでも、明らかな自動アクセスや不要なボットの可視化に役立ちます。

Commonを使うことで、どのような種類のボットが、どのパスに、どの程度アクセスしているのかを把握できます。

Targeted protection level

Targeted protection levelは、Commonより高度なボット対策を行う保護レベルです。

通常のUser-Agentや単純なシグネチャだけでは見分けにくい、より高度なボットを検出するために使います。

たとえば、人間のブラウザのように振る舞うスクレイピングボット、ログインフォームを狙う自動化ツール、検索機能や商品ページを継続的に取得する高度なクローラーなどが対象になります。

Targetedでは、ブラウザ検査、フィンガープリンティング、行動ヒューリスティック、機械学習分析などが関係します。

また、多くの保護機能を有効に活用するには、AWS WAF JavaScript SDKやモバイルSDK、またはChallengeやCAPTCHAによるトークン設計が重要になります。

そのため、Targetedは全ページに一律で適用するより、ログイン、会員登録、検索機能、商品詳細、API、問い合わせフォームなど、被害が発生しやすい箇所に絞って導入するのが現実的です。

Bot Controlのラベルとは

Bot Controlの重要な特徴は、検出したボットに対してラベルを付与することです。

ラベルとは、AWS WAFがリクエストに対して付ける分類情報です。

たとえば、クローラー系、スクレイピングフレームワーク、HTTPライブラリ、AI関連ボット、検証済みボットなどを示すラベルがあります。

このラベルを使うことで、Bot Controlの判定結果をもとに、後続のAWS WAFルールで細かく制御できます。

ラベルを使うメリット

ラベルを使うと、ボットの種類に応じて異なる対応を設定できます。

たとえば、検証済みのクローラーは許可し、同じ種類を名乗っていても検証されていないものはブロックする、といった制御が可能です。

また、スクレイピングフレームワーク由来のアクセスはブロックし、HTTPライブラリ系のアクセスはAPIに限定して許可する、といった設計もできます。

Bot Controlは、単に「ボットらしきものを止める」ためだけの機能ではありません。

ラベルを活用することで、サイトの運用方針に合わせた細かな制御が可能になります。

ラベルを使った制御例

検証済みのクローラーは許可する。

クローラーを名乗っているが検証済みではないアクセスはブロックする。

スクレイピングフレームワーク由来のアクセスはブロックする。

HTTPライブラリ系のアクセスは、API以外では制限する。

監視ツールや外部連携サービスは、必要なものだけ許可する。

SNSやチャットツールのリンクプレビュー用アクセスは許可する。

AI関連ボットは、サイト方針に応じて許可、制限、ブロック、監視のいずれかを選ぶ。

このように、ラベルはBot Controlを実務で使いこなすうえで重要な要素です。

検証済みボットの扱い

Bot Controlでは、単にUser-Agentだけを見てボットを判断するのではなく、正規のボットかどうかを確認する仕組みがあります。

たとえば、あるクローラーを名乗るアクセスがあったとしても、それが本当に正規のクローラーとは限りません。

攻撃者やスクレイパーがUser-Agentを偽装している可能性があります。

Bot Controlでは、正規のボットとして確認できたリクエストに対して、検証済みであることを示すラベルを付与します。

これにより、正規のボットと偽装アクセスを分けて扱えるようになります。

正規のボットは許可する

正規のクローラー、外部サービス、監視ツール、リンクプレビュー用ボットなどは、サイト運営上必要な場合があります。

これらを誤ってブロックすると、情報取得、監視、外部連携、表示確認などに影響が出る可能性があります。

そのため、検証済みであり、業務上必要なボットは許可する設計が重要です。

偽装ボットは制限する

正規のボットを名乗っていても、検証済みでないアクセスは偽装の可能性があります。

このようなアクセスは、ブロック、Challenge、レート制限などの対象になります。

特に、User-Agentだけを信頼して許可する設定は避けるべきです。

User-Agentは簡単に変更できるため、偽装アクセスの判断には不十分です。

AI関連ボットは例外に注意する

多くのカテゴリでは、検証済みボットはブロック対象になりにくい設計になっています。

しかし、AI関連カテゴリについては注意が必要です。

検証済みかどうかに関係なくマッチする場合があり、デフォルトでブロック動作を持つことがあります。

そのため、AI関連ボットを許可したい場合や、一部だけ制限したい場合は、ルールアクションの上書き、ラベルベースの制御、対象パスの絞り込みなどを慎重に設計する必要があります。

Bot Control導入時の基本方針

Bot Controlを導入する際は、いきなりブロックから始めるのではなく、段階的に進めるのが安全です。

必要な自動アクセスまで誤って止めてしまうと、監視、外部連携、リンクプレビュー、API通信、業務システムなどに影響が出る可能性があります。

まずはCountで可視化する

最初はBot ControlをCountで導入し、どのようなボットがサイトにアクセスしているかを確認します。

Countにすることで、リクエストをブロックせずに、Bot Controlがどのような判定をしているかをログやメトリクスで確認できます。

導入直後からBlockにすると、必要なボットや正規の自動アクセスまで遮断してしまうリスクがあります。

確認すべき項目

Countで運用している間は、以下のような項目を確認します。

ボットカテゴリ。

検証済みかどうか。

アクセス先のURI。

User-Agent。

IPアドレス。

アクセス元の国や地域。

アクセス頻度。

対象ページ。

APIへのアクセス状況。

ログインやフォームへのアクセス傾向。

エラーの発生状況。

この段階で、正規のアクセス、業務上必要なアクセス、不要なアクセス、悪質な可能性があるアクセスを分類します。

許可すべきアクセスを整理する

次に、ブロックしてはいけないアクセスを明確にします。

代表的には、正規のクローラー、SNSやチャットツールのリンクプレビュー、広告プラットフォームの確認用アクセス、自社監視ツール、外部連携サービス、決済関連の通知、業務システム連携などです。

これらを誤ってブロックすると、サイト運営や業務処理に影響が出る可能性があります。

不要なアクセスを段階的に制限する

許可すべきアクセスを整理したら、不要なボットに対して制限をかけます。

たとえば、スクレイピングフレームワーク、脆弱性スキャン、過剰な自動巡回、不審なHTTPライブラリ系アクセス、ログインフォームへの大量アクセスなどは、ブロックやChallenge、レート制限の対象になります。

ただし、ブロック前には必ずログを確認し、正規の業務通信が含まれていないかを確認することが重要です。

Scope-down statementの重要性

Bot Controlは便利ですが、すべてのリクエストに適用するとコストが増えやすくなります。

そのため、Scope-down statementを使って、Bot Controlの評価対象を絞ることが重要です。

Scope-down statementとは、特定の条件に一致するリクエストだけをマネージドルールグループの評価対象にするための条件設定です。

Scope-downを使う理由

Scope-downを使う理由は、大きく2つあります。

1つ目は、コスト削減です。Bot Controlは評価対象となるリクエスト数に応じて追加料金が発生するため、不要なリクエストまで検査すると費用が増えます。

2つ目は、誤検知リスクの低減です。静的ファイルや画像、CSS、JavaScriptなど、ボット対策の優先度が低いリクエストまで厳しく検査すると、不要な判定や運用負荷が増える可能性があります。

Scope-downの対象例

Bot Controlを適用する対象としては、以下のようなパスが候補になります。

ログインページ。

会員登録ページ。

問い合わせフォーム。

検索機能。

商品詳細ページ。

価格情報ページ。

在庫情報ページ。

APIエンドポイント。

管理画面。

WordPressのログインページ。

一方で、画像、CSS、JavaScript、フォントファイルなどの静的アセットは、Bot Controlの対象から外してもよいケースが多いです。

全ページ適用を避けるべき理由

Bot Controlを全ページに適用すると、コストが増えるだけでなく、必要な自動アクセスまで判定対象に含まれやすくなります。

特にアクセス数が多いサイトでは、静的アセットや低リスクページまで検査対象にすると、費用対効果が悪くなる場合があります。

そのため、まずは被害が出やすいパスや、保護したい機能に絞って適用するのが現実的です。

料金面での注意点

Bot Controlは、通常のAWS WAF料金に加えて追加料金が発生します。

料金は、Web ACLの数、ルール数、処理するリクエスト数、CommonかTargetedか、CAPTCHAやChallengeの使用状況、Scope-downの有無などによって変わります。

CommonとTargetedでは料金インパクトが異なる

Commonは基本的なボット分類を行う保護レベルで、比較的導入しやすい構成です。

一方、Targetedは高度な検出機能を含むため、費用が大きくなりやすい傾向があります。

そのため、Targetedを全ページに適用するのではなく、ログイン、フォーム、検索機能、商品ページ、APIなど、被害が発生しやすい箇所に限定するのが実務上は安全です。

コストを抑える考え方

Bot Controlのコストを抑えるには、いきなり全ページに適用しないことが重要です。

まずはCommonで状況を可視化し、ボットアクセスが多い箇所や保護優先度の高い箇所を確認します。

そのうえで、Scope-down statementを使って対象パスを絞り、Targetedが必要な箇所だけに適用します。

また、定期的にログを確認し、不要な評価対象が増えていないかを見直すことも大切です。

運用上の注意点

Bot Controlはセキュリティ対策として有効ですが、設定を誤ると正常なアクセスや業務上必要な自動アクセスを止めてしまう可能性があります。

そのため、技術的な防御だけでなく、サイト運用や外部サービス連携への影響も含めて設計する必要があります。

正規のクローラーを止めない

正規のクローラーは、サイトの情報を取得するために必要な場合があります。

これらを誤ってブロックすると、外部サービス側で情報が取得できなくなる可能性があります。

そのため、クローラーを名乗るアクセスをすべて許可するのではなく、検証済みのものだけを許可し、偽装アクセスは制限する設計が重要です。

リンクプレビュー用ボットを止めない

SNSやチャットツールでURLを共有したとき、リンクプレビューを生成するためのボットがアクセスすることがあります。

これらをブロックすると、タイトル、説明文、画像などが正しく表示されない場合があります。

共有機能を重視するサイトでは、リンクプレビュー系のアクセスを誤ってブロックしないように注意が必要です。

広告プラットフォームの確認用アクセスに注意する

広告配信サービスを利用している場合、広告プラットフォーム側がリンク先ページや設定内容を確認するためにアクセスすることがあります。

このような確認用アクセスを誤ってブロックすると、審査や配信に影響が出る可能性があります。

広告運用を行っているサイトでは、広告関連の確認アクセスがWAFで止まっていないかを確認する必要があります。

外部連携や監視ツールに注意する

自社で利用している監視ツール、外部API連携、決済通知、業務システム連携なども、Bot Controlでボットとして判定される場合があります。

これらは正常な運用に必要なアクセスであるため、導入前に洗い出しておくことが重要です。

必要に応じて、IPアドレス、認証情報、パス、ヘッダー、ラベルなどを条件に許可ルールを設計します。

AI関連ボットはサイト方針で判断する

AI関連ボットを許可するか制限するかは、サイトの目的によって判断が分かれます。

公開情報であれば許可してもよい場合がありますが、会員限定情報、価格情報、在庫情報、独自データ、管理画面、APIなどは制限すべきケースが多くあります。

すべてを一律で許可またはブロックするのではなく、コンテンツの種類やリスクに応じて方針を分けると運用しやすくなります。

よくある失敗

Bot Controlは強力な機能ですが、設定を誤ると正常なアクセスや重要な自動アクセスを止めてしまう可能性があります。

ここでは、導入時によくある失敗を整理します。

いきなりBlockで本番投入する

最も避けたいのが、導入直後からBlockで運用することです。

Bot Controlの判定自体が正しくても、サイト側にとって必要なボットや外部サービスのアクセスまで止めてしまう可能性があります。

まずはCountで可視化し、ログを見てから段階的にBlockやChallengeへ移行するのが安全です。

Targetedを全URLに適用する

Targetedは高度な保護を提供しますが、コストや利用者体験への影響も大きくなりやすいです。

すべてのURLに適用するのではなく、ログイン、会員登録、検索機能、商品ページ、フォーム、APIなど、被害が発生しやすい箇所に絞るべきです。

クローラー系カテゴリをまとめてブロックする

クローラー系のアクセスを単純にまとめてブロックすると、正規のアクセスまで止める可能性があります。

クローラー系のボットは、カテゴリだけでなく、検証済みかどうかを組み合わせて判断する必要があります。

HTTPライブラリをすべてブロックする

HTTPライブラリ由来のアクセスは、不正なボットである場合もありますが、正規のAPI利用や社内ツールである可能性もあります。

APIや外部連携を提供しているサイトでは、HTTPライブラリ系アクセスを一律ブロックすると、正規機能が止まる恐れがあります。

AI関連カテゴリの扱いを確認しない

AI関連カテゴリは、他のカテゴリと挙動が異なる場合があります。

AI関連ボットを許可したい、または一部だけ制限したい場合は、デフォルトのルールアクション、検証済みボットの扱い、ラベルベースの制御を必ず確認する必要があります。

おすすめの導入手順

AWS WAF Bot Controlを安全に導入するなら、段階的に設定していくことが重要です。

最初から厳しい制御を入れるのではなく、現状把握、必要なアクセスの整理、不要なアクセスの制限という順番で進めると、誤ブロックのリスクを抑えられます。

WAFログを有効化する

まずはAWS WAFのログを有効化します。

ログがなければ、どのルールがどのリクエストにマッチしたのか、どのボットがどのページにアクセスしているのかを確認できません。

Bot Controlは導入後の調整が重要なため、ログ分析できる状態を先に作ることが大切です。

CommonをCountで導入する

最初はCommon protection levelをCountで導入します。

この段階ではブロックせず、どのようなボットが来ているかを観察します。

特に、クローラー、リンクプレビュー、監視ツール、HTTPライブラリ、スクレイピングフレームワーク、AI関連ボット、セキュリティスキャン系のアクセスを確認します。

必要なアクセスを許可する

ログを確認したら、ブロックしてはいけないアクセスを整理します。

正規のクローラー、SNSやチャットツールのリンクプレビュー、広告プラットフォームの確認用アクセス、自社監視、外部連携、決済関連、業務APIなどは、事前に許可方針を決めておきます。

不要なボットを制限する

次に、不要なボットに対して制限をかけます。

スクレイピングフレームワーク、過剰な自動巡回、脆弱性スキャン、偽装クローラー、不審なHTTPライブラリ系アクセスなどは、ブロック、Challenge、レート制限の候補になります。

Targetedを高リスク箇所に限定して使う

Commonだけでは不十分な場合、Targetedを検討します。

ただし、Targetedはコストや実装面の考慮が必要です。

特に、JavaScript SDKやモバイルSDK、Challenge/CAPTCHAによるトークン設計が重要になります。

Targetedは、ログイン、会員登録、検索機能、商品詳細、問い合わせフォーム、APIなどに絞って適用するのが現実的です。

定期的にログを見直す

ボットの挙動は変化します。

一度設定して終わりではなく、定期的にWAFログやCloudWatchメトリクスを確認し、必要に応じてルールを調整します。

外部サービス、広告プラットフォーム、監視ツール、AI関連ボットなどの仕様は変わることがあるため、必要なアクセスが止まっていないかを継続的に確認することが大切です。

実務でのおすすめ構成

多くのWebサイトでは、Bot Controlをいきなり強く適用するのではなく、段階的に導入する構成が現実的です。

特に、業務上必要な自動アクセスや外部サービス連携がある場合は、Countでの確認とログ分析を前提に進めるべきです。

基本構成

まずAWS WAFログを有効化します。

次に、Bot Control CommonをCountで導入します。

その後、正規のクローラー、リンクプレビュー、外部連携、監視ツールなど、必要なアクセスを確認します。

明らかに不要なボットから段階的に制限します。

さらに、Scope-down statementで対象パスを絞ります。

必要に応じて、Targetedを高リスク箇所に限定して導入します。

ECサイトの場合

ECサイトでは、商品ページ、検索機能、価格情報、在庫情報、ログイン、カート、決済周辺が重要です。

特に、価格スクレイピング、在庫監視、転売目的の自動アクセス、ログイン試行、クーポン悪用などに注意が必要です。

商品ページや検索機能ではスクレイピング対策を強化し、ログインや会員登録ではTargeted、Challenge、レート制限を組み合わせるとよいでしょう。

ただし、決済周辺は誤検知が売上に直結するため、最初はCountで慎重に検証する必要があります。

メディアサイトの場合

メディアサイトでは、記事コンテンツのスクレイピング、AI関連ボット、正規クローラー、リンクプレビュー系アクセスの扱いが重要です。

必要なクローラーやリンクプレビューを誤ってブロックすると、外部サービス上での表示や情報取得に影響が出る可能性があります。

一方で、記事本文を大量取得するスクレイピングボットやAI関連ボットについては、コンテンツ方針に応じて制限を検討します。

BtoBサイトの場合

BtoBサイトでは、問い合わせフォーム、資料請求フォーム、ログイン、API、ホワイトペーパーのダウンロードなどが保護対象になります。

フォームスパムや不正な自動送信が多い場合は、Bot Controlに加えて、レート制限、CAPTCHA、Challengeを組み合わせると効果的です。

広告配信サービスを利用している場合は、広告プラットフォームの確認用アクセスや計測関連アクセスを止めないように注意が必要です。

まとめ

AWS WAF Bot Controlは、Webサイトやアプリケーションにアクセスするボットを検出・分類し、適切な制御につなげるための機能です。

Common protection levelでは、クローラー、SNSやチャットツールのリンクプレビュー、HTTPライブラリ、スクレイピングフレームワーク、監視ツール、セキュリティスキャン系ボットなどの基本的なボットを分類できます。

Targeted protection levelでは、より高度で自己識別しないボットに対して、ブラウザ検査や行動分析を含む対策を行えます。

実務では、いきなりブロックするのではなく、まずCountで可視化し、WAFログを見ながら必要なアクセスと不要なアクセスを整理することが重要です。

また、Bot Controlは追加料金が発生するため、Scope-down statementを使ってログイン、会員登録、検索機能、商品ページ、問い合わせフォーム、APIなどの高リスク箇所に絞ることがコスト最適化につながります。

AWS WAF Bot Controlは、単なるアクセス遮断の仕組みではありません。

必要な自動アクセスを維持しながら、不要なボットや悪質な自動アクセスを抑えるためのボット制御基盤として活用することが重要です。

以上、AWS WAFのBot Controlについてでした。

最後までお読みいただき、ありがとうございました。