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

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

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

はじめに

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

認証ポリシーを作成する

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

  1. 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 assurance policy（デバイス保証ポリシー）］［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 Expression Language」を参照してください。

  1. 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（ユーザーが認証に使用する要素）］

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

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

    ［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要素認証オプションについては、「Okta FastPassを構成する」を参照してください。
    AND［Possession factor constraints are（所有要素の制約）］ ［User must authenticate with（ユーザーが認証に使用する要素：）］で［Password（パスワード）］、［Any 1 factor type（任意の1要素タイプ）］、または［Any 1 factor type / IdP（任意の1要素タイプ/IdP）］を選択した場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。
    • ［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キーの保存方法を特定するには、管理リソースでsecureHardwarePresent属性を確認します。また、Okta Expression Language（EL）式を使ってdevice.profile.secureHardwarePresentviewの値を調べることもできます。この値がtrueであれば、安全なハードウェアが使用されます。

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

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

      ハードウェア保護されたWebAuthnオーセンティケーターにはいつかの制限事項が適用されます。

      • 2022年11月30日以前に行われた登録はサポートされません。
      • FIDO U2Fを使った登録はサポートされません。
      • Firefoxでの登録は現在サポートされません。
      • ［User Verification（ユーザー検証）］が［Discouraged（非推奨）］に設定され、セキュリティキーにPINが設定されている場合、Chromeでの登録は現在サポートされません。
      • 登録時に求められた場合、ユーザーはセキュリティキーのメーカーとモデルの確認をOktaに許可する必要があります。
    • ［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 FastPassを有効にする場合（つまり、ユーザーが物理的に存在していることを証明せずにリソースにアクセスできるようにする場合）、追加要素としてセキュリティ質問を使用することはできません。セキュリティ質問の使用をエンドユーザーに求めるには、グローバルセッションポリシーの［A password（パスワード）］オプションを使用する必要があります。

制限事項

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

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

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

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

次の手順

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

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