セッション保護を構成する

セッション保護を構成して、どのコンテキストの変更がグローバルセッションおよびアプリサインインポリシーの再評価につながるかを定義します。

VPNの切り替え、別のデバイスでのテスト、出張中のWi-Fiネットワークの変更など、ユーザーが認証後に実行するルーチンアクションについて考えてみましょう。どのコンテキストでリスクと見なされますか？ポリシーに違反している場合、どの修復レベルが最も効果的ですか？セッション保護は、確認できる違反数およびユーザーのサインインの負担のレベルを制御するため、ITPにとって不可欠です。

開始する前に

• セッション保護を構成するには、スーパー管理者またはorg管理者である必要があります。ITPの管理者ロールを参照してください。

• ポリシーに含めるネットワークゾーンを作成します。ネットワークゾーンを管理するを参照してください。

• カスタム修復アクションを実行する場合は、ITP用のWorkflowsを作成してください。サポートされるのは委任ワークフローのみです。ポリシーアクションの委任フローを作成するを参照してください。

ステータスを設定する

1. Admin Consoleで、セキュリティ（Security） > Identity Threat Protectionに移動します。

2. 検出および応答（Detection and Response）タブをクリックします。

3. セッション保護（Session Protection）に移動します。

4. ステータス（Status）セクションで、以下のいずれかを選択します。

   • モニタリング（Monitoring）：ポリシーが再評価され、セッション違反がSystem Logに記録されます。修復アクションは適用されません。

   • 強制適用済み（Enforced）：ポリシーが再評価され、セッション違反がSystem Logに記録され、修復アクションが強制されます。

セッション違反検出を構成する

これらの設定は、再評価をトリガーするタイミングを決定します。

1. セッション違反検出（Session violation detection）セクションで編集（Edit）をクリックします。

2. リスクレベル（Risk level）を選択します。

   • 高（High）：高リスクのセッションのみ、ポリシーの再評価が求められます。この場合、ユーザーの負担は最小限に抑えられますが、セキュリティは低下します。IPまたはデバイスを変更するたびにポリシーを再評価する必要がない場合、それらの変更はこのレベルのフィルタリングで除外できます。

   • 中程度以上（Medium and above）：中程度以上のリスクと判断されたセッションで、ポリシーの再評価が求められます。このレベルは、セキュリティとユーザー負担のバランスが最適になります。

   • 低度以上（Low and Above）（Low and above）：デフォルトの設定です。すべてのセッションでポリシーの再評価が求められます。いかなる変更もフィルタリングで除外されないため、最も安全なリスクレベルですが、管理者の介入とユーザーの負担が増えます。

3. ユーザーのIP（User's new IP is）メニューで、ポリシー評価を開始するネットワークゾーンを選択します。

   • 任意のIP（Any IP）：すべてのIPを対象にポリシーを再評価します。これは、最も安全な設定です。

   • 次のいずれかのゾーン（In any of the following zones）：新しいIPが管理者が選択したゾーン（例：EDZ/アノニマイザー/地理的リスクゾーン）にある場合にのみ、ポリシーを再評価します。この設定は、すべてのリスクゾーンを確信を持って特定できるorgに有益です。

   • 次のゾーン以外（NOT in any of the following zones）：管理者が選択したゾーンにあるIPを除く、すべてのIPでポリシーを再評価します（例えば、除外HQ/ VPNを除外します）。これには、DefaultExemptIPZoneと信頼できるプロキシ構成ネットワークゾーンがデフォルトで含まれます。

強制適用設定

これらの設定は、セッション違反が記録されたときの動作を制御します。

1. 強制適用設定（Enforcement settings）セクションで、グローバルセッションおよびアプリサインインポリシーから継承したアクション（Actions）を確認します。これらのアクションは、ポリシーが強制適用済み（Enforced）に設定されるたびに強制適用され、それらのポリシーで指定したユーザーに適用されます。

   • 可能であればMFA（MFA if possible）：Oktaページに表示されているユーザーは、アクセスしようとしているアプリのグローバルセッションポリシーまたはアプリサインインポリシーがMFAを必要とする場合は、再認証を求められます。適切なMFAが提供されていれば、セッション違反は記録されません。

   • Oktaログアウト（Okta logout）：グローバルセッションポリシーでDENYアクションが発生した場合、またはユーザーが適切なMFAを提供しなかった場合、ユーザーはOktaセッションからログアウトされます。アプリセッションは影響を受けない場合があります。

2. 別の修復手順を追加するには、追加のアクションを実行（Run an additional action）を選択してから、次のいずれかを選択します。

   • アプリログアウト（App logout）：検出がアプリサインインポリシーに違反し、アプリがUniversal Logoutをサポートしている場合、ユーザーはアプリからログアウトされます。グローバルセッションポリシーで同時に違反があった場合、ユーザーは関連アプリから同時にログアウトされる可能性があります。

   • ワークフローを実行（Run a workflow）：Oktaは、委任ワークフローに基づいてカスタム修復を実行します。

3. 影響を受けるグループ（Groups impacted）セクションで、追加アクション（アプリログアウト（App logout）またはワークフローを実行（Run a workflow）を適用するグループを選択します。これらのグループではないユーザーは、グローバルセッションポリシーとアプリサインインポリシーで、可能であればMFA（MFA if possible）とOktaログアウト（Okta logout）アクションの影響を依然として受ける場合があることに注意してください。

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

関連項目

セッション保護（Session protection）

セッション保護レポート