次の方法で共有

条件付きアクセスのアダプティブ セッションの有効期間

  • [アーティクル]

複雑なデプロイでは、認証セッションの制限が必要になる場合があります。 次のようなシナリオがあります。

  • 管理対象外のデバイスまたは共有デバイスからのリソース アクセス
  • 外部ネットワークから機密情報へのアクセス
  • 影響の大きなユーザー
  • 重大なビジネス アプリケーション

条件付きアクセスでは、すべてのユーザーに影響を与えることなく、組織内の特定のユース ケースを対象とするポリシーを作成できるアダプティブ セッションの有効期限ポリシー制御が提供されます。

ポリシーを構成する方法を詳しく説明する前に、既定の構成を調べてみましょう。

ユーザー サインインの頻度

サインインの頻度は、ユーザーがリソースにアクセスしようとしたときにサインインし直すように求められるまでの期間を定義します。

ユーザー サインインの頻度に関する Microsoft Entra ID の既定の構成は、90 日間のローリング ウィンドウです。 多くの場合、ユーザーに資格情報を要求することは賢明であるように思われますが、逆効果になることがあります。何も考えずに資格情報を入力するように教えられたユーザーは、意図せずに、資格情報を求める悪意のあるプロンプトに入力してしまう可能性があります。

ユーザーにサインインし直すように求めないことは不安に感じられるかもしれませんが、実際は IT ポリシーのどのような違反によってもセッションは取り消されます。 たとえば、パスワードの変更、非準拠のデバイス、アカウントの無効化などがあります (ただしこれらに限定されません)。 また、Microsoft Graph PowerShell を使用して明示的にユーザーのセッションを取り消すことができます。 Microsoft Entra ID のデフォルトの構成は、結局、"セッションのセキュリティ態勢が変更していなければ、資格証明の提供をユーザーに求めない" というものになります。

サインイン頻度設定は、標準に従って OAuth2 または OIDC プロトコルを実装したアプリで動作します。 Windows、Mac、次の Web アプリケーションを含むモバイル用のほとんどの Microsoft ネイティブ アプリは、この設定に準拠します。

  • Word、Excel、PowerPoint Online
  • OneNote Online
  • Office.com
  • Microsoft 365 管理者ポータル
  • Exchange Online
  • SharePoint と OneDrive
  • Teams Web クライアント
  • Dynamics CRM Online
  • Azure portal

サインイン頻度 (SIF) は、独自の Cookie が削除されず、定期的に認証のために Microsoft Entra ID にリダイレクトされる限り、OAuth2 または OIDC プロトコルが実装されているサードパーティの SAML アプリケーションおよびアプリで機能します。

ユーザーのサインイン頻度と多要素認証

サインイン頻度は、以前は Microsoft Entra 参加済みデバイス、Microsoft Entra ハイブリッド参加済みデバイス、Microsoft Entra 登録済みデバイス上の最初の要素認証にのみ適用されていました。 お客様にとって、これらのデバイスに多要素認証を再適用するための簡単な方法はありませんでした。 お客様からのフィードバックに基づいて、サインイン頻度が MFA にも適用されます。

サインインの頻度と MFA がどのように連携するかを示す図。

ユーザーサインインの頻度とデバイス ID

Microsoft Entra 参加済みおよび Microsoft Entra ハイブリッド参加済みデバイスでは、デバイスのロックを解除するか、対話形式でサインインすると、プライマリ更新トークン (PRT) が 4 時間ごとに更新されます。 現在のタイムスタンプと比較して PRT 用に記録される最後の更新タイムスタンプは、SIF を満たし、既存の MFA 要求を持つ PRT へのアクセスを許可するために、PRT 用の SIF ポリシーで割り当てられた時間内である必要があります。 Microsoft Entra 登録済みデバイスでは、ユーザーが Microsoft Entra アカウントを介して Microsoft Entra 登録済みデバイスにアクセスしていないため、ロック解除/サインインは SIF ポリシーを満たしません。 ただし、Microsoft Entra WAM プラグインは、WAM を使用したネイティブ アプリケーション認証中に PRT を更新できます。

Note

