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

早期アクセスリリース。「セルフサービス機能を有効にする」を参照してください。

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

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

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

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

    • ［Okta logout（Oktaログアウト）］：グローバルセッションポリシーで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 if possible（可能であればMFA）］と［Okta logout（Oktaログアウト）］アクションの影響を依然として受ける場合があることに注意してください。

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

関連項目

セッション保護

セッション保護レポート