Okta FastPassの認証ポリシーを構成する

Okta FastPassをサポートする認証ポリシーを作成します。

この手順では、アプリへのパスワードなしのアクセスを許可する認証ポリシーを構成する方法の例について説明します。

このポリシーでは、ユーザーはアプリにアクセスする前に、デバイスにOkta Verifyをインストールおよび登録している必要があります（「デバイス登録」を参照）。未登録のデバイスのユーザーは、アプリへのアクセスを拒否されます。

1. Admin Consoleで、［Security（セキュリティ）］［Authentication Policies（認証ポリシー）］に移動します。
2. 更新するポリシーを選択します。
3. ［Add Rule（ルールを追加）］をクリックします。
4. 認証ポリシールールを作成します。

認証ポリシールールを設定するときは、ガイドとして「ルール1（例）」、「ルール2（例）」、および「ルール3（例）」を使用します。この例では：

• ルール1では、デバイスが管理され、登録されていて、安全なハードウェアを備えており、ユーザーが任意の2つの認証要素を正常に提供した場合、アプリケーションへのシームレスなアクセス（Okta FastPass）が許可されます。

• ルール2では、デバイスが登録されていて、管理されておらず、ユーザーがパスワードとその他の認証要素（電話またはメールを除く）を正常に提供した場合、アプリケーションへのアクセスが許可されます。

• ルール3では、ルール1またはルール2を満たさないすべてのユーザーへのアクセスを拒否します。

最も制限の厳しいルール（ルール1）が一番上にあり、最も制限が緩やかなルールが一番下にあります。

次の画像は、例として提供されているルールを反映しています。



ルール1（例）

このルールは、管理され、登録されていて、安全なハードウェアを備えたデバイスを使用するユーザーに適用されます。これにより、ユーザーはアプリケーションにシームレスにアクセスできます。ユーザーは、最後に認証してから1時間以上経過している場合にのみ再認証を求められます。

このルールに一致するユーザーは、任意の2つの認証要素タイプを使用してアプリケーションにアクセスできます。ユーザーがパスワードを入力せずにアプリケーションにアクセスするには、Okta Verifyで生体認証を有効にする必要があります。Okta Verifyで生体認証を有効にしてある場合でも、パスワード（知識要素）の入力を求められます。

1. ［Rule name（ルール名）］フィールドに、ルールの名前を入力します。例：パスワードなし：登録済み+管理対象+ハードウェアあり+2つの要素で許可
2. ルール1のガイドとして以下の構成を使用します。

