アプリサインインポリシールールを追加する

アプリ・サインイン・ポリシーはルールに基づいて構築されます。アプリ・サインイン・ポリシーを作成する際は、任意の2つの要素タイプを持つすべてのリクエストに対してアクセスを許可する、単一のキャッチオールルールから開始します。ルールを追加し、それらをキャッチオールよりも優先させて、Authenticatorの要件を構成します。

たとえば、すべてのユーザーにパスワードを求める1つのルールを追加できます。その上で、特定ループのユーザーにメールとパスワードのAuthenticatorを求める第2のルールを追加できます。

開始する前に

Authenticatorをセットアップする

アプリサインインポリシーを作成する

ポリシーにルールを追加する

  1. Admin Consoleでセキュリティ（Security） > 認証ポリシー に移動します。

  2. アプリのサインイン（App sign-in）をクリックします。
  3. ルールを追加するポリシーを選択します。
  4. ルール（Rules）タブでルールを追加（Add rule）をクリックします。
  5. ルール名（Rule Name）（Rule name）を入力します。
  6. IF条件を構成します。これらの条件では、どのような場合にルールを適用するのかを指定します。
    IF 説明
    IFユーザーのユーザータイプ（IF User's user type is） デフォルトを受け入れるか、対象に含めるユーザータイプと除外するユーザータイプを指定します。
    ANDユーザーのグループメンバーシップ（AND User's group membership includes） デフォルトを受け入れるか、対象に含めるユーザーグループと除外するユーザーグループを指定します。
    ANDユーザー（AND User is） デフォルトを受け入れるか、対象に含めるユーザーと除外するユーザーを指定します。
    ANDデバイスの状態（AND Device state is） デフォルトを受け入れるか、登録済み（Registered）を選択して、Okta Verifyに登録されているデバイスにのみこのルールを適用します。デバイス登録を参照してください。
    ANDデバイス管理（AND Device management is）

    登録済み（Registered）デバイスの状態を選択した場合、サードパーティのデバイス管理ソリューションによって管理されるデバイスにのみルールが適用されるかどうかを示します。

    デバイスシグナル収集ルールを使用する場合、この選択用にルールを追加します。デバイスシグナル収集ルールを作成するを参照してください。
    ANDデバイス保証ポリシー（AND Device assurance policy is）

    登録済み（Registered）デバイスの状態を選択した場合、満たされるべきデバイス保証ポリシーを指定できます。デバイス保証ポリシーを追加するを参照してください。

    デバイスシグナル収集ルールを使用する場合、この選択用にルールを追加します。デバイスシグナル収集ルールを作成するを参照してください。
    ANDデバイスプラットフォーム（AND Device platform is） デフォルトを受け入れるか、特定のプラットフォームを選択してください。
    ANDユーザーのIP（AND User's IP is） デフォルトを受け入れるか、対象に含めたいネットワークゾーンと除外したいネットワークゾーンを指定します。Oktaで定義されているまたは定義されていないゾーン、あるいは動的ゾーンでソートできます。

    ゾーンを指定する場合には、IPが動的であり、IPの地理位置情報が保証されないことに注意してください。場所のみに依存してアクセスを拒否するポリシーは作成しないでください。

    ANDリスクレベル（AND Risk is） デフォルトでは、このルールはどのリスクレベルの認証試行にも適用されます。レベルを選択すると、指定したリスクレベルのみにルールが制限されます。「リスクスコアリング」を参照してください。
    AND次のカスタム式をtrueとする（AND The following custom expression is true） 任意。式言語（EL）を使用して追加の条件を指定します。「動作とサインオンポリシーについて」と「Okta Expression Language」を参照してください。

  7. THEN条件を構成します。これらの条件は、認証の適用方法を指定します。

    THEN 説明
    THENアクセスの可否（THEN Access is）

    ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。

    • 拒否（Denied）：構成した条件をユーザーが満たす場合にアクセスを拒否します。アクセス拒否を選択する場合、最後の手順までスキップしてルールを保存してください。
    • 認証の成功後に許可（Allowed after successful authentication）：構成した条件をユーザーが満たす場合にアクセスを許可します。

    ANDユーザーが指定する必要があるもの（AND User must provide）

    この項目は、ルールの設定をJSONコードで表示します。これは、次のオプションを選択した場合に表示されます。

    • THENアクセス：（THEN Access is）（Allowed after successful authentication）の認証の成功後に許可（Allowed after successful authentication）（THEN Access is）
    • ANDユーザーが使用する認証方法（AND User must authenticate with）（Any 1 factor type）の任意の1要素タイプ（Any 1 factor type）（Any 1 factor type / IdP）または任意の1要素タイプ/IdP（Any 1 factor type / IdP）（AND User must authenticate with）
    • AND要素の制限（AND Factor restraints are）の任意の所有制約
    ANDユーザーが認証に使用する要素（AND User must authenticate with）

    アプリへのアクセスに強制適用する認証要件を選択します。要素タイプの説明については、多要素認証を参照してください。

    これらの認証オプションの横に IdP が表示されるときは、グローバルセッションポリシーでパスワード要件を満たすことができるIDプロバイダー（IdP）が指定されています。指定されたIdPを介して認証するユーザーは、パスワードを入力する必要もありません。

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

    orgで同一のAuthenticatorに複数のインスタンスがある場合、ポリシーで特定のAuthenticatorインスタンスを許可することができます。このAuthenticatorインスタンスは、ユーザーがサインインする際に表示されます。たとえば、2つのDuo Securityインスタンスが構成されている場合には、どちらのインスタンスがユーザーに促されるのかを選ぶことができます。ユーザーがAuthenticatorインスタンスにまだ登録していない場合には、次回の認証試行で登録が促されます。

    同様に、ポリシーを使って特定のAuthenticatorインスタンスを許可しないこともできます。このインスタンスは、ユーザーが次回サインインする際に利用できなくなります。ポリシーのルールで1つのAuthenticatorインスタンスを許可や不許可にしても、他のAuthenticatorインスタンスには影響しません。

    ただし、汎用のIdP Authenticatorを許可や不許可にした場合には、すべてのIdP Authenticatorインスタンスが許可または不許可になります。

    1要素タイプ（1 factor type）：1要素認証を有効にするには、次のいずれかのオプションを選択します。

    • パスワード（Password）またはパスワード/IdP（Password / IdP）では、ルールで再認証が必要になるたびにパスワードを入力する必要があります。このオプションを選択すると、要素の制限（Factor restraints are）オプションが使用できなくなります。
    • 所有要素（Possession factor）では、アプリにアクセスするために、ユーザーがOkta Verifyやメールなどの所有要素を提供する必要があります。
    • 任意の1要素タイプ（Any 1 factor type）または任意の1要素タイプ/IdP（Any 1 factor type / IdP）を使用すると、ユーザーは任意の単一要素を提供してアプリにアクセスできます。このオプションを選択すると、要素の制限（Factor restraints are）オプションが使用できなくなります。

    パスワードレスの1要素認証オプションを設定するには、「パスワードレスサインインエクスペリエンスをセットアップする」を参照してください。

    2要素タイプ（2 factor types）：ユーザーに2つの個別の要素タイプの提供を要求するには、以下のいずれかのオプションを選択します。

    • パスワード+別の要素（Password + Another factor）またはパスワード/IdP+別の要素（Password / IdP + Another factor）
    • 任意の2要素タイプ（Any 2 factor types）

    パスワードレスの2要素認証オプションについては、パスワードレス認証を参照してください。

    認証方法チェーン（Authentication method chain）：複数の認証方法を指定の順序で使用して検証を行うことをユーザーに求めます。認証方法チェーン（Authentication method chain）を参照してください。
    AND所有要素の制約（AND Possession factor constraints are） パスワード（Password）、任意の1要素タイプ（Any 1 factor type）、または任意の1要素タイプ/IdP（Any 1 factor type / IdP）を選択した場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。
    • フィッシング耐性（Phishing-resistant）：サインインサーバー（オリジン）を暗号で検証する所有要素の提供をユーザーに要求します。Okta Verifyのパスキー（FIDO2 WebAuthn）とOkta FastPassのオプションは、この要件を満たします。詳細については、多要素認証を参照してください。
    • ハードウェアで保護（Hardware protection）：認証に使用されるキーがデバイスのセキュアハードウェアに保存されている必要があります。WindowsデバイスとAndroidデバイスでは、TPMを使用します。macOSデバイスとiOSデバイスでは、Secure Enclaveを使用します。

      一部のWebAuthn Authenticatorはハードウェア保護されています。Oktaでは、WebAuthn Authenticatorがハードウェア保護されているかどうかはFIDO Alliance Metadata Service（MDS）を使って判断されます。いずれかのkeyProtection値がhardwareであれば、Authenticatorはハードウェア保護と見なされます。

      ハードウェア保護されたWebAuthn Authenticatorにはいつかの制限事項が適用されます。

      • 2022年11月30日以前に行われた登録はサポートされません。
      • FIDO U2Fを使った登録はサポートされません。
      • Firefoxでの登録は現在サポートされません。
      • ユーザー検証（User Verification）が非推奨（Discouraged）に設定され、セキュリティキーにPINが設定されている場合、Chromeでの登録は現在サポートされません。
      • 登録時に求められる場合、ユーザーはセキュリティキーのメーカーとモデルの確認をOktaに許可する必要があります。
    • ユーザー操作を要求する（Require user interaction）：このオプションでは、ユーザーに対し、認証の際に自分が物理的に存在することを証明するよう要求するかどうかを選択できます。

      このオプションが選択されておらず、アプリ・サインイン・ポリシーが所有要素を必要とする場合、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーは物理的に存在することを証明せずにリソースにアクセスできるようになります。

      このオプションが選択されていない場合、セキュリティ質問を追加要素として使用できません。

    • PINまたは生体認証によるユーザー検証を要求する（Require PIN or biometric user verification）：このオプションは、ユーザー操作を要求する（Require user interaction）をクリックすると表示されます。PINを入力するか、生体認証を使って本人確認を行うようにユーザーに求めます。

      このオプションを選択した場合、ユーザーは自分の存在を証明するAuthenticator（プッシュありOkta Verify）、パスキー（FIDO2 WebAuthn）、Okta FastPass、カスタムAuthenticator、またはスマートカード（PIN付き））を使用して本人確認を行う必要があります。これらの各ユーザーの存在Authenticatorがユーザー検証を求めるように構成してください。こうすることで、ユーザーがロックアウトされるのが防止されるとともに、これらのAuthenticatorの新しい登録がユーザー検証要件を満たすことが保証されます。

      Authenticatorがユーザー検証を求めるように構成する：

      1. セキュリティ（Security） > Authenticatorに移動します。
      2. セットアップ（Setup）タブをクリックします。
      3. 構成するAuthenticatorのアクション（Actions） > 編集（Edit）をクリックします。
      4. プッシュあり（Okta Verify）、パスキー（FIDO2 WebAuthn）、カスタムAuthenticator、Okta FastPassの場合は、ユーザー検証（User verification）セクションのドロップダウンメニューで必須（Required）を選択します。スマートカードの場合は、PINを選択します。

      ユーザー検証を満たすAuthenticatorへのユーザー登録を要求します。Authenticator登録ポリシーを作成するを参照してください。Authenticator（Authenticators）セクションで、各ユーザーの存在Authenticatorを必須（Required）に設定します。

    AND認証方法（AND Authentication methods）

    認証方法としてパスワード（Password）が選択されている場合、これらのオプションは使用できません。

    • 要件を満たすために使用できる任意の方法を許可（Allow any method that can be used to meet the requirement）：ユーザーは、要件が満たされる利用可能な任意の方法を認証に使用できます。

    • 特定の認証方法を拒否（Disallow specific authentication methods）：認証での使用から除外する方法を選択します。このオプションを選択した場合、拒否リストに追加されていない限り、利用可能なすべての方法は許可されます。

    • 特定の認証方法を許可（Allow specific authentication methods）：認証での使用を許可する方法を選択します。このオプションを選択した場合、許可リストに追加されていない限り、利用可能なすべての方法は拒否されます。
    サインインしたままにするオプション（Option to stay signed in） この設定をすると、ユーザーがこのアプリで認証した後に、サインイン状態を維持する（Keep me signed in）プロンプトが表示されるようになります。この選択によってプロンプトの表示が制御されますが、本機能がこのアプリだけに制限されるわけではありません。 サインイン状態を維持する（Keep me signed in）は、すべてのアプリで保持されるグローバル設定です。サインインしたままにする（Keep me signed in）を参照してください。

    ユーザーの現在のデバイスで過去に表示されていなかった場合に表示（Show when not previously shown on the user's current device in the past）

    		サインインしたままにするオプション（Option to stay signed in）を選択した場合には、サインインしたままにする（Keep me signed in）プロンプトが再び表示されるまでの経過時間を指定します。この設定はプロンプトのみに適用され、MFAライフライム設定とは別途です。
    認証のプロンプト（Prompt for authentication） このオプションは、認証に1要素タイプ（1 factor type）または任意の2要素タイプ（Any 2 factor types）のオプションを必須とした場合に表示されます。ユーザーが認証しなければならない頻度を示します。
    • ユーザーがリソースにサインインするたび（Every time user signs in to resource）：ユーザーは、アプリへのアクセスを試みるたびに認証する必要があります。これは、最も安全なオプションです。
    • アクティブなOktaグローバルセッションによって保護されるリソースにユーザーがサインインしてから指定の時間が経過した場合（When it's been over a specified length of time since the user signed in to any resource protected by the active Okta global session）：指定した間隔が経過すると、ユーザーは認証を求められます。
    • Oktaグローバルセッションが存在しない場合（When an Okta global session doesn't exist）：アクティブなOktaグローバルセッションを確立していない場合、ユーザーは認証を求められます。
    パスワード認証のプロンプト（Prompt for password authentication）

    および

    認証のその他すべての要素のプロンプト（Prompt for all other factors of authentication）

    		これらのオプションは、認証にパスワード+別の要素（Password + Another Factor）またはパスワード/IdP+別の要素（Password / IdP + Another factor）を必須にした場合に表示されます。パスワードとその他要素の頻度の間隔を選択します。
  8. 保存（Save）をクリックします。
  9. アプリ・サインイン・ポリシーの一部でデバイスシグナルを使用する方法は、デバイスシグナル収集ルールを作成するを参照してください。