ユーザーのログインからキャプチャされたタイムスタンプは、更新サイクルが 4 時間であるため、最後に記録された PRT 更新のタイムスタンプと必ずしも同じではありません。 それが同じになるのは、PRT の有効期限が切れ、ユーザー ログインによってそれが 4 時間の間に更新された場合です。 次の例では、SIF ポリシーが 1 時間に設定されており、PRT が 00:00 に更新されるとします。

例 1: SPO で同じドキュメントに対して 1 時間作業を続ける場合

  • 00:00 に、ユーザーは Windows 11 Microsoft Entra 参加済みデバイスにサインインし、SharePoint Online に保存されているドキュメントで作業を開始します。
  • ユーザーはデバイス上の同じドキュメントで1時間、作業を継続します。
  • 01:00 に、ユーザーはもう一度サインインするように求められます。 このプロンプトは、管理者によって構成された条件付きアクセス ポリシーのサインイン頻度の要件に基づいています。

例 2: ブラウザーで実行されているバックグラウンド タスクで作業を一時停止し、SIF ポリシー時間が経過した後に再び対話する場合

  • 00:00 に、ユーザーは Windows 11 Microsoft Entra 参加済みデバイスにサインインし、SharePoint Online にドキュメントのアップロードを開始します。
  • 00:10 に、ユーザーは立ち上がり、デバイスをロックして休憩します。 SharePoint Online へのバックグラウンド アップロードは継続されます。
  • 02:45 に、ユーザーは休憩から戻り、デバイスのロックを解除します。 バックグラウンド アップロードは完了と表示されます。
  • 02:45 に、ユーザーは再び対話するときにサインインするように求められます。 このプロンプトは、前回のサインインが 00:00 に発生してから管理者によって構成された、条件付きアクセスポリシーのサインイン頻度の要件に基づいています。

クライアント アプリ (アクティビティの詳細の下) がブラウザーの場合、次のユーザー操作まで、バックグラウンド サービスに対するイベント/ポリシーのサインイン頻度の適用を延期します。 機密クライアントでは、非対話型サインインに対するサインイン頻度の適用は、次回の対話型サインインまで延期されます。

例 3: ロック解除からのプライマリ更新トークンの更新サイクルが 4 時間の場合

シナリオ 1 - ユーザーがサイクル内に戻る

  • 00:00 に、ユーザーは Windows 11 Microsoft Entra 参加済みデバイスにサインインし、SharePoint Online に保存されているドキュメントで作業を開始します。
  • 00:30 では、ユーザーは立ち上がり、デバイスをロックして休憩します。
  • 00:45 では、ユーザーは休憩から戻り、デバイスのロックを解除します。
  • 01:00 に、ユーザーはもう一度サインインするように求められます。 このプロンプトは、最初のサインインから 1 時間経過したため、管理者によって構成された条件付きアクセス ポリシーのサインイン頻度の要件に基づいています。

シナリオ 2 - ユーザーがサイクル外に戻る

  • 00:00 に、ユーザーは Windows 11 Microsoft Entra 参加済みデバイスにサインインし、SharePoint Online に保存されているドキュメントで作業を開始します。
  • 00:30 では、ユーザーは立ち上がり、デバイスをロックして休憩します。
  • 04:45 に、ユーザーは休憩から戻り、デバイスのロックを解除します。
  • 05:45 に、ユーザーはもう一度サインインするように求められます。 このプロンプトは、管理者によって構成された条件付きアクセス ポリシーのサインイン頻度の要件に基づいています。 PRT が 04:45 に更新されてから 1 時間経過し、00:00 の最初のサインインからは 4 時間超過しました。

毎回の再認証を要求する

ユーザーが次のような特定のアクションを実行するたびに、お客様が新しい認証を要求するシナリオがあります。

  • 機密アプリケーションへのアクセス。
  • VPN またはサービスとしてのネットワーク (NaaS) プロバイダーの背後にあるリソースのセキュリティ保護。
  • PIM での特権ロールの昇格のセキュリティ保護。
  • Azure Virtual Desktop マシンへのユーザー サインインの保護。
  • 危険なユーザーと危険なサインインの保護Microsoft Entra ID Protection によって識別された
  • Microsoft Intune 登録などの機密性の高いユーザー アクションのセキュリティ保護。

