ボット防御の強制適用を構成する

早期アクセスリリース。「セルフサービス機能を有効にする」を参照してください。

CAPTCHAを使用するorgではボット防御がデフォルトで無効になっており、使用しないorgではモニタリングステータスになっています。この機能を使用するには、ステータスを変更してから検出と強制適用の設定を構成します。

開始する前に

ボット防御は、Sign-In Widgetを介したサインイン、サインアップ、セルフサービスのパスワード復旧フローでのみサポートされます。Sign-In Widgetバージョン7.40.3以降が必要です。

セルフサービスのパスワード復旧フローを保護するには、グローバルセッションポリシーでセッションの確立にパスワードを必須にする必要があります。その他の要素を必須とするポリシーはサポートされません。

orgでCloudflareZscaler、またはFastlyなどのWebアプリケーションファイアウォール(WAF)を使用する場合は、元のクライアントのIPアドレスを渡すように構成する必要があります。

  1. WAFにX-Forwarded-For(XFF)HTTPヘッダーを構成して、元のクライアントのIPアドレスがHTTPリクエストのXFFヘッダーに追加されるようにします。これにより、最初のIPが実際のクライアントとなるIPアドレスのチェーンが作成されます。その後、Oktaでは完全なIPチェーンを確認し、ボット検知モデルでクライアントのIPを使用できます。

  2. OktaでWAFのIPを信頼できるプロキシとして構成します。これにより、OktaはWAFのIPを無視できます。代わりにXFFヘッダーの最初のIPアドレスを確認して、リクエストの真のソースを判断します。

このタスクを開始する

  1. Admin Consoleで、[Security(セキュリティ)] Identity Threat Protectionに移動します

  2. [Detection and Response(検出および応答)]タブをクリックします。

  3. [Bot protection(ボット防御)]セクションに移動します。

  4. [Status(ステータス)]セクションで、[Enforced(強制適用済み)]を選択します。

  5. CAPTCHAを有効にしている場合は、CAPTCHA統合がボット防御によって置き換えられることを理解していることを確認してください。

  6. [Detection settings(検出設定)][Edit(編集)]をクリックします。

  7. [Bot Likeliness(ボットの可能性)]のしきい値を選択します。

    • [High(高)]:信頼度が高度のボットリクエストのみにフラグを付けます。このオプションでは、スムーズなユーザーエクスペリエンスが優先されます。

    • [Medium and above(中程度以上)]:信頼度が中程度と高度のボットリクエストにフラグを付けます。このオプションでは、ユーザーエクスペリエンスとセキュリティが両立されます。

    • [Low and above(低度以上)]:信頼性が低度のボットリクエストのみにフラグを付けます。このオプションでは厳格なセキュリティが優先されます。

    • [Any(すべて)]:信頼レベルに関係なく、すべてのリクエストにフラグを付けます。

  8. [Protected flows(保護されたフロー)]メニューで、保護するフローを選択します。

  9. [Enforcement settings(強制適用設定)][Okta Challenge(Oktaチャレンジ)]に設定したままにします。

ユーザーエクスペリエンス

ユーザーエクスペリエンスの変更は最小限に留まります。

ボット防御は、認証用のユーザー資格情報の送信時に開始されます。フローによっては、ユーザーが[Next(次へ)][Sign up(サインアップ)]、または[Change password(パスワード変更)]をクリックした時です。ボット防御が[Monitoring(モニタリング)]に設定されている場合、ユーザーは変更に気付きません。[Enforced(強制適用済み)]に設定すると、ユーザーに短い「確認中」メッセージが表示されます。検証済みのユーザーは引き続きダッシュボードを使用し、検証に失敗したリクエストは403エラーページにリダイレクトされます。

関連項目

ボット保護

ボット防御レポート