条件付きアクセス のアダプティブ セッション有効期間ポリシーは、組織が複雑な展開で認証セッションを制限するのに役立ちます。 シナリオには以下が含まれます。
- 管理対象外のデバイスまたは共有デバイスからのリソース アクセス
- 外部ネットワークから機密情報へのアクセス
- 影響の大きなユーザー
- 重大なビジネス アプリケーション
条件付きアクセスでは、アダプティブ セッション有効期間ポリシー制御が提供され、すべてのユーザーに影響を与えることなく、組織内の特定のユース ケースを対象とするポリシーを作成できます。
ポリシーを構成する方法の詳細を確認する前に、既定の構成を調べてみましょう。
ユーザー サインインの頻度
サインインの頻度は、ユーザーがリソースにアクセスしようとしたときにサインインし直すように求められるまでの期間を定義します。
ユーザー サインインの頻度に関する Microsoft Entra ID の既定の構成は、90 日間のローリング ウィンドウです。 多くの場合、ユーザーに資格情報を求めることは賢明に思えますが、裏目に出る可能性があります。 考えずに資格情報を入力するようにトレーニングされたユーザーは、意図せずに悪意のある資格情報プロンプトに資格情報を提供する可能性があります。
ユーザーにサインインを求めないようにすると、警告が表示されることがありますが、IT ポリシー違反によってセッションが取り消されます。 たとえば、パスワードの変更、準拠していないデバイス、アカウントの無効化などです (ただし、これらに限定されません)。 また、Microsoft Graph PowerShell を使用して明示的にユーザーのセッションを取り消すことができます。 Microsoft Entra ID の既定の構成は、「セッションのセキュリティ体制が変更されなかった場合は、ユーザーに資格情報の入力を求めないでください」という内容になります。
サインイン頻度設定は、標準に従って OAuth2 または OIDC プロトコルを実装したアプリで動作します。 次の Web アプリケーションを含む Windows、Mac、Mobile などのほとんどの Microsoft ネイティブ アプリは、この設定に準拠しています。
- Word、Excel、PowerPoint Online
- OneNote オンライン
- Office.com
- Microsoft 365 管理者ポータル
- Exchange Online
- SharePoint と OneDrive
- Teams Web クライアント
- Dynamics CRM オンライン
- Azure Portal
サインイン頻度 (SIF) は、独自の Cookie を削除せず、認証のために定期的に Microsoft Entra ID にリダイレクトされる限り、OAuth2 または OIDC プロトコルを実装する Microsoft 以外の SAML アプリケーションおよびアプリで動作します。
ユーザーのサインイン頻度と多要素認証
サインイン頻度は、以前は Microsoft Entra 参加済みデバイス、Microsoft Entra ハイブリッド参加済みデバイス、Microsoft Entra 登録済みデバイス上の最初の要素認証にのみ適用されていました。 顧客がこれらのデバイスで多要素認証を強化する簡単な方法はありませんでした。 お客様からのフィードバックに基づいて、サインイン頻度が多要素認証 (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 を更新できます。
注
ユーザーのログインからキャプチャされたタイムスタンプは、更新サイクルが 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 にリダイレクトします。
管理者は、ユーザーに毎回再認証を要求するポリシーを適用するアプリケーションの数を制限する必要があります。 再認証を頻繁にトリガーすると、ユーザーが MFA の疲労を経験し、フィッシングの扉を開く原因となるまで、セキュリティの摩擦が高まる可能性があります。 通常、Web アプリケーションでは、有効になるたびに再認証が必要な場合に、デスクトップ アプリケーションよりも中断の少ないエクスペリエンスを提供します。 ポリシーで [毎回] が選ばれている場合、5 分の時刻のずれを考慮して、5 分に 1 回以下の頻度でユーザーにプロンプトを表示するようにします。
警告
サインイン頻度を使用して、多要素認証なしで毎回再認証を要求すると、ユーザーのサインイン ループが発生する可能性があります。
- Microsoft 365 スタックのアプリケーションでは、ユーザー エクスペリエンスを向上させるために、時間ベースのユーザー サインイン頻度を使うことをお勧めします。
- Azure portal と Microsoft Entra 管理センターでは、ユーザー エクスペリエンスを向上させるために、 時間ベースのユーザー サインイン頻度 を使用するか、認証コンテキストを使用して PIM アクティブ化の再認証を要求 することをお勧めします。
ブラウズ セッションの永続化
永続的なブラウザー セッションを使用すると、ユーザーはブラウザー ウィンドウを閉じてから再度開いた後もサインインを維持できます。
ブラウザー セッション永続化の既定の 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 多要素認証のセッションの有効期間を理解する」の記事を参照してください。
次のステップ
- 条件付きアクセス ポリシーでセッションの有効期間を構成する
- 環境の条件付きアクセス ポリシーを構成するには、「 条件付きアクセスの展開を計画する」の記事を参照してください。