Authenticatorの登録のルールを追加する

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

Authenticator登録プロセスにフィッシング耐性を組み込むには、このルールを追加します。このルールがアクティブの場合、ユーザーはフィッシング耐性のあるAuthenticator以外のAuthenticatorを登録するとき、およびAuthenticatorを登録解除するときに、フィッシング耐性のあるAuthenticatorを提供する必要があります。orgがフィッシング耐性のあるAuthenticatorをまだ使用していない場合は、まず最初のフィッシング耐性のあるAuthenticatorの登録ルールを追加してください。

前提条件

org内のすべてのユーザーがフィッシング耐性のあるAuthenticatorを使用できなければなりません。「Authenticator登録ポリシーを作成する」を参照してください。

ルールを追加する

  1. Admin Console[Security(セキュリティ)][Authentication Policies(認証ポリシー)]に移動します。

  2. [Okta Account Management Policy(Oktaアカウント管理ポリシー)]を選択します。

  3. [Add Rule(ルールを追加)]をクリックします。

  4. わかりやすいルール名を入力します(「フィッシング耐性のあるAuthenticatorの登録」など)。

  5. 次のIF条件を設定します。

    • [User type(ユーザータイプ)]:[任意のユーザータイプ]

    • [User group membership includes(ユーザーのグループメンバーシップ:)]:[任意]

    • [User is(ユーザー:)]:[任意]

    • [Device state is(デバイスの状態:)]:[任意]

    • [Device assurance policy is(デバイス保証ポリシー:)]:[ポリシーなし]

    • [Device platform is(デバイスプラットフォーム:)]:[任意のプラットフォーム]

    • [User's IP is(ユーザーのIP:)]:[任意]

    • [Risk is(リスク:)]:[任意]

    • [The following custom expression is true(次のカスタム式をtrueとする)]accessRequest.operation == 'enroll'

  6. 次のTHEN条件を設定します。

    • [Access is(アクセス:)]:[認証の成功後に許可]

    • [User must authenticate with(ユーザーが使用する認証方法)]:[所有要素]

    • [Possession factor constraints are(所有要素の制約)]:[フィッシング耐性]

    • [Authentication methods(認証方法)]:[要件を満たすために使用できる任意の方法を許可]

    • [Prompt for authentication(認証のためのプロンプト)]:ユーザーがリソースにサインインするたび

  7. [Save(保存)]をクリックします。

このルールの優先度はキャッチオールより上、ただし最初のフィッシング耐性のあるAuthenticator(追加した場合)より下に設定します。必ず最初のフィッシング耐性のあるAuthenticatorルールを優先度1のままにしてください。

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

ユーザーがこのルールの要件を満たす場合、このプロセスのユーザーエクスペリエンスは変化しません。ただし、ユーザーの鑑別工具の選択はフィッシング耐性のあるオプションに制限されます。次の2つのシナリオについて考えてみてください。

  • 現在単一要素でアクティブ化されているユーザーが新しいAuthenticatorを登録できないか、MFAを必要とするアプリにサインインできません。このタスクの前提条件を参照してください。

  • ユーザーは、あまりにも多くのAuthenticatorを登録解除すると、ロックアウトされる可能性があります。フィッシング耐性のある鑑別工具を少なくとも1つ常に登録しておく必要があることをユーザーに知らせてください。

関連項目

Oktaアカウント管理ポリシー

パスワードの復旧とアカウントのロック解除のルールを追加する