EDR統合アプリのサインオン・ポリシーを作成する
エンドポイント検出および応答(EDR)クライアントによって収集した信頼シグナルをOktaで評価できるようにするOktaアプリのサインオン・ポリシーを、式言語を使用して作成または編集することができます。
この手順を開始する
- 管理コンソールで、[アプリケーション] > に移動します。 [アプリケーション]
- EDRソリューションから収集した信頼シグナルで保護するアプリを選択します。
- アプリケーションのメイン・ページで、[サインオン]タブをクリックします。
- [サインオン・ポリシー]セクションまでスクロールします。
- アプリのサインオン・ポリシーを作成または編集します。
- IF条件を構成します。これらの条件では、どのような場合にルールを適用するのかを指定します。
IF条件 説明 IF
ユーザーのユーザー・タイプデフォルトでは、ルールはアプリに割り当てられたどのユーザーにも適用されます。デフォルトを受け入れるか、ユーザー・タイプを指定してください。 AND
ユーザーのグループ・メンバーシップデフォルトでは、ルールはアプリに割り当てられたどのグループにも適用されます。デフォルトを受け入れるか、ユーザー・グループを指定してください。 AND
ユーザーのIPデフォルトでは、ルールはどのIPにも適用されます。デフォルトを受け入れるか、ネットワーク・ゾーンを選択します。Oktaで定義済みのゾーンや未定義のゾーンで並べ替えたり、特定のゾーンを構成したりすることが可能です。 AND
デバイスの状態[登録済み]を選択します。 AND
デバイス管理
(このIF条件はすべての組織で使用できるわけではないことに注意してください。使用可能な場合、AND
デバイスの状態で[すべて]が選択されているときは表示されません。)ご使用のEDRをOkta Verifyと統合するために、デバイスをMDMソリューションで管理する必要はありません。必要に応じて[管理対象]または[非管理対象]を選択してください。 AND
デバイス・プラットフォームデフォルトでは、ルールはどのプラットフォームにも適用されます。デフォルトを受け入れるか、特定のプラットフォームを選択してください。 AND
リスク・レベルデフォルトでは、このルールはどのリスク・レベルの認証試行にも適用されます。ルールを選択すると、指定したリスク・レベルのみにルールが制限されます。 リスク・スコアリングを参照してください。 AND
次のカスタム式をtrueとする必要な式言語(EL)を入力して、このポリシーで評価するEDRシグナルを指定します。 - CrowdStrikeの例
以下の形式では、CrowdStrike ZTAシグナルをご使用のアプリのサインオン・ポリシーに統合します。これを使用して、セキュリティーのニーズを満たせるように許可/拒否ルールを調整します。利用可能なCrowdStrike EDRシグナルについては、利用可能なEDRシグナル(ベンダー別) を参照してください。
ここで紹介している値は一例に過ぎません。ご使用の環境に適した値を判別するには、CrowdStrikeのドキュメントを参照するか、直接CrowdStrikeにお問い合わせください。
device.provider.zta.overall <= 60
またはdevice.provider.zta.overall >= 60
- Windowsセキュリティ・センターの例
利用可能なWindowsセキュリティ・センターのEDRシグナルについては、利用可能なEDRシグナル(ベンダー別) を参照してください。
以下の形式では、ご使用のアプリのサインオン・ポリシーにWindowsセキュリティ・センターのシグナルを統合します。これを使用して、セキュリティーのニーズを満たせるように許可または拒否ルールを調整します。
device.provider.wsc.fireWall == "GOOD"
またはdevice.provider.wsc.fireWall == "POOR"
「挙動とアプリのサインオン・ポリシー・ルールについて」と「Okta式言語」を参照してください。
- CrowdStrikeの例
- THEN条件を構成します。これらの条件では、認証を適用する方法を指定します。
THEN条件 説明 THEN
アクセスの可否[認証の成功後に許可]を選択します。 AND
ユーザーが認証に使用する要素必要に応じて次のいずれかを選択します: - Okta Verifyでの登録がユーザー検証(Windows Hello)用に設定されている場合、[任意の2つの要素]を選択します
- Okta Verifyでの登録がユーザー検証(Windows Hello)用に設定されていない場合、[所有要素]を選択します
AND
所有要素の制限[デバイス・バウンド(電話とメールを除く)]を選択します。 AND
Okta FastPassを使用したアクセスを許可これらのオプションでは、Okta FastPassを使用して認証する際に、エンド・ユーザーが物理的に存在していることの証明を要求するかどうかを選択できます。 - ユーザーがOkta Verifyでプロンプトを承認するか、生体認証を提供する(NIST AAL2要件を満たす)場合
このオプションでは、ユーザーが物理的に存在することを証明する必要があります。
- ユーザーがOkta Verifyでプロンプトを承認したり、生体認証を提供したりしない場合
このオプションが選択されていて、アプリのサインオン・ポリシーに所有要素が必要な場合、Okta Verifyで証明書ベースの認証を実行できます。これにより、ユーザーが物理的に存在することを証明せずにリソースにアクセスできるようになります。このオプションはNIST AAL2の要件を満たしていません。
パスワードの再認証の頻度 [すべてのサインイン試行]を選択します。 ほかのあらゆる要素での再認証の頻度 [すべてのサインイン試行]を選択します。
-
[保存]をクリックします。