条件	構成	説明
IF［User's user type is（ユーザーのユーザータイプ）］	［Any user type（任意のユーザータイプ）］	アプリにアクセスできるユーザータイプを構成します。次のいずれかを選択します。 ［Any user type（任意のユーザータイプ）］（デフォルト）：任意のユーザータイプにアプリへのアクセスを許可します。 ［One of the following user types（次のいずれかのユーザータイプ）］：特定のユーザータイプのみがアプリにアクセスできます。このオプションを選択したときに表示されるフィールドに、含めるユーザータイプと除外するユーザータイプを入力します。
AND［User's group membership includes（ユーザーのグループメンバーシップ）］	［Any group（任意のグループ）］	アプリにアクセスできるユーザーグループを構成します。次のいずれかを選択します。 ［Any group（任意のグループ）］（デフォルト）：任意のグループに属するユーザーがアプリにアクセスできます。 ［At least one of the following groups（次のグループのうち少なくとも1つ）］：特定のグループに属するユーザーのみがアプリにアクセスできます。このオプションを選択したときに表示されるフィールドに、含めるグループと除外するグループを入力します。
AND ［User is（ユーザー）］	［Any user（任意のユーザー）］	アプリにアクセスできるユーザーを構成します。次のいずれかを選択します。 ［Any user（任意のユーザー）］（デフォルト）：任意のユーザーにアプリへのアクセスを許可します。 ［At least one of the following users（次のユーザーのうち少なくとも1人）］：特定のユーザーにのみアプリへのアクセスを許可します。このオプションを選択したときに表示されるフィールドに、含めるユーザーと除外するユーザーを入力します。
AND［Device state is（デバイスの状態）］	［Registered（登録済み）］	アプリにアクセスするためにデバイスを登録する必要があるかどうかを構成します。次のいずれかを選択します。 ［Any（すべて）］（デフォルト）：登録済みおよび未登録のデバイスがアプリにアクセスできます。 ［Registered（登録済み）］：登録済みのデバイスのみがアプリにアクセスできます。
AND ［Device management is（デバイス管理）］	［Managed（管理対象）］	アプリにアクセスするためにデバイスを管理する必要があるかどうかを構成します。次のいずれかを選択します。 ［Not managed（非管理対象）］（デフォルト）：管理対象デバイスおよび非管理対象デバイスがアプリにアクセスできます。 ［Managed（管理対象）］：管理対象デバイスのみがアプリにアクセスできます。
AND［Device assurance policy（デバイス保証ポリシー）］	次のいずれかのデバイス保証ポリシー：	セキュリティに関連する必要なデバイス条件を制御します。次のいずれかを選択します。 ［No policy（ポリシーなし）］：デバイス保障ポリシーは必要ありません。 ［Any of the following device assurance policies（次のデバイス保証ポリシーのいずれか）］：オプションの選択時に表示されるリストから必要なデバイス保障ポリシーを選択します。別のシナリオをカバーするための複数のデバイス保障ポリシーを選択できます 「認証ポリシーにデバイス保証を追加する」を参照してください。
AND［Device platform is（デバイスプラットフォーム）］	［Any platform（任意のプラットフォーム）］	アプリにアクセスするために必要なデバイスプラットフォームを構成します。 前の手順で特定のデバイス保証ポリシーを選択した場合、このオプションはデフォルトから変更できません。次のいずれかを選択します。 ［Any platform（任意のプラットフォーム）］（デフォルト）：どのデバイスプラットフォームもアプリにアクセスできます。 ［One of the following platforms（次のプラットフォームのいずれか）］：指定されたデバイスプラットフォームのみがアプリにアクセスできます。このオプションを選択したときに表示されるリストから、次のうち1つ以上を選択します。 IOS ANDROID WINDOWS MACOS CHROMEOS MOBILE_OTHER DESKTOP_OTHER
AND［User's IP is（ユーザーのIP）］	［Any IP（任意のIP）］	アプリへのアクセスに必要なネットワークゾーンを構成します。次のいずれかを選択します。 ［Any IP（任意のIP）］（デフォルト）：任意のIPアドレスを持つデバイスがアプリにアクセスできます。 ［In any network zone defined in Okta（Oktaで定義された任意のネットワークゾーン）］：Oktaで定義されたネットワークゾーン内のデバイスのみがアプリにアクセスできます。 ［In any of the following zones（次のいずれかのゾーン）］：指定されたゾーン内のデバイスのみがアプリにアクセスできます。表示されるフィールドに特定のゾーンを入力します。 ［Not in any network zone defined in Okta（Oktaで定義されたネットワークゾーンのいずれにも含まれない）］：Oktaで定義されたネットワークゾーン外のデバイスのみがアプリにアクセスできます。 ［Not in any of the following zones（次のゾーンのいずれにも含まれない）］：指定されたゾーン外のデバイスのみがアプリにアクセスできます。表示されるフィールドに特定のゾーンを入力します。
AND［Risk is（リスクレベル）］	［Any（すべて）］	サインイン試行のリスクスコア許容範囲を構成します。次のいずれかを選択します。 ［Any（すべて）］（デフォルト）：リスクスコアは、低、中、または高です。 ［Low（低）］：リスクスコアは低くする必要があります。 ［Medium（中）］：リスクスコアは中である必要があります。 ［High（高）］：リスクスコアは高くする必要があります。 「リスクスコアリング」を参照してください。
AND［The following custom expression is true（次のカスタム式をtrueとする）］	任意	Okta Expression Language（EL）を使用して追加の条件を構成します。 「デバイスのOkta Expression Language」を参照してください。
AND［Client is（クライアント）］	［Any client（任意のクライアント）］	アプリにアクセスできるクライアントを構成します。次のいずれかを選択します。 ［Any client（任意のクライアント）］（デフォルト）：任意のクライアントがアプリにアクセスできます。 ［One of the following clients（次のいずれかのクライアント）］：指定されたクライアントのみがアプリにアクセスできます。次から1つ以上を選択します。 Webブラウザー 先進認証 Exchange ActiveSync/レガシー認証
THEN［Access is（アクセスの可否）］	［Allowed after successful authentication（認証の成功後に許可）］	前の条件がすべて満たされた場合の結果としてのアプリの権限を構成します。 ［Denied（拒否）］：すべてのIF条件が満たされた場合、デバイスはアクセスを拒否されます。 ［Allowed after successful authentication（認証の成功後に許可）］：すべてのIF条件が満たされて認証が成功した場合に、デバイスはアクセスを許可されます。
AND［User must authenticate with（ユーザーが認証に使用する要素）］	［Any 2 factor types（任意の2つの要素タイプ）］	アプリへのアクセスに必要な認証を構成します。 ［Password（パスワード）］または［Password / IdP（パスワード/IdP）］：ユーザーはルールで再認証が必要になるたびにパスワードを入力する必要があります。 ［Possession factor（所有要素）］：ユーザーは認証のために所有要素を提供する必要があります。たとえば、Okta Verify、WebAuthn、電話、メールなどです。 ［Any 1 factor type（任意の1要素タイプ）］または［Any 1 factor type / IdP（任意の1要素タイプ/IdP）］：ユーザーは所有要素、知識要素、または生体認証要素を提供する必要があります。たとえば、Okta Verify、WebAuthn、電話、メール、パスワード、セキュリティ質問などです。 ［Password + Another factor（パスワード+別の要素）］または［Password / IdP + Another factor（パスワード/IdP+別の要素）］：ユーザーはパスワードとその他の認証要素を提供する必要があります。 ［Any 2 factor types（任意の2要素タイプ）］：ユーザーは任意の2つの認証要素を提供する必要があります。 「多要素認証」を参照してください。
AND［Possession factor constraints are（所有要素の制約）］	次のチェックボックスをオンにします。 ［Hardware protection（ハードウェア保護）］ ［Device bound (excludes phone and email)（デバイスバウンド（電話とメールを除く））］	所有要素の特性を構成します。 ［Phishing resistant（フィッシング耐性）］（デフォルトでオフ）：所有要素をフィッシング耐性にする必要があります。 ［Hardware protected（ハードウェア保護）］（デフォルトでオフ）：ハードウェア格納型のキーストア（TPM、安全なエンクレーブ）にキーを保管する必要があります。 注：デフォルトでは、Okta Verifyはデバイスの安全なハードウェア（WindowsおよびAndroidデバイスの場合はTrusted Platform Module（TPM）、macOSおよびiOSデバイスの場合は安全なエンクレーブ）にOkta Verifyキーを保存しようとします。安全なハードウェアが利用できない場合は、ソフトウェアストレージが使用されます。ソフトウェアストレージを使用する場合、THEN条件のAND［Possession factor restraints are（所有要素の制限）］で［Hardware protection（ハードウェアで保護）］が選択されているときは、Okta Verifyは認証ポリシーを満たしていません。 デバイスに対してOkta Verifyキーがどのように保存されているかを確認するには、Okta Admin ConsoleでsecureHardwarePresentデバイス属性を表示するか、Okta Expression Language（EL）の式を使用してdevice.profile.secureHardwarePresentviewの値を確認します。この値がtrueの場合は、安全なハードウェアが使用されます。 「デバイスのOkta Expression Language」を参照してください。 ［Device Bound (excludes phone and email)（デバイスバウンド（電話とメールを除く））］（デフォルトで選択）：要素キーをデバイスで安全に保管する必要があります。
AND［Access with Okta FastPass is granted（Okta FastPassを使用したアクセスを許可）］	［If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)（ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する（NIST AAL2要件を満たす）場合）］	Okta FastPassを使用したアクセスを許可する場合に構成します。 ［If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)（ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する（NIST AAL2要件を満たす）場合）］（デフォルト）：Okta FastPassを使用して認証する場合、ユーザーは、物理的に存在することを証明する必要があります。 ［Without the user approving a prompt in Okta Verify or providing biometrics（ユーザーがOkta Verifyでプロンプトを承認したり、生体認証を提供したりしない場合）］：ユーザーは、Okta Verifyでプロンプトを承認したり、生体認証を提供したりする必要はありません。 この設定の詳細については、「グローバルセッションポリシールールを追加する」を参照してください。
［Re-authentication frequency is（再認証の頻度）］	［Re-authenticate after（次の期間ごとに再認証）］ ：［1 Hours（1 時間）］	ユーザーの再認証が必要になる頻度を構成します。 ［Every sign-in attempt（すべてのサインイン試行）］：ユーザーはサインインのたびに認証する必要があります。 ［Never re-authenticate if the session is active（セッションがアクティブの場合は再認証しない）］：ユーザーがアクティブなセッション内にある場合は、再認証する必要はありません。 ［Re-authenticate after（次の期間ごとに再認証）］（デフォルト）：指定された時間が経過したらユーザーを再認証する必要があります。デフォルトは2時間です。

