ステップ3：クライアント認証ルールを設定する
ダウンロード
フォーカスモード
フォントサイズ
概要
本ドキュメントでは、EdgeOneクライアント認証ルールの設定方法について説明します。このルールは、クライアントに対して認証（チャレンジ）をトリガーするタイミングを決定するために使用されます。認証ルールはリクエストの特徴をマッチングし、設定された優先順位に従ってソートされます。リクエストがルール条件を満たすと、関連付けられた認証方式が実行されます。本記事では、ルールのマッチングメカニズム、優先順位設計、および各フィールドの意味について説明します。
説明：
クライアント認証ルールでは、現在、他のサイト内で設定された認証方式またはAPIリソースの使用はサポートされていません。
クライアント認証は、現在、クロスサイト展開のポリシーテンプレートでの使用をサポートしていません。
サンプルシナリオ
オンライン小売サイト
www.examplestore.comの注文インターフェース/api/order.jsonにアクセスするクライアントに対してセキュリティ認証を実行します。H5クライアント、iOS、Androidモバイル端末が注文インターフェースにアクセスする際には、事前にEdgeOne 人機検証を使用して検証し、高リスクのクライアントアクセスをサイレント処理することが求められます。操作手順
注意：
1. EdgeOne 人機検証オプションを使用する前に、まず認証方式の設定でそのカスタム認証方式を作成してください。
2. ブラウザまたはWebViewクライアントにSDKを自動展開する場合は、まずブラウザおよびWebView端末の統合手順を完了してテスト検証してください。
1. EdgeOneコンソールにログインし、左側のメニューバーで「サービス概要」に入り、「Webサイト安全な加速」内で設定が必要なサイトをクリックします。
2. 「セキュリティ保護」>「Web保護」をクリックします。デフォルトではサイトレベル保護ポリシーです。「ドメインレベル保護ポリシー」タブをクリックし、ドメインレベル保護ポリシーで、対象ドメインをクリックして対象ドメインの保護ポリシー設定画面に入ります。例えば：
www.examplestore.com。3. Bot管理カードに移動し、クライアント認証の下にあるルールを追加をクリックして、設定ページに入ります。
4. ルール名を入力し、判定条件、認証方式、および異なるリスククライアントの処理オプションを設定します。例のシナリオを例にすると、一致条件オプションでリクエストパス一致を選択し、認証ポリシーオプションで、提供元が EdgeOne 人機検証のカスタム認証オプションを選択します。
5. 認証ポリシーで、順番にアクセスを許可するクライアントタイプを追加します。
アクセスを許可する各クライアントタイプに対して、異なるリスクリクエストの処理オプションを設定します。
認証要件を満たさないリクエストに対して、処理オプションを設定します。
6. 「保存して公開」をクリックすると、ルールがデプロイされて有効になります。
関連参考
クライアント認証ルールの説明
EdgeOneのクライアント認証ルールは、Web保護のBot管理モジュールで設定します。各ルールには以下の設定項目が含まれます：
一致条件：認証ルールの適用範囲。
マッチング条件には、リクエストURLとリクエストヘッダーのフィールドが含まれます。例えば、Host、URL、リクエストパス（Path）、指定リクエストヘッダーなどです。また、APIリソースをマッチング条件として参照することもできます。
ルールには1つまたは複数の一致条件を設定できます。リクエストがすべての条件を満たした場合にのみ、そのルールが有効になります。
認証方式：クライアントが提供する有効な認証情報に含める必要がある認証方式です。
認証に必要なSDKを統合済みであるにもかかわらず、認証が完了していないクライアントリクエストに対しては、HTTP 428が応答され、クライアントに追加の認証情報の提示が要求されます。詳細はHTTP 428チャレンジの処理フローを参照してください。
既にこの認証方式の認証情報を持っているが、その認証情報が期限切れとなっているリクエストに対しては、HTTP 428が応答され、クライアントに追加の認証情報の提示が要求されます。詳細はHTTP 428チャレンジの処理フローを参照してください。
その他、この認証方式の有効な認証情報が提供されていないリクエストは、認証要件を満たさないものとして処理されます。
デバイス認証ポリシー：異なるタイプのクライアントリクエストに対する認証要件と処理方法を設定します。
デバイスタイプ：ブラウザ/WebView、iOS、Androidクライアントを選択できます。クライアント統合が完了すると、認証SDKは認証情報に認証済みクライアントタイプを含めます。ルールはこの識別子に基づいて、対応するデバイスの認証ポリシーを採用します。
リクエストリスクスコアリング：認証プロバイダーが提供する認証結果の詳細に基づいてリスクスコアリングを行います。設定されたスコアリング区間に基づいて、リクエストを高リスクリクエスト、中リスクリクエスト、低リスクリクエストに分類して処理できます。認証プロバイダーがスコアリングをサポートしている場合は、認証プロバイダーのスコアリング結果を直接使用します。
説明：スコアリング範囲は0～100です。0はこの認証方式がリスクを提示していないことを示し、100は認証結果が高リスクリクエストを明確に提示していることを示します。
処置方法：ブロック、サイレントを含む複数の処置方法を選択できます。低リスクリクエストに対しては、観察オプションの使用のみがサポートされます（ログのみ記録し、処理は行いません）。観察処置方法を使用するリクエストは、引き続き他のクライアント認証ルールと照合されます。
認証要件を満たさない場合のリクエスト処理方法：クライアントSDKが統合されていない場合、または提供された認証情報が不正な場合、指定された方法で処理します。
優先度：優先度が高い（優先度の数値が小さい）ルールから先に照合します。ルールがブロックまたはチャレンジされなかった場合は、他のルールの照合を続けます。
フィードバック