ある参加者から素晴らしい質問を受けました。上のウェブ上のリソースをシンプルなボットから保護するために、コスト効率がよく、信頼性が高く、複雑すぎないソリューションを設計するのを手伝ってほしいと言いました。リリースにより、その質問にエレガントなソリューションで対応できるようになったので、私はこのときのことをよく覚えています。以上を占める一般的で広範なボットのフィルタリングを開始するために、スイッチを入れるだけの問題になっているのです。その機能の一部が紹介されています。この記事では、どこから始めればいいのか、どの要素を設定と保護のために使用すればよいかについて、知るべき情報をカバーしています。本記事では、密接に関連する機能を明らかにし、重要な考慮事項、ベストプラクティス、および一般的なユースケースのためのカスタマイズ方法について説明します。対象となるユースケースは以下の通りです。チューニングの主な要素ボット軽減機能の細かい設定に移る前に、このプロセスの構成要素を理解することが重要です。独自のものではありませんが、この機能を活用し、多くの設定でラベルをメインの入力として使用しています。ラベルは、ルールステートメントのマッチングに基づいて、リクエストに適用される文字列です。特定のリクエストに属するタグのようなものです。内の後続のすべてのルールでラベルを取得し、同様のリクエストの識別に利用できます。ラベルを使用すると、特定の条件を満たすリクエストのグループに対処することができます。内の後続のルールが追加されたラベルにアクセスでき、それらに対してマッチングができるからです。ラベルは、単なるルールマッチングの仕組みにとどまりません。いずれに対しても追加することができます。ログのレコードに対してラベルに基づくフィルタリングやクエリを構築し、高度な分析が可能になります。ラベルは、コロンで区切られた、接頭辞、オプションの名前空間、名前で構成される文字列です。よって自動的に追加されます。様々なラベルと名前空間があります。ボットの名称(ある場合)。アプリケーションにとって安全です。このセクションで後述するボット確認検出ロジックによって、これらのボットが提示するソースから来たものであることを検証します。よってブロックされませんが、ラベルを使用して、カスタムルールでこれらをブロックすることもできます。ボットのアクティビティを示す属性。これらを使って、以下のような処理を実行します。リクエストのユーザーエージェントを既知のボットと比較、分類し、お客様がカテゴリ別にブロックできるようにします。ボットは、スクレイパー、検索エンジン、ソーシャルメディアなどの機能別に分類されます。よって、ドメイン名とホスト名の妥当性を検証します。これらの自動チェックは、正当なボットだけを許可し、下流のシステムにボット検出のフラグを立てるためのシグナルを提供するのに役立ちます。リクエストヘッダの検証では、ヘッダの欠落、不正なヘッダ、無効なヘッダを探すための一連のチェックを実行します。組み合わせを識別するブラウザシグネチャを生成することができます。このシグネチャーは、ユーザーエージェントと一致していることを確認するために検証され、既知の良性・悪性のブラウザシグネチャーのリストと照合することができます。ラベルの例をいくつか示します。使用して、すべてのリストを取得できます。アクションに切り替えることができます。これにより、次のことが実現されます。ルールの1つにマッチしても、リソースに対する正当なボットである可能性があるリクエストが誤検出されるのを回避します。ルールにマッチした際に、ラベルとリクエストへのアクションという形で、十分なデータポイントを蓄積できます。これにより、ボットやカテゴリごとにルールを構築し、いつデフォルトのアクションに切り替えるべきかについて、十分な情報を得た上で判断できます。ログから確認でき、そこからすぐに、特定のシナリオに対応するための例外やカスタムルールの必要性について計画することができます。この投稿では、「典型的なユースケース」のセクションで、それらを検討します。どこに位置しているかを考慮する必要があります。ルールグループを配置することができます。処理するリクエスト数が減少し、費用対効果が高まります。は早い段階のルールで評価されるよう配置すべきでしょう。後続のルールのためにラベルを生成したい。副次的な効果として、高い視認性ももたらします。評価する前に適切なボットをブロックしてしまう誤検出を減らしたい。一連の機能なしには、完備かつ設定可能とは言えません。それらを紐解いてみましょう。これにより、ウェブサイトにヒットしたボットやカテゴリ、それに関連するラベルを確認でき、チューニングに利用することができます。メトリクスは以下のようなディメンジョンとメトリクスで生成されます。除いて、すべてのリージョンで利用可能です。関連付けられている場合は北バージニアリージョンのメトリクスとなります。接頭辞を含む、完全修飾の名前空間です。最終的なアクションです。メトリクスへのショートカットがあります。サービスカテゴリで確認することができます。生成されたラベル、日時ごとのボリュームをメトリクスとして取得できるため、評価の上、ルールの構成や誤検出への対処について、情報に基づいた判断を下すことができます。私のウェブサイトへのボットからのリクエストに対して、生成されたラベルを示しています。アクションをいくつか設定しただけなので、ほとんどがブロックされました。上段には、選択された2つのラベルのメトリクスを示しています。フィールドの配列として記録されます。配列を含むリクエストの例を示します。つのラベルが生成されています。カテゴリラベルに従います。つのラベルを組み合わせることは、それらに基づく設定に柔軟性を持たせるのに有効です。カテゴリ全体を使うこともできますし、特定のボットのラベルを使ってフォーカスすることもできます。この投稿の後半で、このことがどのように、そしてなぜ重要であるかを説明します。通常とは異なるヘッダを持ったリクエストのシグナルです。ラベルと組み合わせてボットから保護するために、特定のリクエストに対してアプリケーションで特別なスキャンを構築できます。あることを考えれば、コストを抑えられるかどうかは非常に重要です。よる検査を必要としないトラフィックをフィルタすることで、コストを最適化できます。つの大まかなシナリオで、スコープダウンステートメントを使用できます。よるスキャンから除外することができます。ウェブサイトのうち、ボットにアクセスされても構わない箇所を考えてみましょう。ファイルなどの静的コンテンツがこれにあたります。ログインページなどの部分には保護を残します。レンジを除外することもできます。自社組織から発信されていることが分かっているトラフィックや、パートナーや顧客等の閲覧者です。視点を変えて、リソースのごく一部にのみボット管理を適用することも可能です。保護し、それ以外は対象外にできます。これらを駆使して、ユースケースとシナリオを掘り下げてみましょう。ニーズに合うようチューニングする方法はいくつかあります。このセクションでは、使用できるいくつかの方法を紹介します。場合によっては、ウェブサイトへのボットのアクセスを許可する必要があります。検索エンジンのボットは、ウェブサイトをクロールしてインデックスを作成します。検索エンジンの最適化がビジネスにとって重要である一方、ウェブリソースへのリクエストが多すぎて負荷がかかりすぎている場合、必要以上にブロックすることなくクローラーの速度を下げる方法についてジレンマに直面することがあります。検知ロジックと、レスポンスのステータスコードやヘッダでクローラーに意図を伝えるレートベースルールを組み合わせることで、これを解決できます。有用と判断されるほとんどのクローラーは、負荷の増加を検知した際に、クロールレートを低下させるメカニズムを持っています。作成する手順に従います。選択し、以下のように設定します。内の評価プロセスで、後続のルールで使用できるラベルも取得できます。