アクティブ特徴識別
ダウンロード
フォーカスモード
フォントサイズ
概要
受信したクライアントリクエストを分析し、ヘッダーとクライアントIP内の特徴を識別することに加えて、EdgeOneは能動的特徴識別によるBot識別方式も提供します。能動的特徴識別は、クライアントに対してCookie検証とセッショントラッキング、およびクライアント行動検証によるインタラクションを行うことができ、さらにクライアントのインタラクションフィードバックを通じて現在のアクセス者がツールであるかどうかを識別します。能動的特徴識別には以下の利点があります：
ブラウザの動作を模倣できるツール（例：Headless Chromeなど）に対して高い識別効果を持ちます。
他のフロントエンド検証方式（例：CAPTCHA人機検証）と比較して、能動的特徴識別の統合方式はビジネスへの侵入性が低く、ユーザーにはほとんど感知されません。これにより、より優れたBot識別効果と統合体験をもたらすことができます。
現在のサイトサービスでログイン/登録/決済サービスを提供しており、かつ高いビジネス価値を持つ場合（例：アカウント取得後にアカウント内の価値を得られる、決済を通じて希少な商品やサービスを取得できるなど）、重要なビジネスインターフェースに対して能動的特徴識別を有効にすることをお勧めします。
説明：
1. 主動的特徴識別のメカニズムの特性上、有効化する前に、お客様のビジネスがWebブラウザクライアントであることを確認するか、またはマッチング条件を通じて主動的特徴識別ルールをWebブラウザのみ許可するリソースに制限し、互換性の問題によるモバイルアプリのアクセスへの影響を回避してください。
2. エッジ関数に同時に関連付けられたアクセスパスに対して、主動的特徴識別はJavaScriptを正常に注入できません。偽造ブラウザクライアントを識別するために、他のHTMLページリソースを選択してJavaScript注入を構成することをお勧めします。
3. この機能は現在もクローズドベータ中です。有効化が必要な場合は、お問い合わせください。
サポートされる機能
主動的特徴識別は以下の2種類の能力設定をサポートします：
Cookie検証とセッショントラッキング：HTTPセッション状態（Cookieメカニズム）を通じて、各訪問者に動的セッショントークンを発行し、訪問者リクエストに合法的なセッショントークンが含まれていることを要求します。これにより、異なる訪問者からのリクエストを追跡・区別し、その行動特徴を識別します。リクエスト内のCookieの正当性の検証に加えて、Cookie検証は改ざんされたセッション情報や高頻度でCookie情報を収集する行為も識別し、セッションハイジャックによるセキュリティリスクを低減します。
クライアント行動検証：高度な自動化ツール（例：Headless Chrome）はすでにブラウザの動作を模倣できます。クライアント行動検証は、HTML応答ページにJavaScriptコードを注入することで、クライアントのJavaScript実行環境、デバイス環境、クライアントのインタラクション動作を収集し、ツール環境と正常なリクエストの訪問者を識別します。
クライアントインタラクションフロー
シナリオ1：一般的なWebツールクローラーによるメディアサイトへのアクセスをブロックする
シナリオ例
メディアサイト
media.example.comはH5クライアントとブラウザのみにサイトコンテンツの取得を許可し、かつ合法的なクライアントはすべてCookieをサポートしています。そのため、Cookieをサポートしないクライアントをブロックする必要があります。これには他の訪問者のセッションをハイジャックしたクローラーも含まれます。悪意を持ってCookieを改ざんするクライアントに対しては、サイレント方式で対抗し、接続を維持しますがリクエストには応答しません。操作手順
1. EdgeOneコンソールにログインし、左側のメニューバーでサービス概要に入り、ウェブサイトWebサイト安全な加速内で設定が必要なサイトをクリックします。
2. セキュリティ保護 > Web保護をクリックします。デフォルトではサイトレベル保護ポリシーです。ドメインレベル保護ポリシータブをクリックし、ドメインレベル保護ポリシーで対象ドメインをクリックして対象ドメインの保護ポリシー設定画面に入ります。例えば：
media.example.com。3. Bot管理カードに移動し、主動的特徴識別の下にあるルールを追加をクリックして、設定ページに入ります。
4. 判定条件と実行アクションを設定します。現在のシナリオを例にとると、マッチングフィールドをリクエストパス（Path）が正規表現
/*に一致し、かつリクエストメソッド（Method）がGETに等しいリクエストに設定できます。実行アクションをCookie検証とセッショントラッキングに設定し、検証方式をCookieを更新して検証に設定します：Cookieを携帯していない、またはCookieの有効期限が切れているリクエストに対して、トリガーしきい値を10秒以内に300回に設定し、実行処置をブロックにします。
不正なCookieを携帯しているリクエストに対して、実行処置はサイレントです。
設定項目 | 説明 |
検証方法 | Cookieを更新して検証：合法的なセッション情報を携帯していない、またはセッション情報の有効期限が切れているリクエストに対して、EdgeOneは応答にSet-Cookieヘッダーを含めてセッションを作成し、セッション情報を継続的に更新します。GET方式でアクセスするパスにはこの検証方式を選択することをお勧めします。 検証のみ：EdgeOneはリクエストに含まれるセッション情報が合法かどうかのみを検証します。リクエスト内のセッション情報の有効期限が切れている場合、またはリクエストに合法的なセッション情報が含まれていない場合、Cookieを更新して新しいセッションを作成することはありません。POST方式でアクセスするインターフェース（例：登録、ログイン、カート追加など）には検証のみ方式を使用することをお勧めします。 |
検証結果 | Cookie検証に合格しなかったリクエストは、検証結果に基づき、以下の方法で処理できます。 Cookie未携帯またはCookie有効期限切れ：Cookieヘッダーに含まれるセッション情報には有効期限があり、一定期間のみ有効です。リクエストに合法的なセッション情報が含まれていない場合、またはセッション情報の有効期限が切れている場合、セッション情報を更新して初めてCookie検証を通過できます。クライアントがセッション情報を含まないリクエストを高頻度で使用してアクセスする場合、Cookieを収集してセッションをハイジャックするリスクが存在する可能性があります。セッション情報を含まないリクエストが指定レートに達したとき、そのリクエスト送信元（クライアントIP）からの、かつ合法的なセッション情報を含まないリクエストを処置することを選択できます。 トリガーしきい値：一定時間内に許可される、Cookieを携帯していない、またはCookieの有効期限が切れている場合に作成できるセッション数の上限を設定し、新しいセッションの開始レートを制限できます。トリガーしきい値を超えた場合、設定された処置方法に従って処理されます。 不正なCookie：EdgeOneが発行するセッション情報には暗号化検証機能があり、セッション情報を恣意的に改ざんすることは通常、悪意のあるリクエストを意味します。セッション情報が改ざんされたリクエストを処置することを選択できます。 |
セッションのレートおよび周期特性の検証 | Cookie検証に合格したリクエストは、プリセットのレート特性に基づき、高リスク、中リスク、低リスクの3つに分類されます。各リスクレベルに対して異なる対処方法を設定することで、悪意のある行為をより効果的に識別し防御できます。 高リスク：単一セッション（Cookieヘッダー内の同じEO-Bot-SessionId値に対応）において、5分間の統計ウィンドウで1000件を超えるリクエストが発生した場合です。クライアント動作検証を有効にした後、同時に同一クライアントの検証チケット（Cookieヘッダー内の同じEO-Bot-Token値に対応）が1分間に200回を超えて繰り返し使用された場合も該当します。 中リスク：単一セッション（Cookieヘッダー内の同じEO-Bot-SessionId値に対応）において、5分間の統計ウィンドウで500件を超えるリクエストが発生した場合です。クライアント動作検証を有効にした後、同時に同一クライアントの検証チケット（Cookieヘッダー内の同じEO-Bot-Token値に対応）が1分間に100回を超えて繰り返し使用された場合も該当します。 低リスク：単一セッション（Cookieヘッダー内の同じEO-Bot-SessionId値に対応）において、5分間の統計ウィンドウで100件を超えるリクエストが発生した場合です。クライアント動作検証を有効にした後、同時に同一クライアントの検証チケット（Cookieヘッダー内の同じEO-Bot-Token値に対応）が1分間に20回を超えて繰り返し使用された場合も該当します。 |
5. 「保存して公開」をクリックすると、ルールがデプロイされて有効になります。
シナリオ2：クライアント挙動検証を用いたECサイトのパスワードリセットページとAPIの強化、および一括パスワードリセットによるアカウント乗っ取り（ATO、Account Take Over）攻撃への対抗
シナリオ例
ECサイト
shop.example.com のパスワードリセットインターフェース /api/password_reset において、大量の失敗したリセットリクエストが検出されました。これらのリクエストは多数のIPから発生しており、頻度は高くなく、明確な User-Agent またはヘッダーの集中性も見られません。そのため、アクティブ特徴認識機能を使用して、パスワードリセットインターフェース /api/password_reset およびパスワードリセットページ /account/forgot_password.html に対してBot対策戦略を強化し、サイレント方式で自動化されたパスワードリセット試行ツールに対抗します。操作手順
1. EdgeOneコンソールにログインし、左側のメニューバーでサービス概要に入り、ウェブサイトWebサイト安全な加速内で設定が必要なサイトをクリックします。
2. セキュリティ保護 > Web保護をクリックします。デフォルトではサイトレベル保護ポリシーです。ドメインレベル保護ポリシータブをクリックし、ドメインレベル保護ポリシーで対象ドメインをクリックして、対象ドメインの保護ポリシー設定画面に入ります。例えば：
shop.example.com。3. Bot管理カードに移動し、主動的特徴識別の下にあるルールを追加をクリックして、設定ページに入ります。
4. 判定条件と実行アクションを設定します。現在のシナリオを例にとると、マッチングフィールドをリクエストパス（Path）が
/account/forgot_password.htmlに等しいように設定できます。実行アクションをクライアント動作検証に設定し、プルーフオブワーク検証強度を高にし、実行方式を100ms遅延実行にします：クライアントがJSを有効にしていない（検証未完了）状態で、10秒以内に10回を超えるリクエストに対して、実行処置は（長時間）待機後の応答とします。
クライアント検証がタイムアウトしたリクエストに対して、実行処置はサイレントとします。
Botクライアントに対して、実行処置はサイレントとします。
説明：
クライアント行動検証は、応答の
Content-Typeがtext/htmlの場合にのみJavaScriptを注入して検証を行います。その他のリクエストは、現在の検証結果に基づいて処理されます。
設定項目 | 説明 |
プルーフ・オブ・ワーク検証 | クライアント動作検証は、プルーフ・オブ・ワーク検証の強度調整をサポートします。強度を調整することで、クライアントの計算負荷とBotの検出精度のバランスを取ることができます。 |
実行方式 | 検出用のJavaScriptコードは、ページ全体の読み込みが完了した後に実行されます。また、JavaScript検出コードの実行を一定時間遅延させることができます。これにより、通常のページ描画への影響を回避し、ブラウザが先にページを読み込んでから検証を行うことで、ユーザーのアクセス体験への影響を防ぎます。 |
検証結果 | クライアントがJSを有効にしていない（検証未完了）：JavaScriptをサポートしていないクライアント、または検証が完了していない時点で発信されたリクエストは、このカテゴリに分類されます。JavaScript検証には通常一定の時間がかかるため、クライアントが検証を完了する前に、一定レートのリクエストの通過を許可し、検証を通過せずかつ高頻度でリクエストを発信するクライアントを処置できます。 クライアント検証タイムアウト：クライアントはJavaScriptをサポートし、すでに検証を開始していますが、60秒以内に検証を完了できませんでした。60秒は通常のブラウザクライアントにとってクライアント行動検証を完了するのに十分です。一方、計算能力の低いIoTプロキシは検証がタイムアウトする確率が高くなります。このオプションを使用することで、計算能力の低い分散型Botネットワークリクエストを区別して処置できます。 Botクライアント：クライアントはJavaScript検証を正常に完了しましたが、検出モジュールがクライアントの実行環境の異常を発見しました。これは正常な人間がブラウザを通じてアクセスしたものではありません。 |
5. 「保存して公開」をクリックすると、ルールがデプロイされて有効になります。
フィードバック