翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ボット制御のテクニック
ボット緩和の主な目的は、自動化されたボットアクティビティが組織のウェブサイト、サービス、アプリケーションに与える悪影響を制限することです。使用するテクノロジーと手法は、防御するトラフィックまたはアクティビティのタイプによって異なります。これを実現するには、アプリケーションとそのトラフィックを理解することが重要です。開始する場所の詳細については、このガイドの[ボットコントロール戦略のモニタリングに関するガイドライン](monitoring.md)「」セクションを参照してください。
一般的に、ボット緩和ソリューションが提供するコントロールは、静的、クライアント識別、高度な分析の大まかなカテゴリにグループ化できます。次の図は、利用可能なさまざまな手法と、ボットアクティビティの複雑さに応じてどのように使用できるかを示しています。これにより、許可リストや組み込みチェックなどの静的コントロールを使用して、ベースまたは最も広範な緩和策を取得する方法が浮き彫りになります。ボットの最小部分は常に最も高度であり、これらのボットに対する緩和には、より高度なテクノロジーとコントロールの組み合わせが必要です。
![\[ボットの複雑さが増すにつれて、 は緩和手法の複雑さと洗練さも増す必要があります。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/bot-control/images/bot-mitigation-techniques.png)
次に、このガイドでは各カテゴリとその手法について説明します。また、これらのコントロールを実装[AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html)するために で使用できるオプションについても説明します。
+ [ボットを管理するための静的コントロール](static-controls.md)
+ [ボットを管理するためのクライアント識別コントロール](client-identification-controls.md)
+ [ボットを管理するための高度な分析コントロール](advanced-analysis-controls.md)
# ボットを管理するための静的コントロール
アクションを実行するために、*静的コントロール*は IP アドレスやヘッダーなど、HTTP(S) リクエストからの静的情報を評価します。これらのコントロールは、洗練度の低い悪質なボットアクティビティや、検証および管理が必要な予想される有益なボットトラフィックに役立ちます。静的コントロール手法には、許可リスト、IP ベースのコントロール、組み込みチェックなどがあります。
## 一覧表示を許可する
許可リストは、既存のボット緩和コントロールを通じて識別されたフレンドリトラフィックを許可するコントロールです。これを実現するには、さまざまな方法があります。最も簡単なのは、[一連の IP アドレス](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-forwarded-ip-address.html)または同様の一致条件に一致するルールを使用することです。リクエストがアクションに設定されたルールと一致すると`Allow`、後続のルールでは評価されません。場合によっては、特定のルールのみが実行されるのを防ぐ必要があります。つまり、1 つのルールのリストを許可する必要がありますが、すべてのルールを許可することはできません。これは、ルールの誤検出を処理するための一般的なシナリオです。許可リストは、広範なルールと見なされます。偽陰性の可能性を減らすために、パスやヘッダーの一致など、より詳細な別のオプションと組み合わせることをお勧めします。
## IP ベースのコントロール
### 単一の IP アドレスブロック
ボットの影響を軽減するために一般的に使用されるツールは、単一のリクエスタからのリクエストを制限することです。最も簡単な例は、トラフィックの送信元 IP アドレスのリクエストが悪意のあるものであるか、ボリュームが多い場合、そのトラフィックの送信元 IP アドレスをブロックすることです。これは AWS WAF [、IP セット一致ルール](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-ipset-match.html)を使用して IP ベースのブロックを実装します。これらのルールは IP アドレスに一致し、`Block`、、`Challenge`または のアクションを適用します`CAPTCHA`。IP アドレスからのリクエストが多すぎる場合は、コンテンツ配信ネットワーク (CDN)、ウェブアプリケーションファイアウォール、またはアプリケーションとサービスログを確認することで判断できます。ただし、ほとんどの場合、このコントロールは自動化なしでは実用的ではありません。
での IP アドレスブロックリストの自動化 AWS WAF は、一般的にレートベースのルールで行われます。詳細については、このガイドの「[レートベースのルール](#rate-based-rules)」を参照してください。ソリューション[のセキュリティオートメーション AWS WAF](https://docs.aws.amazon.com/solutions/latest/security-automations-for-aws-waf/welcome.html)を実装することもできます。このソリューションは、ブロックする IP アドレスのリストを自動的に更新し、 AWS WAF ルールはそれらの IP アドレスに一致するリクエストを拒否します。
ボット攻撃を認識する 1 つの方法は、同じ IP アドレスからの多数のリクエストが少数のウェブページに集中している場合です。これは、ボットが料金スクレイプしているか、高い割合で失敗したログインを繰り返し試行していることを示します。このパターンをすぐに認識するオートメーションを作成できます。自動化により IP アドレスがブロックされるため、攻撃をすばやく特定して軽減することで、攻撃の有効性が低下します。特定の IP アドレスをブロックすることは、攻撃者が攻撃を開始するための大量の IP アドレスのコレクションを持っている場合、または攻撃動作を認識して通常のトラフィックから分離するのが困難な場合、あまり効果的ではありません。
### IP アドレスの評価
*IP 評価サービスは*、IP アドレスの信頼性を評価するのに役立つインテリジェンスを提供します。このインテリジェンスは、通常、その IP アドレスからの過去のアクティビティから IP 関連情報を集約することによって算出されます。以前のアクティビティは、IP アドレスが悪意のあるリクエストを生成する可能性を示すのに役立ちます。データは、IP アドレスの動作を追跡するマネージドリストに追加されます。
匿名 IP アドレスは、IP アドレスの評価の特殊なケースです。ソース IP アドレスは、クラウドベースの仮想マシンなどの簡単に取得できる IP アドレスの既知のソース、または既知の VPN プロバイダーや Tor ノードなどのプロキシから取得されます。 AWS WAF [Amazon IP 評価リスト](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon)と[匿名 IP リスト](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-anonymous)マネージドルールグループは、Amazon 内部脅威インテリジェンスを使用して、これらの IP アドレスを識別します。
これらのマネージドリストによって提供されるインテリジェンスは、これらのソースから特定されたアクティビティに対処するのに役立ちます。このインテリジェンスに基づいて、トラフィックを直接ブロックするルールや、リクエストの数を制限するルール (レートベースのルールなど) を作成できます。このインテリジェンスを使用して、 `COUNT` モードでルールを使用してトラフィックのソースを評価することもできます。これにより、一致基準が調べられ、カスタムルールの作成に使用できるラベルが適用されます。
### レートベースのルール
レートベースのルールは、特定のシナリオにとって貴重なツールです。たとえば、レートベースのルールは、ボットトラフィックが機密性の高いユニフォームリソース識別子 (URIs) のユーザーと比較して大量の に達した場合や、トラフィックボリュームが通常のオペレーションに影響を与え始めた場合に有効です。レート制限は、リクエストを管理可能なレベルで維持し、アクセスを制限および制御できます。 は、レートベースのルールステートメントを使用して、[ウェブアクセスコントロールリスト (ウェブ ACL)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html) にレート制限ルールを実装 AWS WAF できます。 [https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)レートベースのルールを使用する場合に推奨されるアプローチは、サイト全体を対象とする包括的なルール、URI 固有のルール、および IP 評価レートベースのルールを含めることです。IP 評価レートベースのルールは、IP アドレス評価のインテリジェンスとレート制限機能を組み合わせます。
サイト全体について、包括的な IP 評価レートベースのルールは、少数の IPs からサイトを氾濫する、洗練されていないボットを防止する上限を作成します。レート制限は、ログインページやアカウント作成ページなど、コストや影響が大きい URIs を保護する場合に特に推奨されます。
レート制限ルールは、コスト効率の高い第 1 防御層を提供できます。より高度なルールを使用して、機密性の高い URIs を保護できます。URI 固有のレートベースのルールは、重要なページや、データベースアクセスなどのバックエンドに影響する APIs への影響を制限できます。このガイドで後述する特定の URIs を保護するための高度な緩和策では、追加コストが発生することが多く、これらの URI 固有のレートベースのルールはコストの制御に役立ちます。一般的に推奨されるレートベースのルールの詳細については、 AWS セキュリティブログの[「最も重要な 3 つの AWS WAF レートベースのルール](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)」を参照してください。状況によっては、レートベースのルールによって評価されるリクエストのタイプを制限すると便利です。[スコープダウンステートメント](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-scope-down-statements.html)を使用して、ソース IP アドレスの地理的領域でレートベースのルールを制限できます。
AWS WAF は、[集約キー](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-aggregation-instances.html)を使用してレートベースのルールの高度な機能を提供します。この機能を使用すると、ソース IP アドレス以外のさまざまな集約キーとキーの組み合わせを使用するようにレートベースのルールを設定できます。たとえば、単一の組み合わせとして、転送された IP アドレス、HTTP メソッド、およびクエリ引数に基づいてリクエストを集約できます。これにより、高度なボリューメトリックトラフィックの軽減のために、よりきめ細かなルールを設定できます。
## 組み込みチェック
*組み込みチェック*は、システムまたはプロセス内のさまざまなタイプの内部または固有の検証または検証です。ボット制御の場合、 AWS WAF はリクエストで送信された情報がシステムシグナルと一致することを確認して、組み込みチェックを実行します。たとえば、逆引き DNS ルックアップやその他のシステム検証を実行します。SEO 関連のリクエストなど、一部の自動リクエストが必要です。許可リストは、期待される適切なボットを許可する方法です。ただし、悪意のあるボットが適切なボットをエミュレートすることがあり、それらを分離するのは難しい場合があります。 は、マネージド [AWS WAF Bot Control ルールグループ](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-bot.html)を通じてこれを実現する方法 AWS WAF を提供します。このグループのルールは、自己識別ボットが本人であることを検証します。 は、リクエストの詳細をそのボットの既知のパターンと AWS WAF 照合し、逆引き DNS ルックアップやその他の目標検証も実行します。
# ボットを管理するためのクライアント識別コントロール
攻撃関連のトラフィックが静的属性で簡単に認識できない場合、検出はリクエストを行うクライアントを正確に識別できる必要があります。例えば、レートベースのルールは、レート制限されている属性が Cookie やトークンなどのアプリケーション固有である場合に、より効果的で回避が難しいことがよくあります。セッションに関連付けられた Cookie を使用すると、ボットネットオペレーターが多くのボット間で同様のリクエストフローを複製できなくなります。
トークン取得は、クライアント識別に一般的に使用されます。トークン取得の場合、JavaScript コードは情報を収集して、サーバー側で評価されるトークンを生成します。評価は、JavaScript がクライアントで実行されていることの検証から、フィンガープリント用のデバイス情報の収集まで多岐にわたります。トークンの取得では、JavaScript SDK をサイトまたはアプリケーションに統合するか、サービスプロバイダーが動的にインジェクションを実行する必要があります。
JavaScript サポートを必須にすると、ボットがブラウザをエミュレートしようとする際のハードルが追加されます。モバイルアプリケーションなどの SDK が関与する場合、トークン取得は SDK の実装を検証し、ボットがアプリケーションのリクエストを模倣しないようにします。
トークンの取得には、接続のクライアント側で実装された SDKs を使用する必要があります。次の AWS WAF 機能は、ブラウザ用の JavaScript ベースの SDK とモバイルデバイス用のアプリケーションベースの SDK を提供します: [Bot Control](https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control.html)、 [Fraud Control Account Takeover Prevention (ATP)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-atp.html)、 [Fraud Control Account Creation Fraud Prevention (ACFP)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-acfp.html)。
クライアント識別の手法には、CAPTCHA、ブラウザプロファイリング、デバイスのフィンガープリント、TLS フィンガープリントなどがあります。
## CAPTCHA
コンピュータと人間を区別するための完全に自動化されたパブリックチューリングテスト ([CAPTCHA](https://docs.aws.amazon.com/waf/latest/developerguide/waf-captcha.html)) は、ロボット訪問者と人間訪問者を区別し、ウェブスクレイピング、認証情報スタッフィング、スパムを防ぐために使用されます。実装にはさまざまなものがありますが、多くの場合、人間が解決できるパズルが含まれます。CAPTCHAsは、一般的なボットに対する追加の防御レイヤーを提供し、ボット検出の誤検出を減らすことができます。
AWS WAF は、ルールの検査基準に一致するウェブリクエストに対して CAPTCHA アクションを実行することをルールに許可します。このアクションは、サービスによって収集されたクライアント識別情報の評価の結果です。 AWS WAF ルールでは、ログイン、検索、フォーム送信など、ボットによって頻繁にターゲットにされる特定のリソースに対して CAPTCHA チャレンジを解決する必要があります。 AWS WAF は、相互手段または SDK を使用して直接 CAPTCHA を提供してクライアント側で処理できます。詳細については、[「CAPTCHA」と「チャレンジ AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-captcha-and-challenge.html)」を参照してください。
## ブラウザプロファイリング
*ブラウザプロファイリング*は、トークン取得の一環としてブラウザの特性を収集して評価し、インタラクティブブラウザを使用して実際の人間を分散ボットアクティビティと区別する方法です。ブラウザのプロファイリングは、ヘッダー、ヘッダーの順序、およびブラウザの動作に固有のリクエストのその他の特性を通じてパッシブに実行できます。
トークン取得を使用してコードでブラウザプロファイリングを実行することもできます。ブラウザプロファイリングに JavaScript を使用すると、クライアントが JavaScript をサポートしているかどうかをすばやく判断できます。これにより、サポートされていない単純なボットを検出できます。ブラウザプロファイリングは、HTTP ヘッダーと JavaScript サポートだけでなく、ボットがウェブブラウザを完全にエミュレートすることが困難になります。どちらのブラウザプロファイリングオプションも、実際のブラウザの動作との不整合を示すパターンをブラウザプロファイルで検索するという同じ目標を持っています。
AWS WAF ターゲットボットのボットコントロールは、トークン評価の一環として、ブラウザが自動化の証拠を示しているか、一貫性のないシグナルを示しているかを示します。 は、ルールで指定されたアクションを実行するためにリクエストを AWS WAF フラグ付けします。詳細については、 AWS セキュリティブログの[「高度なボットトラフィックを検出してブロック](https://aws.amazon.com/blogs/security/detect-and-block-advanced-bot-traffic/)する」を参照してください。
## デバイスのフィンガープリント
デバイスのフィンガープリントはブラウザプロファイリングに似ていますが、ブラウザに限定されません。デバイス (モバイルデバイスまたはウェブブラウザ) で実行されているコードは、デバイスの詳細を収集し、バックエンドサーバーに報告します。詳細には、メモリ、CPU タイプ、オペレーティングシステム (OS) カーネルタイプ、OS バージョン、仮想化などのシステム属性を含めることができます。
デバイスフィンガープリントを使用して、ボットが環境をエミュレートしているかどうか、またはオートメーションが使用されている直接の兆候があるかどうかを認識できます。さらに、デバイスのフィンガープリントを使用して、同じデバイスからの繰り返しのリクエストを認識することもできます。
同じデバイスから繰り返されるリクエストを認識すると、デバイスがリクエストの特性を変更しようとしても、バックエンドシステムはレート制限ルールを適用できます。デバイスのフィンガープリントに基づくレート制限ルールは、通常、IP アドレスに基づくレート制限ルールよりも効果的です。これにより、VPNs またはプロキシ間でローテーションしているが、少数のデバイスから取得されているボットトラフィックを軽減できます。
ターゲットボットの AWS WAF ボット制御をアプリケーション統合 SDKs で使用すると、 はクライアントセッションリクエストの動作を 集約できます。これにより、両方が同じ IP アドレスから発信された場合でも、正当なクライアントセッションを検出して悪意のあるクライアントセッションから分離できます。ターゲット AWS WAF ボットのボット制御の詳細については、 AWS セキュリティブログの[「高度なボットトラフィックを検出してブロック](https://aws.amazon.com/blogs/security/detect-and-block-advanced-bot-traffic/)する」を参照してください。
## TLS フィンガープリント
*署名ベースのルールとも呼ばれる TLS フィンガープリント*は、ボットが多くの IP アドレスから発信されるが、同様の特性を示す場合によく使用されます。HTTPS を使用する場合、クライアント側とサーバー側はメッセージを交換して相互に確認および検証します。暗号化アルゴリズムとセッションキーを確立します。これは *TLS ハンドシェイク*と呼ばれます。TLS ハンドシェイクの実装方法は、多くの IP アドレスにまたがる大規模な攻撃を認識する上でしばしば役立つ署名です。
TLS フィンガープリントを使用すると、ウェブサーバーはウェブクライアントのアイデンティティを高い精度で判断できます。アプリケーションデータ交換が発生する前に、最初のパケット接続のパラメータのみが必要です。この場合、*ウェブクライアント*とは、ブラウザ、CLI ツール、スクリプト (ボット）、ネイティブアプリケーション、またはその他のクライアントなど、リクエストを開始するアプリケーションを指します。
1 つの SSL および TLS フィンガープリントアプローチは [JA3 フィンガープリント](https://github.com/salesforce/ja3)です。JA3 は、SSL または TLS ハンドシェイクからの Client Hello メッセージ内のフィールドに基づいてクライアント接続をフィンガープリントします。これにより、異なるソース IP アドレス、ポート、および X.509 証明書間で特定の SSL および TLS クライアントをプロファイリングできます。
Amazon CloudFront は、リクエストへの [JA3 ヘッダーの追加](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/adding-cloudfront-headers.html)をサポートしています。`CloudFront-Viewer-JA3-Fingerprint` ヘッダーには、受信ビューワーリクエストの TLS Client Hello パケットの 32 文字のハッシュフィンガープリントが含まれます。フィンガープリントは、クライアントがどのように通信するかに関する情報をカプセル化します。この情報は、同じパターンを共有するクライアントをプロファイリングするために使用できます。`CloudFront-Viewer-JA3-Fingerprint` ヘッダーをオリジンリクエストポリシーに追加し、そのポリシーを CloudFront ディストリビューションにアタッチできます。その後、オリジンアプリケーションまたは Lambda@Edge および CloudFront Functions でヘッダー値を検査できます。ヘッダー値を既知のマルウェアフィンガープリントのリストと比較して、悪意のあるクライアントをブロックできます。ヘッダー値と予想されるフィンガープリントのリストを比較して、既知のクライアントからのリクエストのみを許可することもできます。
# ボットを管理するための高度な分析コントロール
一部のボットでは、高度な偽装ツールを使用して検出を積極的に回避しています。これらのボットは、頭皮などの特定のアクティビティを実行するために人間の動作を模倣します。これらのボットには目的があり、通常は大きな金銭的報酬にリンクされています。
これらの高度な永続ボットは、さまざまなテクノロジーを使用して検出を回避したり、通常のトラフィックとブレンドしたりします。また、悪意のあるトラフィックを正確に識別して軽減するには、さまざまな検出テクノロジーの組み合わせも必要です。
## ターゲットを絞ったユースケース
ユースケースデータは、ボット検出の機会を提供することができます。*不正検出*は、特別な緩和が必要とされる特別なユースケースです。たとえば、アカウントの乗っ取りを防ぐために、侵害されたアカウントのユーザー名とパスワードのリストをログインまたはアカウント作成リクエストと比較できます。これにより、ウェブサイトの所有者は、侵害された認証情報を使用するログイン試行を検出できます。侵害された認証情報を使用すると、ボットがアカウントを乗っ取ろうとしているか、認証情報が侵害されていることに気付いていないユーザーである可能性があります。このユースケースでは、ウェブサイト所有者は、ユーザーを検証し、パスワードの変更に役立つ追加の手順を実行できます。 は、このユースケースの [Fraud Control アカウント乗っ取り防止 (ATP)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-atp.html) マネージドルール AWS WAF を提供します。
## アプリケーションレベルまたは集計ボットの検出
一部のユースケースでは、コンテンツ配信ネットワーク (CDN) からのリクエストと AWS WAF、アプリケーションまたはサービスのバックエンドに関するデータを組み合わせる必要があります。場合によっては、ボットに関する信頼性の高い意思決定を行うために、サードパーティーのインテリジェンスを統合する必要もあります。
[Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) および の機能は AWS WAF 、バックエンドインフラストラクチャにシグナルを送信したり、ヘッダーと[ラベル](https://docs.aws.amazon.com/waf/latest/developerguide/waf-labels.html)を介してルールを集約したりできます。CloudFront は、前述のように JA3 フィンガープリントヘッダーを公開します。これは、CloudFront がヘッダーを介してそのようなデータを提供する例です。 は、ルールで一致するときにラベルを送信 AWS WAF できます。後続のルールでは、これらのラベルを使用してボットに関するより良い意思決定を行うことができます。複数のルールを組み合わせると、非常に詳細なコントロールを実装できます。一般的なユースケースは、ラベルを介してマネージドルールの一部を照合し 、それを他のリクエストデータと組み合わせることです。詳細については、 AWS WAF ドキュメントの[「ラベル一致の例](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-label-match-examples.html)」を参照してください。
## 機械学習分析
機械学習 (ML) は、ボットを処理するための強力な手法です。ML は詳細の変化に対応でき、他のツールと組み合わせると、誤検出を最小限に抑えてボットを軽減するための最も堅牢で完全な方法を提供します。最も一般的な ML 手法は、*動作分析*と*異常検出*の 2 つです。動作分析では、システム (クライアント、サーバー、またはその両方) はユーザーがアプリケーションまたはウェブサイトとやり取りする方法をモニタリングします。マウスの動きパターンまたはクリックとタッチのやり取りの頻度をモニタリングします。その後、動作は ML モデルで分析され、ボットを認識します。異常検出も同様です。アプリケーションまたはウェブサイトに定義されているベースラインとは大幅に異なる動作やパターンを検出することに重点を置いています。
AWS WAF ボットのターゲットコントロールは、予測 ML テクノロジーを提供します。このテクノロジーは、検出を回避するように設計されたボットによって行われる分散型のプロキシベースの攻撃に対する防御に役立ちます。マネージド [AWS WAF Bot Control ルールグループは](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-bot.html)、ウェブサイトトラフィック統計の自動 ML 分析を使用して、分散された調整されたボットアクティビティを示す異常な動作を検出します。