クライアントで新しいトークンを取得する必要があるタイミングのロジックがリソースにある場合、サインイン頻度を [毎回] に設定すると最適に動作します。 これらのリソースは、セッションの有効期限が切れた場合にのみ、ユーザーを Microsoft Entra にリダイレクトします。

管理者は、ユーザーに毎回再認証を要求するポリシーを適用するアプリケーションの数を制限する必要があります。 ポリシーで [毎回] が選ばれている場合、5 分の時刻のずれを考慮して、5 分に 1 回以下の頻度でユーザーにプロンプトを表示するようにします。 再認証を頻繁にトリガーし過ぎると、MFA 疲労が発生してフィッシングの試みが可能になるまで、セキュリティの摩擦が高まる可能性があります。 通常、Web アプリケーションでは、有効になるたびに再認証が必要な場合に、デスクトップ アプリケーションよりも中断の少ないエクスペリエンスを提供します。

サポートされている一般提供のシナリオ:

2024 年 2 月のパブリック プレビュー機能を使うと、管理者は次の認証を要求できます。

管理者が [毎回] を選択すると、セッションの評価時に完全な再認証が必要になります。

ブラウズ セッションの永続化

永続的なブラウザー セッションでは、ユーザーはブラウザー ウィンドウを閉じてから再度開いた後でもサインインした状態を維持できます。

ブラウザー セッションの永続化に関する Microsoft Entra ID の既定値により、個人用デバイスのユーザーは、認証が成功した後に「サインインの状態を維持しますか?」というプロンプトを表示して、セッションを永続化するかどうかを選択できます。 「AD FS シングル サインオンの設定」の記事のガイダンスを使用して AD FS でブラウザー永続化が構成されている場合、そのポリシーに従って、Microsoft Entra セッションも永続化します。 また、企業ブランド ウィンドウにある設定で該当する設定を変更することにより、テナント内のユーザーに "サインインの状態を維持しますか?" というプロンプトを表示するかどうかを構成することもできます。

永続的なブラウザーでは、ユーザーがブラウザーを閉じても、Cookie はユーザーのデバイスに保存されたままになります。 これらの Cookie から Microsoft Entra 成果物にアクセスできる可能性があり、これらの成果物は、リソース環境に配置された条件付きアクセス ポリシーに関係なく、トークンの有効期限が切れるまで使用できます。 そのため、トークンのキャッシュは、認証に必要なセキュリティ ポリシーに直接違反する可能性があります。 トークンを現在のセッションを超えて保存することは便利に思えるかもしれませんが、これを行うと、Microsoft Entra 成果物への不正アクセスが許可され、セキュリティの脆弱性が発生する可能性があります。

認証セッション コントロールの構成

条件付きアクセスは、Microsoft Entra ID P1 または P2 機能であり、Premium ライセンスが必要です。 条件付きアクセスの詳細については、「Microsoft Entra ID における条件付きアクセス」を参照してください。

警告

現在、パブリック プレビューで構成可能なトークン有効期間機能を使用している場合、同一のユーザーまたはアプリの組み合わせに対し、異なる 2 つのポリシー (1 つはこの機能で、もう 1 つは構成可能なトークン有効期間機能で使用) を作成することはサポートしていないことに注意してください。 Microsoft は、2021 年 1 月 30 日に更新およびセッション トークン有効期間の構成可能なトークン有効期間機能を廃止し、条件付きアクセス認証セッション管理機能に置き換えました。

[サインインの頻度] を有効にする前に、テナントで他の再認証設定が無効になっていることを確認してください。 [信頼されたデバイスで MFA を記憶する] が有効になっている場合は、[サインインの頻度] を使用する前に必ず無効にしてください。この 2 つの設定を一緒に使用すると、ユーザーに予期せずにメッセージが表示される可能性があります。 再認証のプロンプトとセッションの有効期間の詳細については、「再認証プロンプトを最適化し、Microsoft Entra 多要素認証のセッションの有効期間を理解する」の記事を参照してください。

次のステップ