アプリのサインオン・ポリシー・ルールの追加

アプリのサインオン・ポリシーは、エンド・ユーザーがアプリにサインインしようとするときに認証要件を適用します。組織の各アプリにはすでにサインオン・ポリシーが設定されており、そのポリシーにルールを追加してアクセスのレベルをカスタマイズすることができます。

たとえば、デフォルトのすべてのOktaユーザーにはパスワードの提供を要求し、指定されたグループのすべてのOktaユーザーにはオーセンティケーターとしてパスワードとメールの両方の提供を要求することができます。 その場合は、デフォルト・ユーザーにパスワードのみの提供を要求する1つのルールを作成してから、指定されたグループのすべてのメンバーにパスワードとメールのオーセンティケーターの提供を要求する2つ目のルールを作成します。

ルールが評価される順序は、ポリシー・ページのルールの順序と一致します。ルールを追加しない場合、アプリはデフォルトのキャッチオール・ルールに対して認証されます。

ユーザーがIDプロバイダーを使用してOktaにサインインする場合の手順については、IDプロバイダーでアプリのサインオン・ポリシー・ルールを追加するを参照してください。

ユーザーがIDプロバイダーを使用してOktaにサインインしない場合は、このページの手順に従ってアプリのサインオン・ポリシー・ルールを追加してください。

アプリのサインオン・ポリシー・ルールの追加

  1. 管理コンソールで、[アプリケーション]>[アプリケーション]に移動します。
  2. サインオン・ポリシー・ルールを作成するアプリを選択します。
  3. アプリケーションのメイン・ページで、[サインオン]タブをクリックします。
  4. [サインオン・ポリシー]セクションまでスクロールしてから、[ルールを追加]をクリックします。
  5. [ルール名]を入力します。
  1. IF条件を構成します。これらの条件では、どのような場合にルールを適用するのかを指定します。
    IF説明
    IFユーザーのユーザー・タイプデフォルトでは、ルールはアプリに割り当てられたすべてのユーザー・タイプに適用されます。デフォルトを受け入れるか、範囲に含めるおよび除外するユーザー・タイプを指定します。
    ANDユーザーのグループ・メンバーシップデフォルトでは、ルールはアプリに割り当てられたすべてのグループに適用されます。デフォルトを受け入れるか、範囲に含めるおよび除外するユーザー・グループを指定します。
    ANDユーザー:デフォルトでは、ルールはアプリに割り当てられたすべてのユーザーに適用されます。デフォルトを受け入れるか、範囲に含めるユーザーと除外するユーザーを指定します。

    ANDユーザーのIP:デフォルトでは、ルールはすべてのIPに適用されます。デフォルトを受け入れるか、ネットワーク・ゾーンを選択します。Oktaで定義済みのゾーンや未定義のゾーンで並べ替えたり、特定のゾーンを構成したりすることが可能です。
    ANDデバイスの状態デフォルトでは、ルールはどの状態のデバイスにも適用されます。デフォルトを受け入れるか、[登録済み]を選択して、Okta Verifyに登録されているデバイスにのみこのルールを適用します。デバイスの登録を参照してください。
    ANDデバイス管理[登録済み]デバイスの状態を選択した場合、サード・パーティーのデバイス管理ソリューションによって管理されるデバイスにのみルールが適用されるかどうかを示します。
    ANDデバイス・プラットフォーム:デフォルトでは、ルールはすべてのプラットフォームに適用されます。デフォルトを受け入れるか、特定のプラットフォームを選択してください。
    ANDリスクは次のとおりです:デフォルトでは、このルールはあらゆるリスク・レベルの認証試行に適用されます。ルールを選択すると、指定したリスク・レベルのみにルールが制限されます。 リスク・スコアリングを参照してください。
    AND次のカスタム式をtrueとするオプションです。式言語(EL)を使用して追加の条件を指定します。挙動とサインオン・ポリシーについて「Okta式言語」
  2. を参照してください。
  1. THEN条件を構成します。これらの条件では、認証を適用する方法を指定します。
    THEN説明
    THENアクセスは次のとおりです:ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。
    ANDユーザーが次で認証する必要があります:アプリへのアクセスに適用する認証要件を選択します。要素タイプの説明については、オーセンティケーターの構成を参照してください。
    1要素タイプ:
    1要素認証を有効化するには、次から選択します。
    • パスワードでは、ルールで再認証が必要になるたびにユーザーがパスワードを入力する必要があります。
    • 所有要素では、アプリにアクセスするために、ユーザーがOkta Verifyやメールなどの所有要素を提供する必要があります。
    • 任意の1要素タイプを使用すると、ユーザーは任意の単一要素を指定してアプリにアクセスできます。
    • パスワードなしの1要素認証オプションについては、パスワードなしの認証を構成するを参照してください。
    2要素タイプ:ユーザーに2つの異なる要素タイプの提供を要求する場合に選択します。次から選択します。
    • パスワード+別の要素
    • 任意の2つの要素タイプ
    • パスワードなしの2要素認証オプションについては、Okta FastPassを構成する を参照してください。
    AND所有要素の制限[ユーザーが次で認証する必要があります:][パスワード]のみが選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。
    • フィッシング耐性:ログイン・サーバー(オリジン)を暗号で検証する所有要素の提供をユーザーに要求します。現在、FIDO2(WebAuthn)のみがこの要件を満たしています。フィッシング耐性はデバイス・バウンドを意味するため、[フィッシング耐性]を選択すると、その制約が自動的に選択されます。
    • ハードウェアで保護:認証に使用されるキーがデバイスのセキュア・ハードウェア(TPM、安全なエンクレーブ)に保存されている必要があります。現在、Okta Verifyのみがこの制約を満たしています。ハードウェアで保護はデバイス・バウンドを意味するため、[ハードウェアで保護]を選択すると、その制約が自動的に選択されます。
    • デバイス・バウンド(電話とメールを除く):要素のキーをデバイスに安全に保管するよう求め、要素を再登録せずに別のデバイスに転送できないようにします。デバイス・バウンドでない所有要素は、メールとSMSだけです。ほかの制約のいずれかが選択されている場合、この制約は自動的に選択されます。
    ANDOkta FastPassを使用したアクセスを許可これらのオプションでは、Okta FastPassを使用して認証する際に、エンド・ユーザーが物理的に存在していることの証明を要求するかどうかを選択できます。
    • ユーザーがOkta Verifyでプロンプトを承認するか、生体認証(NIST AAL2の要件を満たす)を提供する場合、
    このオプションでは、ユーザーが物理的に存在することを証明する必要があります。
    • ユーザーがOkta Verifyでプロンプトを承認したり生体認証を提供したりしない場合
    このオプションが選択されていて、アプリ・サインオン・ポリシーで所有要素が必要であれば、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようになります。このオプションはNIST AAL2の要件を満たしていません。さらに、このオプションを選択した場合、セキュリティー上の質問を追加の要素として使用することはできません。
    再認証の頻度この設定では、エンド・ユーザーが再認証する必要がある頻度を指定できます。
    • サインイン試行の都度: ユーザーはアプリにアクセスするたびに再認証する必要があります。
    • デバイスごとに1回:ユーザーがデバイスから認証されると、セッションのライフタイムに達するか、Oktaからサインアウトするまで、再認証のプロンプトは表示されません。
    • 再認証を求めるまでの時間:エンド・ユーザーが再認証する必要がある頻度を指定します。ユーザーがアプリへのアクセスを試行し、指定した時間間隔内に再認証されておらず、セッションの有効期限が切れていない場合にのみ再認証を求められます。
    :ユーザーがパスワードで認証した後、10秒間の猶予期間が適用されます。[サインイン試行の都度]が選択されている場合は、この猶予期間中に再度パスワードの入力を求められることはありません。
    パスワードの再認証の頻度これら2つのオプションは、[パスワード+別の要素]が選択されている場合にのみ表示されます。パスワードやそのほかの要素に対して、異なる再認証間隔を指定できます。たとえば、最後に認証されてから8時間以上経過している場合はパスワードを使用し、アプリにアクセスするたびに所有要素を使用して再認証するようにユーザーに要求できます。
    ほかのあらゆる要素での再認証の頻度
  2. [保存]をクリックします。

