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

認証ポリシーはルールに基づいて構築されます。認証ポリシーを作成する際は、任意の2つの要素タイプを持つすべてのリクエストに対してアクセスを許可する、単一のキャッチオールルールから開始します。ルールを追加し、それらをキャッチオールよりも優先して、オーセンティケーターの要件を構成します。たとえば、すべてのユーザーにパスワードを求めるプロンプトを表示する1つのルールを追加してから、特定のグループのユーザーにメールとパスワードのオーセンティケーターを求めるプロンプトを表示する2つ目のルールを追加することができます。

開始する前に

オーセンティケーターをセットアップする

認証ポリシーを作成する

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

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

  2. ルールを追加するポリシーを選択します。
  3. ［Rules（ルール）］タブで、［Add Rule（ルールを追加）］をクリックします。
  4. ［Rule Name（ルール名）］を入力します。
  1. 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 platform is（デバイスプラットフォーム）］デフォルトを受け入れるか、特定のプラットフォームを選択してください。
    AND［User's IP is（ユーザーのIP）］デフォルトを受け入れるか、対象に含めたいネットワークゾーンと除外したいネットワークゾーンを指定します。Oktaで定義されているまたは定義されていないゾーン、あるいは動的ゾーンでソートできます。
    AND［Risk is（リスクレベル）］デフォルトでは、このルールはどのリスクレベルの認証試行にも適用されます。レベルを選択すると、指定したリスクレベルのみにルールが制限されます。「リスクスコアリング」を参照してください。
    AND［The following custom expression is true（次のカスタム式をtrueとする）］任意。式言語（EL）を使用して追加の条件を指定します。「行動とサインオンポリシーについて」と「Okta式言語」を参照してください。

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

    THEN 説明
    THEN［Access is（アクセスの可否）］ ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。
    AND［User must authenticate with（ユーザーが認証に使用する要素）］

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

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

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

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

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

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

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

    パスワードなしの2要素認証オプションについては、「Okta FastPassを構成する」を参照してください。
    AND［Factor restraints are（要素の制限）］ ［User must authenticate with（ユーザーが認証に使用する要素）］で［Password（パスワード）］が選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。
    • ［Phishing-resistant（フィッシング耐性）］：サインインサーバー（オリジン）を暗号で検証する所有要素の提供をユーザーに要求します。FIDO 2（WebAuthn）とOkta VerifyのOkta FastPassオプションはこの要件を満たします。詳細については、「MFAオーセンティケーターについて」を参照してください。フィッシング耐性はデバイスバウンドを意味するため、［Phishing-resistant（フィッシング耐性）］を選択すると、その制約が自動的に選択されます。
    • ［Hardware protection（ハードウェアで保護）］：認証に使用されるキーがデバイスのセキュアハードウェア（TPM、安全なエンクレーブ）に保存されている必要があります。現在、Okta Verifyのみがこの制約を満たしています。ハードウェアで保護はデバイスバウンドを意味するため、［Hardware protection（ハードウェアで保護）］を選択すると、その制約が自動的に選択されます。

      注：Okta Verifyがデバイスの安全なハードウェア（WindowsおよびAndroidデバイスの場合はTPM、macOSおよびiOSデバイスの場合は安全なエンクレーブ）にキーを保存できない場合、ソフトウェアストレージを使用します。こうした場合、Okta Verifyはハードウェアで保護の要件を満たしません。

      デバイスに対してOkta Verifyキーがどのように保存されているかを確認するには、Okta Admin ConsoleでsecureHardwarePresentデバイス属性を表示するか、Okta式言語（EL）の式を使用してdevice.profile.secureHardwarePresentviewの値を確認します。この値がtrueの場合は、安全なハードウェアが使用されます。

      「カスタム式」および「デバイスの状態を表示する」を参照してください。

    • ［Exclude phone and email authenticators（電話とメールのオーセンティケーターを除く）］：要素のキーをデバイスに安全に保管するよう求め、要素を再登録せずに別のデバイスに転送できないようにします。デバイスバウンドでない所有要素は、メールとSMSだけです。ほかの制約のいずれかが選択されている場合、この制約は自動的に選択されます。
    AND［Access with Okta FastPass is granted（Okta FastPassを使用したアクセスを許可）］ これらのオプションでは、Okta FastPassを使用して認証する際に、エンドユーザーが物理的に存在していることの証明を要求するかどうかを選択できます。
    • ［If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)（ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する（NIST AAL2要件を満たす）場合）］
    このオプションでは、ユーザーが物理的に存在することを証明する必要があります。
    • ユーザーがOkta Verifyでプロンプトを承認したり、生体認証を提供したりしない場合
    このオプションが選択されていて、認証ポリシーに所有要素が必要な場合、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようになります。このオプションはNIST AAL2の要件を満たしていません。また、このオプションを選択した場合、セキュリティ上の質問を追加の要素として使用することはできません。
    ［Re-authentication frequency is（再認証の頻度）］

    この設定では、エンドユーザーが再認証する必要がある頻度を指定できます。

    • ［Every sign-in attempt（サインイン試行の都度）］：ユーザーはアプリにアクセスするたびに再認証する必要があります。
    • ［Never re-authenticate if the session is active（セッションがアクティブの場合は再認証しない）］：ユーザーがデバイスから認証された後は、セッションの最大ライフタイムに達するか、Oktaからサインアウトするまで、再認証のプロンプトは表示されません。
    • ［Re-authenticate after（再認証を求めるまでの時間）］：エンドユーザーが再認証する必要がある頻度を指定します。ユーザーがアプリへのアクセスを試行し、指定した時間間隔内に再認証されておらず、セッションの有効期限が切れていない場合にのみ再認証を求められます。

    注：ユーザーがパスワードで認証した後、10秒間の猶予期間が適用されます。［Every sign-in attempt（すべてのサインイン試行）］が選択されている場合は、この猶予期間中に再度パスワードの入力を求められることはありません。
    ［Password re-authentication frequency is（パスワードの再認証の頻度）］ これら2つのオプションは、［Password + Another Factor（パスワード+別の要素）］または［Password / IdP + Another factor（パスワード/IdP+別の要素）］が選択されている場合にのみ表示されます。パスワードやそのほかの要素に対して、異なる再認証間隔を指定できます。たとえば、アプリにアクセスするたびに所有要素を使用して再認証するようにユーザーに要求し、最後に認証されてから8時間以上経過している場合はパスワードを要求することができます。
    ［Re-authentication frequency for all other factors is（ほかのあらゆる要素での再認証の頻度）］
  2. ［Save（保存）］をクリックします。

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

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

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

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

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

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

制限事項

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

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

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

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

次の手順

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

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