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

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

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) > アイデンティティ脅威保護 に移動します。

  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チャレンジ(Okta Challenge)に設定したままにします。

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

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

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

関連項目

ボット保護

ボット防御レポート