3. ［Save（保存）］をクリックします。

ルール2（例）

このルールは、登録済みで非管理対象のデバイスを使用するユーザーに適用されます。これにより、パスワードとその他の認証要素（電話またはメールを除く）を提供した後に、アプリケーションへのアクセスが許可されます。

このルールに一致するユーザーは、パスワードの提供に加えて、登録されている任意の認証要素（電話とメールを除く）を選択できます。このルールでオプション［Okta Verify user interaction（Okta Verifyユーザーインタラクション）］を選択する場合、Okta Verifyを認証要素として選択したユーザーは、ユーザー検証（生体認証）を提供するように求められます。

1. ルール名フィールドに、ルールの名前を入力します。例：登録済み+非管理対象+2つの要素（パスワード、所有）で許可
2. ルール2のガイドとして以下の構成を使用します。

条件	構成	説明
IF［User's user type is（ユーザーのユーザータイプ）］	［Any user type（任意のユーザータイプ）］	「ルール1（例）」を参照してください。
AND［User's group membership includes（ユーザーのグループメンバーシップ）］	［Any group（任意のグループ）］
AND［User is（ユーザー）］	［Any user（任意のユーザー）］
AND［Device state is（デバイスの状態）］	［Registered（登録済み）］
AND［Device management is（デバイス管理）］	［Not managed（非管理対象）］
AND［Device assurance policy（デバイス保証ポリシー）］	［No policy（ポリシーなし）］
AND［Device platform is（デバイスプラットフォーム）］	［Any platform（任意のプラットフォーム）］
AND［User's IP is（ユーザーのIP）］	［Any IP（任意のIP）］
AND［Risk is（リスクレベル）］	［Any（すべて）］
AND［The following custom expression is true（次のカスタム式をtrueとする）］	任意。
AND［Client is（クライアント）］	［Any client（任意のクライアント）］
THEN［Access is（アクセスの可否）］	［Allowed after successful authentication（認証の成功後に許可）］
AND［User must authenticate with（ユーザーが認証に使用する要素）］	［Password + Another factor（パスワード+別の要素）］
AND［Possession factor constraints are（所有要素の制約）］	［Device bound (excludes phone and email)（デバイスバウンド（電話とメールを除く））］チェックボックスを選択します。
AND［Access with Okta FastPass is granted（Okta FastPassを使用したアクセスを許可）］	［If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)（ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する（NIST AAL2要件を満たす）場合）］
［Re-authentication frequency is（再認証の頻度）］	以下を設定します。 ［Password re-authentication frequency is（パスワードの再認証の頻度）］：［4 Hours（4時間）］ ［Re-authentication frequency for all other factors is（ほかのあらゆる要素での再認証の頻度）］：［15 Minutes（15分）］

