認証ポリシールールへの動作条件の追加

認証ポリシーは、リクエストされたアプリケーションのコンテキストでエンドユーザーの認証を強制します。式言語を使用して、認証ポリシーの動作条件を構成します。

はじめに

  • 新規に作成するか、既存の認証ポリシーを使用します。
  • アダプティブ多要素認証を有効にする必要があります。
  • 1つのヒューリスティックに含める条件は10個以下にしてください。
  • Security Contextの式言語は、次のような演算子のサブセットをサポートしています。
    • ||、OR
    • &&、AND
    • !、NOT
    • ==
    • !=

詳細については、「Okta Expression Languageの概要」を参照してください。

このタスクを開始する

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

  2. ルールを追加する認証ポリシーを選択します。

  3. ［Add Rule（ルールを追加）］ページをクリックします。

  4. ルールを説明する［Rule name（ルール名）］を入力します。

  5. 適切な［IF］条件を構成して、どのような場合にルールを適用するのかを指定します。

    条件を設定する際には、一部の条件は主にイベントの監査とフィルタリングに役立つものの、セキュリティ体制を定義するための基礎として扱うべきではないことに注意してください。

    たとえば、悪意のあるアクターはデバイスプラットフォームを簡単に偽装できるため、デバイスプラットフォームを認証ポリシールールの主要コンポーネントとして使用しないでください。

  6. 適切な［THEN］条件を構成して、認証の適用方法を指定します。

  7. 必要に応じて、再認証の頻度を構成します。

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

  9. 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」を参照してください。
  10. THEN条件を構成します。これらの条件では、認証を適用する方法を指定します。
    THEN説明
    THEN［Access is（アクセスの可否）］ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。
    AND［User must authenticate with（ユーザーが認証に使用する要素）］

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

    ［1要素タイプ］：1要素認証を有効にするには、次から選択します。

    • ［Password（パスワード）］では、ルールで再認証が必要になるたびにパスワードを入力する必要があります。
    • ［Possession factor（所有要素）］では、アプリにアクセスするために、ユーザーがOkta Verifyやメールなどの所有要素を提供する必要があります。
    • ［Any 1 factor type（任意の1要素タイプ）］を使用すると、ユーザーは任意の単一要素を指定してアプリにアクセスできます。
    • パスワードなしの1要素認証オプションを設定するには、「パスワードなしサインインエクスペリエンスをセットアップする」を参照してください。
    ［2 factor types（2要素タイプ）］：ユーザーに2つの別個の要素タイプの提供を求める場合に選択します。次の中から選択します。
    • ［Password + Another factor（パスワード+別の要素）］
    • ［Any 2 factor types（任意の2つの要素タイプ）］
    • パスワードなしの2要素認証オプションについては、「Okta FastPassを構成する」を参照してください。
    AND［Possession factor restraints are（所有要素の制限）］［User must authenticate with（ユーザーが認証に使用する要素）］で［Password（パスワード）］のみが選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。
    • ［Phishing-resistant（フィッシング耐性）］：ログインサーバー（オリジン）を暗号で検証する所有要素の提供をユーザーに要求します。現在、FIDO2（WebAuthn）のみがこの要件を満たしています。フィッシング耐性はデバイスバウンドを意味するため、［Phishing-resistant（フィッシング耐性）］を選択すると、その制約が自動的に選択されます。
    • ［Hardware protection（ハードウェアで保護）］：認証に使用されるキーがデバイスのセキュア・ハードウェア（TPM、安全なエンクレーブ）に保存されている必要があります。現在、Okta Verifyのみがこの制約を満たしています。ハードウェアで保護はデバイスバウンドを意味するため、［Hardware protection（ハードウェアで保護）］を選択すると、その制約が自動的に選択されます。

      デフォルトでは、Okta Verifyはデバイスの安全なハードウェア（WindowsおよびAndroidデバイスの場合はTrusted Platform Module（TPM）、macOSおよびiOSデバイスの場合は安全なエンクレーブ）にOkta Verifyキーを保存しようとします。安全なハードウェアが利用できない場合は、ソフトウェアストレージが使用されます。ソフトウェアストレージを使用する場合、THEN条件のAND［Possession factor restraints are（所有要素の制限）］で［Hardware protection（ハードウェアで保護）］が選択されているときは、Okta Verifyはアプリサインオンポリシーを満たしていません。デバイスに対してOkta Verifyキーがどのように保存されているかを確認するには、Okta Admin ConsoleでsecureHardwarePresentデバイス属性を表示するか、Okta Expression Language（EL）の式を使用してdevice.profile.secureHardwarePresentviewの値を確認します。この値がtrueの場合は、安全なハードウェアが使用されます。「Okta Expression Language」および「デバイスの詳細の表示」を参照してください。

    • ［Device bound (excludes phone and email)（デバイスバウンド（電話とメールを除く））］：要素のキーをデバイスに安全に保管するよう求め、要素を再登録しなければ別のデバイスに転送できないようにします。デバイスバウンドでない所有要素は、メールと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の要件を満たす）を提供する）］：このオプションを指定すると、ユーザーは物理的に存在することを証明する必要が生じます。
    • ［Without the user approving a prompt in Okta Verify or providing biometrics（ユーザーが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（パスワード+別の要素）］が選択されている場合にのみ表示されます。パスワードやそのほかの要素に対して、異なる再認証間隔を指定できます。たとえば、最後に認証されてから8時間以上経過している場合はパスワードを使用し、アプリにアクセスするたびに所有要素を使用して再認証するようにユーザーに要求できます。
    ［Re-authentication frequency for all other factors is（ほかのあらゆる要素での再認証の頻度）］
  11. ［Save（保存）］をクリックします。

関連項目

動作とサインオンポリシーについて

グローバルセッションポリシー