アプリサインインルールの動作条件を追加する

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

開始する前に

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

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

このタスクを開始する

Admin Consoleでセキュリティ（Security） > 認証ポリシーに移動します。
アプリのサインイン（App sign-in）をクリックします。
ルールを追加するアプリサインインポリシーを選択します。
ルールを追加（Add Rule）（Add rule）ページをクリックします。
ルールを説明するルール名（Rule name）を入力します。
適切なIF条件を構成して、どのような場合にルールを適用するのかを指定します。
条件を設定する際には、一部の条件は主にイベントの監査とフィルタリングに役立つものの、セキュリティ体制を定義するための基礎として扱うべきではないことに注意してください。
たとえば、悪意のあるアクターはデバイスプラットフォームを簡単に偽装できるため、デバイスプラットフォームをアプリサインインポリシールールの主要コンポーネントとして使用しないでください。
適切なTHEN条件を構成して、認証の適用方法を指定します。
必要に応じて、再認証の頻度を構成します。
保存（Save）をクリックします。
THEN条件を構成します。これらの条件では、認証を適用する方法を指定します。

THEN	説明
THENアクセスの可否（THEN Access is）	ユーザーのアクセスを拒否するか、認証が成功した後に許可します。アクセスを拒否する場合、最後の手順までスキップしてルールを保存してください。
ANDユーザーが認証に使用する要素（AND User must authenticate with）	アプリへのアクセスに強制適用する認証要件を選択します。要素タイプの説明については、多要素認証を参照してください。 1要素タイプ（1 factor type:）：1要素認証を有効にするには、次から選択します。パスワード（Password）では、ルールで再認証が必要になるたびにパスワードを入力する必要があります。所有要素（Possession factor）では、アプリにアクセスするために、ユーザーがOkta Verifyやメールなどの所有要素を提供する必要があります。任意の1要素タイプ（Any 1 factor type）を使用すると、ユーザーは任意の単一要素を指定してアプリにアクセスできます。パスワードレスの1要素認証オプションを設定するには、パスワードレス・サインイン・エクスペリエンスをセットアップするを参照してください。 2要素タイプ（［2 factor types）］：（2 factor types:）ユーザーに2つの別個の要素タイプの提供を求める場合に選択します。次の中から選択します。パスワード+別の要素（Password + Another factor）任意の2つの要素タイプ（Any 2 factor types）パスワードレスの2要素認証オプションについては、Okta FastPassを構成するを参照してください。
AND所有要素の制限（AND Possession factor restraints are）	ユーザーが認証に使用する要素（User must authenticate with）（Password）でパスワード（Password）（User must authenticate with）のみが選択されている場合、これらのオプションは使用できません。これらの設定を使用して、所有要素の特性を指定します。フィッシング耐性（［Phishing-resistant）］：（Phishing-resistant:）ログインサーバー（オリジン）を暗号で検証する所有要素の提供をユーザーに要求します。現在、パスキー（FIDO2 WebAuthn）のみがこの要件を満たしています。フィッシング耐性はデバイスバウンド（Device bound）を意味するため、フィッシング耐性（Phishing-resistant）を選択すると、その制約が自動的に選択されます。ハードウェアで保護（［Hardware protection）］：（Hardware protection:）認証に使用されるキーがデバイスのセキュアハードウェア（TPM、安全なエンクレーブ）に保存されている必要があります。現在、Okta Verifyのみがこの制約を満たしています。ハードウェアで保護はデバイスバウンド（Device bound）を意味するため、ハードウェアで保護（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)（デバイスバウンド（電話とメールを除く））］：（Device bound (excludes phone and email):）要素のキーをデバイスに安全に保管するよう求め、要素を再登録しなければ別のデバイスに転送できないようにします。デバイスバウンドでない所有要素は、メールとSMSだけです。ほかの制約のいずれかが選択されている場合、この制約は自動的に選択されます。
AND Okta FastPassを使用したアクセスを許可（AND Access with Okta FastPass is granted）	これらのオプションでは、Okta FastPassを使用して認証する際に、エンドユーザーが物理的に存在していることの証明を要求するかどうかを選択できます。ユーザーがOkta Verifyでプロンプトを承認するか、生体認証（NIST AAL2の要件を満たす）を提供する（If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)）：このオプションを指定すると、ユーザーは物理的に存在することを証明する必要が生じます。ユーザーがOkta Verifyでプロンプトを承認したり生体認証を提供したりしない（Without the user approving a prompt in Okta Verify or providing biometrics）：このオプションを選択した場合、アプリサインオンポリシーで所有要素が必要であれば、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーは物理的に存在することを証明せずにリソースにアクセスできるようになります。このオプションはNIST AAL2の要件を満たしていません。また、このオプションを選択した場合、セキュリティ質問を追加の要素として使用することはできません。
再認証の頻度（Re-authentication frequency is）	この設定では、エンドユーザーが再認証する必要がある頻度を指定できます。サインイン試行の都度（［Every sign-in attempt）］：（Every sign-in attempt:）ユーザーはアプリにアクセスするたびに再認証する必要があります。セッションがアクティブの場合は再認証しない（［Never re-authenticate if the session is active）］：（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）

保存（Save）をクリックします。