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

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

強力な認証ポリシーを構成して各アプリを保護する

Okta FastPassを構成する場合は、グローバルセッションポリシーからデフォルトのグローバルパスワード要件を削除してください。この変更により、グローバルセッションポリシーから認証基準を定義して適用する責任がなくなり、その責任は各認証ポリシーに移管されます。グローバルセッションポリシーでこのグローバル要件を削除する前に、強力な認証ポリシーを使用してすべてのアプリを保護してください。

Okta Classic EngineからOkta Identity Engineにアップグレードした後は、エンドユーザーのユーザー検証エクスペリエンスが変わります。Okta Classic Engineで、認証ポリシーが2つの認証要素(たとえば、[Password + Another Factor(パスワード+別の要素)]、または[Any 2 factor types(任意の2つの要素タイプ)])で構成されている場合、Okta Verifyのユーザーは2つの認証要素を提供する必要があります(たとえば、パスワードを入力し、Okta Verifyのプッシュ通知を受け入れるなど)。Okta Identity Engineにアップグレードした場合、同じ認証ポリシーは存在しますが、ユーザーエクスペリエンスは変わります。現在(以前から同じ例を使用)、ユーザーは、生体認証によるOkta Verifyのプッシュのみを提供してアクセスできるようになっています。これは予想される動作です。デバイスのロックを解除するためにユーザーが生体認証を提供した場合、認証ポリシーがそれを最初の認証要素として評価するためです。

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

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

  1. Okta Admin Consoleで、[Security(セキュリティ)]>[Authentication Policies(認証ポリシー)]に移動します。
  2. 更新するポリシーを選択します。
  3. [Rules(ルール)]タブをクリックします。
  4. [Add Rule(ルールを追加)]をクリックします。
  5. 認証ポリシールールを作成します。
  6. 認証ポリシールールを設定するときは、ガイドとして「ルール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のガイドとして以下の構成を使用します。
    3. 条件 構成 説明
      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 platform is(デバイスプラットフォーム)] [Any platform(任意のプラットフォーム)] アプリへのアクセスに必要なデバイスプラットフォームを構成します。次のいずれかを選択します。
      • [Any platform(任意のプラットフォーム)](デフォルト):任意のデバイスプラットフォームがアプリにアクセスできます。

      • [One of the following platforms(次のプラットフォームのいずれか)]:指定されたデバイスプラットフォームのみがアプリにアクセスできます。このオプションを選択したときに表示されるリストから、次のうち1つ以上を選択します。

        • IOS

        • ANDROID

        • WINDOWS

        • MACOS

        • 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式言語(EL)を使用して追加の条件を構成します。

      「デバイスのOkta式言語」を参照してください。

      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つの認証要素を提供する必要があります。

      「MFAオーセンティケーターについて」を参照してください。

      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式言語(EL)の式を使用してdevice.profile.secureHardwarePresentviewの値を確認します。この値がtrueの場合は、安全なハードウェアが使用されます。

        「デバイスのOkta式言語」を参照してください。

      • [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時間です。

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

    ルール2(例)

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

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

    1. [Rule name(ルール名)]フィールドに、ルールの名前を入力します。例:登録済み+非管理対象+2つの要素(パスワード、所有)で許可
    2. ルール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(デバイスの状態)] [Registered(登録済み)]
      AND[Device management is(デバイス管理)] [Not managed(非管理対象)]
      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分)]

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

    ルール3(例)

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

    1. [Rule name(ルール名)]フィールドに、ルールの名前を入力します。例:キャッチオールルール

    2. ルール3のガイドとして以下の構成を使用します。
    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 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(拒否済み)]
    4. [Save(保存)]をクリックします。

関連項目