アプリのサインオン・ポリシーを更新する

  1. 管理コンソールで、[アプリケーション] > に移動します。 [アプリケーション]
  2. サインオン・ポリシー・ルールを管理するアプリを選択します。
  3. アプリケーションのメイン・ページで、[サインオン]タブをクリックします。
  4. [サインオン・ポリシー]セクションでは、次のことができます。
    • [そのほかのオプション]メニューをクリックし[編集]を選択して、ルールの条件を変更します。
    • [そのほかのオプション]メニューをクリックし、[非アクティブ化]を選択して、ルールを非アクティブ化します。
    • [そのほかのオプション]メニューをクリックし、[非アクティブ化]を選択してから、[削除]を選択して、ルールを削除します。
    • ルールをドラッグ・アンド・ドロップして、優先度を並べ替えます。

アプリのサインオン・ポリシー・ルールを定義して保存すると、そのポリシー用に構成されたアクティブなルールのプレビューが表示されます。

注

含まれているすべてのユーザーまたはグループが削除された場合、ルールは自動的に非アクティブ化されます。

アプリのサインオン・ポリシーのセキュリティー上の質問

セキュリティー上の質問によるオーセンティケーターでは、エンド・ユーザーに対して、提示される質問のリストから選択した質問に対する正しい回答を入力するように求めます。

セキュリティー上の質問によるオーセンティケーター:

  • 認証(MFA/SSO)とユーザーのパスワード復旧シナリオをサポートしています。MFA/SSOに対して無効になっている場合、サインオン・ポリシーの評価に含まれることはありません。
  • パスワードがプライマリ要素として使用される場合、特にユーザーのOktaサインオン・ポリシーのプライマリ要素がパスワード/IDPの場合、ステップアップ認証または追加の検証として使用できます。Oktaでは、どの認証フローでもセキュリティー上の質問を使用しないことを推奨しています。

このオーセンティケーターは、アカウント復旧にのみ使用するか、認証とアカウント復旧の両方に使用するように構成できます。復旧オプションを選択した場合、サインオン・ポリシーの評価中に認証が要求されることはありません。

たとえば、ユーザーに対してOkta FastPassを有効化する、つまり、 ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようにする場合、セキュリティー上の質問を追加の要素として使用することはできません。詳しくは、 アプリのサインオン・ポリシー・ルールの追加. 管理者がエンド・ユーザーにセキュリティー上の質問を使用してもらいたい場合は、Oktaサインオン・ポリシーの[パスワード/ IdP]オプションを使用する必要があります。

関連項目

アプリのサインオン・ポリシー

Oktaのサインオン・ポリシー

パスワードなしの認証を構成する

セキュリティー上の質問によるオーセンティケーターの構成