アプリごとの定期的な認証の構成

プライベート アプリ アクセス ポリシーでこのアクションを使用します。その他のアクセス決定については、アクセス アクションを参照してください。

アプリごとの定期認証ポリシーを設定する

Periodic Per-App Authentication 特定のプライベートアプリセグメントにアクセスする際に、ユーザーに定期的な認証を要求することで、セキュリティ層をさらに強化します。この機能は、デスクトップ デバイス (Windows および macOS) でのみ使用できます。

前提条件

• SAML Forward Proxy クライアント登録とユーザー識別を有効にするには、設定と展開が必要です。
• 認証を成功させるには、ユーザーはクライアントの登録時と同じ ID (電子メール) を使用する必要があります。
• Source OS 新しい定期認証アクションを選択するには、条件をWindows and/or MacOSに設定する必要があります。
• Netskope Client バージョン R133 以降である必要があります。

定期認証リアルタイムポリシーの設定

定期的な認証を強制するには：

1. Policies > Real-Time Protection Policiesへ移動してください。
2. New Policy > Private App Accessをクリックしてください。
3. For Source Criteria, include Operating System = Windows and/or macOS.
4. Select Client for the Access Method.
5. Select the Private App Segment(s) for the Destination.
6. アクションにはPeriodic Authentication Select 、認証間隔（例えば30分ごと）を定義します。
7. ユーザー通知テンプレートSelect 。
8. 完了したら、 Saveをクリックしてください。

ユーザーの認証期限が切れた後も、既存のセッションは有効なままです。ただし、この間隔が経過すると、新しいセッションを開始するには認証が必要になります。

認証タイマーの仕組み

このシステムのタイマーロジックはシンプルながら強力だ。これは、ユーザーがプライベートアプリケーションに対して最後に認証に成功したことを示す単一のタイムスタンプに依存しています。

これは、再認証を求められるたびに新しいタイムスタンプが付与される、一種の万能通行証のようなものだと考えてください。アプリにアクセスしようとすると、システムは、最後にタイムスタンプを取得してから経過した時間が、そのアプリに必要な特定の認証間隔よりも長いかどうかを確認します。

使うケース 例

これが実際にどのように機能するかを示すために、現実世界のシナリオを見てみましょう。

アリスというユーザーに対して、2つのポリシーが設定されていると想像してみてください。

• App A (GitLab): 90分ごとに認証が必要です。
• App B (Jira): 60分ごとに認証が必要です。

アリスの活動の時系列は以下のとおりです。

• 9:00 AM: アリスは初めてGitLab（アプリA）にアクセスする。
  • Action: 彼女は認証を求められます。認証が完了すると、アクセスが許可されます。
  • Result: アリスの最終認証時刻は今、午前9時00分に設定されています。⏰
• 9:50 AM: アリスはJira（アプリB）を開く。
  • Check: システムは彼女の最後の認証からの時間を計算します: 9:50 AM - 9:00 AM = 50 minutes 。
  • Action: 50 分は Jira の 60 分間隔より短いため、新しい認証は必要ありません。 アクセスはスムーズに許可されます。
  • Result: 最終認証時刻は午前9時のままです。
• 10:10 AM: アリスは再び Jira (アプリ B) にアクセスします。
  • Check: システムは経過時間を計算します: 10:10 AM - 9:00 AM = 70 minutes 。
  • Action: 70分はJiraの60分間隔よりも長いため、アリスは再認証を求められます。
  • Result: 認証が成功すると、最終認証時刻が午前10時10分に更新されます。🔄
• 10:30 AM: アリスはGitLab（アプリA）に戻ります。
  • Check: The system uses the newest timestamp: 10:30 AM - 10:10 AM = 20 minutes.
  • Action: 20分はGitLabの90分間隔よりも短いため、認証は不要です。
  • Result: 最終認証時刻は午前10時10分のままです。

この単一のローリングタイムスタンプにより、認証は、ユーザーの最後のシステム全体の認証イベントを基準として、アクセスされるアプリのポリシーに基づいて行われることが保証されます。

ポリシーの保存と有効化

わかりやすいポリシー名を入力し、グループを選択します。ポリシーが有効になっていることを確認して保存し、適用可能な他のアクセス ポリシーに対する位置関係を確認してから、Apply Changes をクリックします。アプリケーションに必要なプライベートアプリセグメント、Publisher、およびトラフィックステアリングがすでに構成されていることを確認します。

通知テンプレート

認証に固有のテンプレートについては、ユーザー通知の設定に従ってください。通知ページには、すべてのブランディング、ローカライゼーション、アクションボタンのフィールドも含まれます。

ポリシーを検証する

1. テストユーザーが対象のWindowsまたはmacOSデバイスと想定されるClient IDを使用していることを確認します。
2. 保護されたアプリケーションへの新しいセッションを開始し、プロンプトが表示されたら認証を完了します。
3. 間隔が期限切れになる前に別のセッションを開始し、想定どおりのアクセスを確認します。
4. インターバルが経過した後、新しいセッションを開始し、認証が必要であることを確認します。
5. ユーザーが異なる間隔でアプリケーションにアクセスする場合は、1つのアプリケーションで認証に成功したことが、他のアプリケーションに対する後続のチェックに反映されていることを確認してください。

Periodic Authentication アクションを利用できない場合は、ポリシーでクライアントアクセスが使用されており、OS 条件に Windows や macOS（またはその両方）が含まれていることを確認します。認証が失敗する場合は、クライアント登録 ID、ID プロバイダの設定、および通知テンプレートを確認します。

関連トピック

• プライベートアプリセグメントのソースポリシー基準
• プライベートアプリセグメントのプロファイルとアクション
• Private App AccessポリシーでのUser Confidenceの設定（ベータ）