3. ［Save（保存）］をクリックします。

ルール3（例）

このルールは、ルール1またはルール2に一致しなかったユーザーに適用されます。これは、アプリケーションへのアクセスを拒否するキャッチオールルールです。

1. ［Rule name（ルール名）］フィールドに、ルールの名前を入力します。例：キャッチオールルール

2. ルール3のガイドとして以下の構成を使用します。

条件	構成	説明
IF［User's user type is（ユーザーのユーザータイプ）］	［Any user type（任意のユーザータイプ）］	「ルール1（例）」を参照してください。
AND［User's group membership includes（ユーザーのグループメンバーシップ）］	［Any group（任意のグループ）］
AND［User is（ユーザー）］	［Any user（任意のユーザー）］
AND［Device state is（デバイスの状態）］	［Any（すべて）］
AND［Device assurance policy（デバイス保証ポリシー）］	［No policy（ポリシーなし）］
AND［Device platform is（デバイスプラットフォーム）］	［Any platform（任意のプラットフォーム）］
AND［User's IP is（ユーザーのIP）］	［Any IP（任意のIP）］
AND［Risk is（リスクレベル）］	［Any（すべて）］
AND［The following custom expression is true（次のカスタム式をtrueとする）］	空白のままにします。
THEN［Access is（アクセスの可否）］	［Denied（拒否済み）］

3. ［Save（保存）］をクリックします。

関連項目

• 認証ポリシー
• 認証ポリシールールを追加する
• 認証ポリシーにデバイス保証を追加する