数年前の AWS Summit Sydney で、ある参加者から素晴らしい質問を受けました。彼女は、Amazon Web Services (AWS) 上のウェブ上のリソースをシンプルなボットから保護するために、コスト効率がよく、信頼性が高く、複雑すぎないソリューションを設計するのを手伝ってほしいと言いました。AWS WAF Bot Control のリリースにより、その質問にエレガントなソリューションで対応できるようになったので、私はこのときのことをよく覚えています。Bot Control の機能は、Web アプリケーションに対するトラフィックの 50% 以上を占める一般的で広範なボットのフィルタリングを開始するために、スイッチを入れるだけの問題になっているのです。
新機能 – AWS WAF Bot Control でウェブサイトの不要なトラフィックを削減 では、AWS WAF Bot Control とその機能の一部が紹介されています。この記事では、どこから始めればいいのか、どの要素を設定と保護のために使用すればよいかについて、知るべき情報をカバーしています。本記事では、密接に関連する機能を明らかにし、重要な考慮事項、ベストプラクティス、および一般的なユースケースのためのカスタマイズ方法について説明します。対象となるユースケースは以下の通りです。
ボット軽減機能の細かい設定に移る前に、このプロセスの構成要素を理解することが重要です。
ラベルは Bot Control 独自のものではありませんが、この機能を活用し、多くの設定でラベルをメインの入力として使用しています。ラベルは、ルールステートメントのマッチングに基づいて、リクエストに適用される文字列です。いわば、特定のリクエストに属するタグのようなものです。リクエストはルールステートメントによって処理された後、同じ Web ACL 内の後続のすべてのルールでラベルを取得し、同様のリクエストの識別に利用できます。ラベルを使用すると、特定の条件を満たすリクエストのグループに対処することができます。それは、同じ Web ACL 内の後続のルールが追加されたラベルにアクセスでき、それらに対してマッチングができるからです。
ラベルは、単なるルールマッチングの仕組みにとどまりません。ラベルはルールのアクションとは独立しており、 Block、 Allow、 Count のいずれに対しても追加することができます。これにより、 AWS WAF ログのレコードに対してラベルに基づくフィルタリングやクエリを構築し、高度な分析が可能になります。
ラベルは、コロンで区切られた、接頭辞、オプションの名前空間、名前で構成される文字列です。
例：prefix:[namespace:]name
接頭辞の prefix 部分は AWS WAF によって自動的に追加されます。
これらのラベルは、マネージドなボット検出ロジックによって追加され、 Bot Control はこれらを使って、以下のような処理を実行します。
既知のボットの分類: リクエストのユーザーエージェントを既知のボットと比較、分類し、お客様がカテゴリ別にブロックできるようにします。ボットは、スクレイパー、検索エンジン、ソーシャルメディアなどの機能別に分類されます。
ボットの確認: ほとんどの正当なボットは、ユーザーエージェントを超える検証方法を提供しており、通常は IP アドレスの逆引き DNS によって、ドメイン名とホスト名の妥当性を検証します。これらの自動チェックは、正当なボットだけを許可し、下流のシステムにボット検出のフラグを立てるためのシグナルを提供するのに役立ちます。
ヘッダの検証: リクエストヘッダの検証では、ヘッダの欠落、不正なヘッダ、無効なヘッダを探すための一連のチェックを実行します。
ブラウザシグネチャーの照合: TLS ハンドシェイクのデータとリクエストヘッダを分解し、部分的に再結合することで、ブラウザと OS の組み合わせを識別するブラウザシグネチャを生成することができます。このシグネチャーは、ユーザーエージェントと一致していることを確認するために検証され、既知の良性・悪性のブラウザシグネチャーのリストと照合することができます。
以下に、Bot Control のラベルの例をいくつか示します。DescribeManagedRuleGroup API を使用して、すべてのリストを取得できます。
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 アクションに切り替えることができます。これにより、次のことが実現されます。
- Bot Control のルールの1つにマッチしても、リソースに対する正当なボットである可能性があるリクエストが誤検出されるのを回避します。
- リクエストの一部が Bot Control のルールにマッチした際に、ラベルとリクエストへのアクションという形で、十分なデータポイントを蓄積できます。これにより、ボットやカテゴリごとにルールを構築し、いつデフォルトのアクションに切り替えるべきかについて、十分な情報を得た上で判断できます。
ラベルは Amazon CloudWatch メトリクスや AWS WAF ログから確認でき、そこからすぐに、特定のシナリオに対応するための例外やカスタムルールの必要性について計画することができます。この投稿では、「典型的なユースケース」のセクションで、それらを検討します。
さらに、AWS WAF はルールを順番に処理するため、Bot Control のルールグループが Web ACL のどこに位置しているかを考慮する必要があります。不要と確信できるリクエストをフィルタするために、評価順序で Bot Control ルールグループの前に、Amazon IP Reputation List などの AWS Managed Rules ルールグループを配置することができます。これにより、Bot Control が処理するリクエスト数が減少し、費用対効果が高まります。同時に、次の要件がある場合には、Bot Control は早い段階のルールで評価されるよう配置すべきでしょう。
- 後続のルールのためにラベルを生成したい。副次的な効果として、高い視認性ももたらします。
- Bot Control が評価する前に適切なボットをブロックしてしまう誤検出を減らしたい。
AWS WAF Bot Control のチューニングは、最近リリースされたAWS WAF の一連の機能なしには、完備かつ設定可能とは言えません。それらを紐解いてみましょう。
CloudWatch メトリクスと AWS WAF ログにおけるラベルの動作
生成されたラベルは CloudWatch のメトリクスを生成し、 AWS WAF のログに記録されます。これにより、ウェブサイトにヒットしたボットやカテゴリ、それに関連するラベルを確認でき、チューニングに利用することができます。
CloudWatch メトリクスは以下のようなディメンジョンとメトリクスで生成されます。
- Region ディメンジョンは、 Amazon CloudFront を除いて、すべてのリージョンで利用可能です。Web ACL が CloudFront に関連付けられている場合は北バージニアリージョンのメトリクスとなります。
- WebACL ディメンジョンは Web ACL の名前です。
- Namespace は接頭辞を含む、完全修飾の名前空間です。
- LabelValue はラベル名です。
- Action は最終的なアクションです。 (例えば、 Allow, Block, Count)
AWS WAF は Overview ページのトップに、図 1 のように関連する CloudWatch メトリクスへのショートカットがあります。
図 1: CloudWatch メトリクスへのショートカットを含む、チャートのタイトルと説明文
または、CloudWatch メトリクスの WAFV2 サービスカテゴリで確認することができます。
CloudWatch は、生成されたラベル、日時ごとのボリュームをメトリクスとして取得できるため、評価の上、ルールの構成や誤検出への対処について、情報に基づいた判断を下すことができます。図 2 は、私のウェブサイトへのボットからのリクエストに対して、生成されたラベルを示しています。この例では、明示的な Allow アクションをいくつか設定しただけなので、ほとんどがブロックされました。図 2 の上段には、選択された2つのラベルのメトリクスを示しています。
図 2: ラベルの WAFV2 CloudWatch メトリクス
AWS WAF ログでは、ラベルは labels フィールドの配列として記録されます。図 3 に、labels 配列を含むリクエストの例を示します。
図 3: AWS WAF ログレコードの例
この例では、同じリクエストに対して 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 の検知ロジックと、レスポンスのステータスコードやヘッダでクローラーに意図を伝えるレートベースルールを組み合わせることで、これを解決できます。有用と判断されるほとんどのクローラーは、負荷の増加を検知した際に、クロールレートを低下させるメカニズムを持っています。
ウェブリソースに悪影響を及ぼす可能性のある制限値以下にクロールレートを設定する
- AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。
- Rules タブを選択し、Add rules をクリックします。Add managed rule groups を選択し、以下のように設定します。
- AWS managed rule groups セクションで、Bot Control の Add to web ACL トグルを選択し、Web ACL で Bot Control を有効にします。これにより、Web ACL 内の評価プロセスで、後続のルールで使用できるラベルも取得できます。
- Add rule をクリックし、Save をクリックします。
- 同じ Web ACL で、Add rules をクリックし、Add my own rules and rule groups を選択します。
- Rule builder を使用し、以下のように設定します。
- 任意の名前を入力し、Rate-based rule を選択します。
- ルールに適用する Rate limit を入力します。例えば、500 などです。
注意: Rate limitは 5 分間に 1 つの IP アドレスから許可する最大リクエスト数です
- Only consider requests that match the criteria in a rule statement を選択し、ルールで評価されるリクエストの範囲を狭めるためにスコープダウンステートメントを有効にします。
- 対象のボットにフォーカスするために、Inspect メニューで Has a label を選択します。
- Match key フィールドに以下のラベルのいずれかを入力し、図 4 で示すように、検査済みボットやスクレイピングと判別されたボットなど、幅広いカテゴリに基づいて照合します。
awswaf:managed:aws:bot-control:bot:verified
awswaf:managed:aws:bot-control:bot:category:scraping_framework - または、ラベルで特定のボットに絞り込むこともできます。
awswaf:managed:aws:bot-control:bot:name:Googlebot
図 4: Match key を指定したラベルマッチルールステートメント
- Action セクションで以下のように設定します
- Custom response を選択し、Enable にチェックを入れます
- Response code に 429 を入力し、一定時間内に送信するリクエストが多すぎることをボットに伝えます。
- Add custom new header を選択し、Retry-After を Key に、指定する秒数を Value にそれぞれ入力します。この値は、ボットが新しいリクエストを送信するまでに何秒待つべきかを示します。
- Add rule をクリックします。
- このカスタムルールでラベルが使用できるよう、Web ACL 内の Bot Control ルールグループの後にルールを配置することが重要です。
- Set rule priority セクションで、新しいレートベースルールが既存の Bot Control rule set の下にあることを確認し、もしそうでなかった場合は、新しく作成したルールを選択して、後ろになるまで Move up か Move down を選択します。
- Save をクリックします。
図 5: カスタムレスポンスコードを含む AWS WAF ルールアクション
この設定により、Bot Control は必要なラベルを設定し、それをレートベースルールのスコープダウンステートメントで使用することで、特定のボットからのリクエスト数の上限を設定するだけでなく、ボットのクロールレートが高すぎるときにはボットに伝達することができます。ボットがそのレスポンスを尊重し、レートを下げない場合、ルールが一時的にボットをブロックし、ウェブリソースを過負荷から保護します。
注意: scraping_framework のようなカテゴリラベルを使用すると、そのラベルを持つすべてのボットがレートベースのルールでカウントされます。同じラベルを使用するボットの意図しないブロックを避けるには、正確な bot:name: ラベルで特定のボットに絞り込むか、Rate limit を高くして余裕を持たせるかのどちらかを選択します。
Bot Control をアプリケーションの一部にだけ適用する
前述のとおり、ウェブリソースの一部を Bot Control の保護の対象から除外し、到達するリクエストのサブセットに焦点をあてることで、実行コストを削減できます。このアプローチを利用する一般的なシナリオがいくつかあります。
動的な部分へのトラフィックだけに Bot Control を適用する
- AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。
- Rules タブを選択し、Add rules をクリックします。Add managed rule groups を選択し、以下のように設定します。
- AWS managed rule groups セクションで、Bot Control の Add to web ACL トグルを選択し、Web ACL で Bot Control を有効にします。
- Edit をクリックします
- Scope-down statement – optional で、Enable Scope-down statement にチェックを入れます。
- If a request で doesn’t match the statement (NOT) を選択します。
- Statement セクションで以下のように設定します。
- Inspect で URI path を選択します。
- Match type で Starts with string を選択します。
- リソースの構造によっては、URI 文字列全体 (images/ など) を String to match フィールドに入力できます。これにより、この文字列が Bot Control の評価から除外されます。
図 6: スコープダウンステートメントの前方一致による URI path の指定
- Save rule をクリックします。
文字列マッチングを使用する代替案
文字列マッチングの Match type の代わりに、正規表現パターンセットを使用できます。もし正規表現パターンセットを作成していない場合は、以下のガイドに従って作成してください。
注意: このパターンは、典型的なウェブリソースの静的ファイルに関連付けられた、最も一般的なファイル拡張子にマッチします。異なるファイルがある場合には、パターンセットをカスタマイズできます。
- 前項の手順 1-4 を行います。
- Statement セクションで以下のように設定します。
- Inspect で URI path を選択します。
- Match type で Matches pattern from regex pattern set を選択し、図 7 のように Regex pattern set に作成した正規表現パターンセットを選択します。
- Regex pattern set では、以下のパターンを入力します。
(?i)\.(jpe?g|gif|png|svg|ico|css|js|woff2?)$
図 7: URI path の一部に指定された正規表現パターンセットに基づいたマッチングを行うスコープダウンステートメント
アプリケーションの最も機密性の高い部分だけに Bot Control を適用する
アプリケーションの最も機密性の高い部分だけに Bot Control を有効にすることで、他のほとんどすべての部分を除外することもできます。例えばログインページなどです。
注意: 実際の URL path はアプリケーションの構造によって異なります。
- Scope-down statement 内の If a request で matches the statement を選択します。
- Statement セクションで以下のように設定します。
- Inspect で URI path を選択します。
- Match type で Contains string を選択します。
- String to match で、マッチさせる文字列を入力します。例えば、図 8 のような login などです。
- Save rule をクリックします。
図 8: URI path 内の文字列でマッチングを行うスコープダウンステートメント
アプリケーションの複数の箇所を Bot Control から除外する
複数の箇所を除外する場合、OR ステートメントを使用して、スコープダウンステートメント内で除外する箇所をリストアップできます。
- Scope-down statement 内の If a request で matches at least one of the statements (OR) を選択します。
- Statement 1 セクションで、以下のように設定します。
- Inspect で URI path を選択します。
- Match type で Contains string を選択します。
- String to match で、マッチさせる文字列を入力します。例えば、図 8 のような login などです。
- Statement 2 セクションで、以下のように設定します。
- Inspect で URI path を選択します。
- Match type で Starts with string を選択します。
- String to match で、マッチさせる文字列を入力します。例えば、 payment/ などです。
- Save rule をクリックします。
図 9 は、先述の完全一致の例に OR ステートメントを追加して、payment という API を保護するようにしたものです。
図 9: より高度なマッチングを実現するための OR ロジックによるスコープダウンステートメント
注意: コンソール上でのビジュアルエディターでは、最大 5 個のステートメントをサポートしています。それ以上追加するには、コンソール上で JSON を編集するか、API を使用します。
ブロックしたくない検証済みボットに優先順位をつける
検証済みボットは、デフォルトではブロックされないため、ほとんどの場合はボットを通過させるために追加でロジックを適用する必要はありません。しかし、他の AWS WAF ルールが検証済みボットからのリクエストのいくつかの要素に一致し、ブロックしてしまうシナリオは起こりえます。それによって、 SEO のメトリクスにダメージを与えたり、リンクが伝播しソーシャルメディアに表示されるのを妨害したりすることがあります。もしそれがビジネスにとって重要であれば、AWS WAF で明示的に許可することによって、検証済みボットを確実に通過させたいと考えるかも知れません。
検証済みボットカテゴリを優先順位付けする
- AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。次の手順では、Web ACL で Bot Control ルールグループがすでに有効になっていることを想定しています。
- Rules タブを選択し、Add rules をクリックします。Add my own rules and rule groups を選択します。
- Rule builder を使用し、以下のように設定します。
- Name にルール名を入力します。
- Inspect で Has a label を選択します。
- Match key フィールドに以下のラベルを入力し、検査済みボットが持つラベルを元に照合します。
awswaf:managed:aws:bot-control:bot:verified
- Action セクションで Allow を選択し、リクエストがマッチした際のアクションを確認します。
- Add rule をクリックします。このカスタムルールで bot:verified ラベルが使用できるよう、Web ACL 内の Bot Control ルールグループの後にルールを配置することが重要です。そのために、以下の手順に従います。
- Set rule priority セクションで、今作成したルールが既存の Bot Control rule set の直後にあることを確認し、もしそうでなかった場合は、新しく作成したルールを選択して、直後になるまで Move up か Move down を選択します。
- Save をクリックします。
図 10: Match key を指定しての Label match rule statement
特定のボットを許可する
ラベルを使用することで、ブロックされたカテゴリの中から、ブロックしたくないボットを選び出すこともできます。代表的な例では、お客様のウェブリソースを監視するサードパーティボットがあります。
UptimeRobot を使って、特定のボットを許可するシナリオを見てみましょう。このボットは、 bot:category:monitoring で、デフォルトではブロックされるカテゴリに該当します。カテゴリ全体を除外することもできますが、リソースに必要以上に大きな影響を与える可能性があります。UptimeRobot だけを許可することもできます。
特定のボットを明示的に許可する
- CloudWatch メトリクスや AWS WAF ログを分析し、ブロックされているボットと、それに関連付けられたラベルを見つけます。カテゴリ全体を許可するのでなければ、目的のボットを bot:name: ラベルから探します。例えば、以下は、 awswaf:managed:aws:bot-control:bot:name:uptimerobot というラベルに基づいています。
ログからは、ボットがどのカテゴリに属しているかを確認でき、スコープダウンステートメントを設定する際にこの情報が役立ちます。
- AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。次の手順では、Web ACL で Bot Control ルールグループがすでに有効になっていることを想定しています。
- Web ACL 内のリストにある Bot Control rule set を開き、Edit をクリックします。
- Rules のリストから CategoryMonitoring を見つけ、Count にセットします。これにより、デフォルトの Block アクションを防ぎます。
- Scope-down statement – optional で、Enable Scope-down statement にチェックを入れ、以下のように設定します。
- Scope-down statement の If a request で、matches all the statements (AND) を選択します。これにより、カテゴリをブロックするが、特定のボットは許可するといった複雑なロジックの構築が可能になります。
- Statement 1 セクションの Inspect で Has a label を選択します。
- Match key フィールドで、手順 4 でカウントに設定したカテゴリの大分類のラベルを入力します。この例では、monitoring となっています。この設定によって、カテゴリの他のボットはブロックされたままになります。
awswaf:managed:aws:bot-control:bot:category:monitoring
- Statement 2 セクションで、特定のボットを除外するために、Negate statement results を選択します。
- Inspect で、Has a label を選択します。
- Match key フィールドで、明示的に許可するボットを一意に識別するラベルを入力します。この例の、uptimerobot は次のようになります。
awswaf:managed:aws:bot-control:bot:name:uptimerobot
- Save rule をクリックします。
図 11: AND ロジックを用いてカテゴリから特定のボット名を抽出する Label match rule statement
注意: この方法は、誤検知の状況を分析し、必要に応じて対処するためのベストプラクティスです。一意の bot:name: ラベルに基づき、任意の、または複数のボットを除外できます。
特定のボットからのリクエストにカスタムヘッダを挿入する
特定のリクエストをさらに処理・分析したい場合や、下流のシステムが提供するロジックを実装したい場合があります。このようなときに、AWS WAF Bot Control を使用すると、リクエストを分類できます。後工程のアプリケーションでは、カテゴリ内のすべてのような幅広い範囲、特定のボットのような狭い範囲のいずれにも、意図したロジックを適用できます。
カスタムヘッダを挿入する
- AWS WAF コンソールで、左メニューから Web ACLs を選択します。Web ACL を開くか、Web ACL を作成する手順に従います。次の手順では、Web ACL で Bot Control ルールグループがすでに有効になっていることを想定しています。
- Web ACL 内のリストにある Bot Control rule set を開き、Edit をクリックします。
- Rules のリストから対象のカテゴリを見つけ、Count にします。
- Save rule をクリックします。
- 同じ Web ACL で、Add rules をクリックし、Add my own rules and rule groups を選択します。
- Rule builder を使用し、以下のように設定します。
- Name にルール名を入力します。
- Inspect で Has a label を選択します。
- Match key フィールドに対象のカテゴリもしくはボットのラベルを入力します。この例ではセキュリティカテゴリのラベルを使用しています。
awswaf:managed:aws:bot-control:bot:category:security
- Action セクションで Count を選択します。
- Custom request – optional を展開し、Add new custom header を選択します。
- Key と Value に下流システムで使用するカスタムヘッダのヘッダーキーと値を入力します。この例では図 12 のように設定しています。
- Add rule をクリックします。
AWS WAF は、カスタムヘッダ挿入時に x-amzn-waf- という接頭辞をヘッダ名に付けるため、abc-category を追加した場合には、下流システムからは x-amzn-waf-abc-category として読み取れます。
図 12: カスタムヘッダを挿入する AWS WAF rule action
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 セキュリティに関するニュースをもっと知りたいですか？ツイッターでフォローしてください。
翻訳はソリューションアーキテクト 駒原 が担当しました。原文はこちらです。
からの記事と詳細 ( AWS WAF Bot Control のチューニングと最適化 | Amazon Web Services - amazon.com )
https://ift.tt/0MzLITd
No comments:
Post a Comment