ポリシーにルールを追加した後の次の手順は、そのポリシーを1つ以上のアプリに適用することです。ポリシーを共有できるアプリの数に制限はありません。

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

秘密の質問によるAuthenticatorでは、エンドユーザーに対して、提示される質問のリストから選択した質問に対する正しい回答を入力するように求めます。

  • 秘密の質問によるAuthenticatorは、認証（MFA/SSO）とユーザーのパスワード復旧シナリオをサポートしています。MFA/SSOに対して無効になっている場合は、アプリ・サインイン・ポリシーまたはグローバルセッションポリシーの評価に組み込まれます。
  • ユーザーのグローバルセッションポリシーのプライマリ要素がパスワード（A password）の場合、秘密の質問によるAuthenticatorをステップアップまたは追加の検証として使用できます。認証フローではセキュリティ質問を使用しないでください。

このAuthenticatorをアカウント復旧にのみ使用する、または認証とアカウント復旧の両方に使用するようにOktaを構成できます。復旧オプションのみを選択した場合は、グローバルセッションポリシーの評価中にOktaが認証を要求することはありません。

ユーザーが物理的に存在していることを証明せずにOkta FastPassにユーザーアクセスの付与を許可する場合、追加の要素としてセキュリティ質問を使用することはできません。セキュリティ質問の使用をユーザーに求めるには、グローバルセッションポリシーのA password（パスワード）オプションを使用する必要があります。

制限事項

  • ユーザーがFirefoxまたはOperaブラウザーでリソースにアクセスする場合、アプリ・サインイン・ルールではChromeBookはChromeOSプラットフォームとして認識されません。

  • ChromeOSではOkta Verifyを利用できないため、このオペレーティングシステムではOkta FastPassはサポートされません。Okta FastPassを使用したアクセスを許可（Access with Okta FastPass is granted）条件は、ChromeOSをチェックするルールには影響しません。

  • ユーザーがChromeOSデバイスからサインインした場合、デバイスレコードは作成されません。

  • カスタム式ではChromeOSを使用できません。

次の手順

デバイスシグナル収集ルールを作成する

アプリをアプリサインインポリシーに割り当てる

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