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

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

前提条件

orgが第三世代Sign-In Widget を使用している場合、すべてのブランドをバージョン7.20以降にアップグレードします。
org内のすべてのユーザーがフィッシング耐性のあるAuthenticatorを使用できなければなりません。Authenticator登録ポリシーを作成するを参照してください。

ルールを追加する

Admin Consoleでセキュリティ（Security） > 認証ポリシーに移動します。
Okta account managementを選択します。
ルールを追加（Add Rule）をクリックします。
わかりやすいルール名を入力します（Phishing-resistant authenticator enrollmentなど）。
次のIF条件を設定します。デバイス条件は早期アクセス機能です。
- ユーザーのユーザータイプ（User's user type）：［任意のユーザータイプ］
- ユーザーのグループメンバーシップ（User's group membership includes）：［任意］
- ユーザー：（User is）：［任意］
- デバイスの状態：（Device state is）：［登録済み］
- デバイス管理：（Device management is）管理対象（：［Managed）］
- デバイス保証ポリシー：（Device assurance policy is）：［いずれかのポリシー］
- デバイスプラットフォーム（Device platform is）：任意のプラットフォーム
- ユーザーのIP：（User's IP is）：［任意］
- リスク（Risk is）：任意
- 次のカスタム式をtrueとする（The following custom expression is true）：accessRequest.operation == 'enroll' || accessRequest.operation == 'unenroll'
次のTHEN条件を設定します。
- アクセス：（Access is）：［認証の成功後に許可］
- ユーザーが使用する認証方法（User must authenticate with）：［所有要素］
- 所有要素の制約（Possession factor constraints are）：［フィッシング耐性］
- 認証方法（Authentication methods）：［要件を満たすために使用できる任意の方法を許可］
- 認証のためのプロンプト（Prompt for authentication）：ユーザーがリソースにサインインするたび
保存（Save）をクリックします。

注:

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

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

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

現在単一要素でアクティブ化されているユーザーが新しいAuthenticatorを登録できないか、MFAを必要とするアプリにサインインできません。このタスクの前提条件を参照してください。
ユーザーは、あまりにも多くのAuthenticatorを登録解除すると、ロックアウトされる可能性があります。フィッシング耐性のあるAuthenticatorを少なくとも1つ常に登録しておく必要があることをユーザーに知らせてください。