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

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

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

はじめに

Authenticatorをセットアップする

認証ポリシーを作成する

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

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

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

    注：これらの認証オプションの横に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要素認証オプションについては、「パスワードなしの認証」を参照してください。
    AND［所有要素の制約］ ［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オプションはこの要件を満たします。詳細については、「多要素認証」を参照してください。フィッシング耐性はDevice bound（デバイスバウンド）を意味するため、［Phishing-resistant（フィッシング耐性）］オプションを選択すると、［Exclude phone and email authenticators（電話とメールのAuthenticatorを除く）］オプションが自動的に選択されます。
    • ［Hardware protection（ハードウェアで保護）］：認証に使用されるキーがデバイスのセキュアハードウェア（TPM、安全なエンクレーブ）に保存されている必要があります。Okta Verifyはこの制約を満たしています。ハードウェアで保護はDevice bound（デバイスバウンド）を意味するため、［Hardware protection（ハードウェアで保護）］を選択すると、その制約が自動的に選択されます。

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

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

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

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

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

      • 2022年11月30日以前に行われた登録はサポートされません。
      • FIDO U2Fを使った登録はサポートされません。
      • Firefoxでの登録は現在サポートされません。
      • ［User Verification（ユーザー検証）］が［Discouraged（非推奨）］に設定され、セキュリティキーにPINが設定されている場合、Chromeでの登録は現在サポートされません。
      • 登録時に求められた場合、ユーザーはセキュリティキーのメーカーとモデルの確認をOktaに許可する必要があります。
    • ［Exclude phone and email authenticators（電話とメールのAuthenticatorを除く）］：要素のキーをデバイスに安全に保存し、要素の再登録なしで別のデバイスに転送できないようにする必要があります。デバイスバウンドでない所有要素は、メールとSMSだけです。ほかの制約のいずれかが選択されている場合、この制約は自動的に選択されます。
    • ［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. ［Setup（設定）］タブをクリックします。
      3. 構成するAuthenticatorの［Actions（アクション）］［Edit（編集）］をクリックします。
      4. Okta Verify（プッシュあり）、FIDO2（WebAuthn）、カスタムAuthenticator、Okta FastPassの場合は、［User verification（ユーザー検証）］セクションのドロップダウンメニューで［Required（必須）］を選択します。スマートカードの場合は、［PIN］を選択します。

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

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

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

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

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

このAuthenticatorをアカウント復旧にのみ使用する、または認証とアカウント復旧の両方に使用するように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を使用できません。

次の手順

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

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