認証ポリシールールを追加する

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

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

開始する前に

Authenticatorをセットアップする

認証ポリシーを作成する

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

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

  2. ルールを追加するポリシーを選択します。
  3. ［Rules（ルール）］タブで、［Add Rule（ルールを追加）］をクリックします。
  4. ［Rule Name（ルール名）］を入力します。
  5. IF条件を構成します。これらの条件では、どのような場合にルールを適用するのかを指定します。
    IF説明
    IF［User's user type is（ユーザーのユーザータイプ）］デフォルトを受け入れるか、対象に含めるユーザータイプと除外するユーザータイプを指定します。
    AND［User's group membership includes（ユーザーのグループメンバーシップ）］デフォルトを受け入れるか、対象に含めるユーザーグループと除外するユーザーグループを指定します。
    AND［User is（ユーザー）］デフォルトを受け入れるか、対象に含めるユーザーと除外するユーザーを指定します。
    AND［Device state is（デバイスの状態）］デフォルトを受け入れるか、［Registered（登録済み）］を選択して、Okta Verifyに登録されているデバイスにのみこのルールを適用します。「デバイス登録」を参照してください。
    AND［Device management is（デバイス管理）］［Registered（登録済み）］デバイスの状態を選択した場合、サードパーティのデバイス管理ソリューションによって管理されるデバイスにのみルールが適用されるかどうかを示します。
    AND［Device assurance policy（デバイス保証ポリシー）］［Registered（登録済み）］デバイスの状態を選択した場合、満たされるべきデバイス保証ポリシーを指定できます。「デバイス保証ポリシーを追加する」を参照してください。
    AND［Device platform is（デバイスプラットフォーム）］デフォルトを受け入れるか、特定のプラットフォームを選択してください。
    AND［User's IP is（ユーザーのIP）］デフォルトを受け入れるか、対象に含めたいネットワークゾーンと除外したいネットワークゾーンを指定します。Oktaで定義されているまたは定義されていないゾーン、あるいは動的ゾーンでソートできます。

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

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

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

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

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

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

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

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

    • THEN［Access is（アクセス：）］の［Allowed after successful authentication（認証の成功後に許可）］
    • AND［User must authenticate with（ユーザーが使用する認証方法）］の［Any 1 factor type（任意の1要素タイプ）］または［Any 1 factor type / IdP（任意の1要素タイプ/IdP）］
    • AND［Possession factor restraints are（所有要素の制限）］の任意の所有制約
    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 factor type（1要素タイプ）］：1要素認証を有効にするには、次のいずれかのオプションを選択します。

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

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

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

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

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

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

      Okta Verifyがデバイスの安全なハードウェアにキーを保存できない場合は、ソフトウェアストレージを使用します。WindowsデバイスとAndroidデバイスでは、TPMを使用します。macOSデバイスとiOSデバイスでは、Secure Enclaveを使用します。その場合、Okta VerifyはHardware protection（ハードウェア保護）の要件を満たしません。

      デバイスのOkta Verifyキーの保存方法を特定するには、Admin ConsoleでsecureHardwarePresentデバイス属性を確認します。また、Okta Expression Language（EL）式を使ってdevice.profile.secureHardwarePresentviewの値を調べることもできます。この値がtrueであれば、安全なハードウェアが使用されます。

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

      一部の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で証明書ベースの認証を実行できます。これにより、ユーザーは物理的に存在することを証明せずにリソースにアクセスできるようになります。

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

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

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

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

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

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

      ユーザーがすでにAuthenticatorに登録しているものの、そのAuthenticatorでユーザー検証オプションをアクティブ化（Okta Verifyでの顔または指紋スキャンの有効化など）していない場合、認証することはできません。ユーザーは、これらの登録をリセットして新しい登録に置換するか、Okta Verifyでプッシュ通知または生体検証をアクティブ化する必要があります。

    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（サインインしたままにする）］プロンプトを表示します。「サインインしたままにする」を参照してください。

    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 factor type（1要素タイプ）］または［Any 2 factor types（任意の2要素タイプ）］を必須とした場合に表示されます。ユーザーが認証しなければならない頻度を示します。
    • ［Every time user signs in to resource（ユーザーがリソースにサインインするたび）］：ユーザーは、アプリへのアクセスを試みるたびに認証する必要があります。これは、最も安全なオプションです。
    • ［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グローバルセッションが存在しない場合）］：アクティブなOktaグローバルセッションを確立していない場合、ユーザーは認証を求められます。

    ユーザーの認証後に10秒間の猶予期間が適用されます。［Every time user signs in to resource（ユーザーがリソースにサインインするたび）］を選択した場合、この猶予期間中に再度認証を求められることはありません。
    Prompt for password authentication（パスワード認証のプロンプト）

    および

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

    		 これらのオプションは、認証に［Password + Another Factor（パスワード+別の要素）］または［Password / IdP + Another factor（パスワード/IdP+別の要素）］を必須にした場合に表示されます。パスワードとその他要素の頻度の間隔を選択します。

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

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

認証ポリシーのセキュリティ上の質問

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

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

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

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

制限事項

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

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

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

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

次の手順

認証ポリシーにアプリを追加する

認証ポリシーをアップデートする