条件付きアクセスを使用して認証セッション管理を構成する

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

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

条件付きアクセス制御を使用すると、すべてのユーザーに影響を与えることなく、組織内の特定のユース ケースを対象とするポリシーを作成できます。

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

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

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

ユーザー サインインの頻度に関する 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

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

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

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

Sign in frequency and 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 10 Microsoft Entra 参加済みデバイスにサインインし、SharePoint Online に格納されているドキュメントで作業を開始します。
  • ユーザーはデバイス上の同じドキュメントで1時間、作業を継続します。
  • 01:00 では、ユーザーは管理者によって構成された条件付きアクセス ポリシーのサインイン頻度の要件に基づいて、もう一度サインインするように求められます。

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

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

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

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

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

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

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

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

再認証を毎回要求する

ユーザーが特定のアクションを実行する前に毎回、お客様が新しい認証を要求するシナリオがあります。 サインインの頻度には、時間または日数に加えて、毎回という新しいオプションがあります。

サポートされているシナリオ:

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

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

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

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

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

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

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

警告

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

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

ポリシーのデプロイ

ポリシーが期待どおりに機能することを確実にするために推奨されるベスト プラクティスは、運用環境にロールアウトする前にポリシーをテストすることです。 テスト テナントを使用して、新しいポリシーが意図したとおりに機能するかどうかを確認するのが理想的です。 詳細については、「条件付きアクセスのデプロイを計画する」を参照してください。

ポリシー 1:サインイン頻度コントロール

  1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。

  2. 保護>条件付きアクセス を参照します。

  3. [新しいポリシーの作成] を選択します。

  4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。

  5. ターゲット クラウド アプリなど、顧客の環境に必要なすべての条件を選択します。

    注意

    最高のユーザー エクスペリエンスが得られるように、Exchange Online や SharePoint Online などの主要な Microsoft Office アプリに、同じ認証プロンプト頻度を設定することをお勧めします。

  6. [アクセス制御]>[セッション] で以下の手順を実行します。

    1. [サインインの頻度] を選択します。
      1. [Periodic reauthentication] (定期的な再認証) を選択し、時間または日の値を入力するか、[Every time] (毎回) を選択します。
  7. ポリシーを保存します。

    Conditional Access policy configured for sign-in frequency

ポリシー 2:永続的ブラウザー セッション

  1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。

  2. 保護>条件付きアクセス を参照します。

  3. [新しいポリシーの作成] を選択します。

  4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。

  5. すべての必要な条件を選択します。

    注意

    このコントロールは条件として [すべてのクラウド アプリ] を選択する必要があることに注意してください。 ブラウザー セッション永続化は認証セッション トークンによって制御されます。 ブラウザー セッションのすべてのタブは 1 つのセッション トークンを共有するため、それらすべては永続性の状態を共有する必要があります。

  6. [アクセス制御]>[セッション] で以下の手順を実行します。

    1. [永続的ブラウザー セッション] を選択します。

      Note

      Microsoft Entra 条件付きアクセスの永続的なブラウザー セッション構成は、「サインインしたままですか?」をオーバーライドします。 両方のポリシーが構成されている場合、同じユーザーの企業ブランド ウィンドウにある「サインインの状態を維持しますか?」の設定を上書きします。

    2. ドロップダウンから値を選択します。

  7. ポリシーを保存します。

ポリシー 3: 危険なユーザーを毎回サインイン頻度コントロール

  1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
  2. 保護>条件付きアクセス を参照します。
  3. [新しいポリシーの作成] を選択します。
  4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
  5. [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
    1. [Include](含める) で、 [すべてのユーザー] を選択します。
    2. [除外] で、[ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
    3. [完了] を選択します。
  6. [ターゲット リソース]>[クラウド アプリ]>[対象] で、[すべてのクラウド アプリ] を選びます。
  7. [条件]>[ユーザー リスク] で、 [構成][はい] に設定します。 [ポリシーを適用するために必要なユーザー リスクのレベルを構成します] で、 [高] を選択した後、 [完了] を選択します。
  8. [アクセス制御]>[付与] で、 [アクセスを許可][パスワードの変更を必須とする] の順に選択し、 [選択] を選択します。
  9. [セッション制御]>[サインインの頻度] で、[Every time] (毎回) を選択します。
  10. 設定を確認し、 [ポリシーの有効化][レポート専用] に設定します。
  11. [作成] を選択して、ポリシーを作成および有効化します。

管理者は、レポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。

検証

What If ツールを使用して、ポリシーをどのように構成したかに基づき、ユーザーからターゲット アプリケーションへのサインインおよび他の条件をシミュレートします。 認証セッションの管理コントロールが、ツールの結果に表示されます。

プロンプトの許容範囲

5 分の時刻のずれを考慮して、5 分に 1 回以下の頻度でユーザーにプロンプトを表示するようにします。 ユーザーが過去 5 分間に MFA を実行し、再認証を要求する別の条件付きアクセス ポリシーにヒットした場合、ユーザーにプロンプトは表示されません。 再認証のためにユーザーを過剰に昇格すると、生産性に影響を与え、ユーザーが開始しなかった MFA 要求を承認するリスクが高まる可能性があります。 特定のビジネス ニーズに対してのみ、"サインインの頻度 – 毎回" を使用します。

既知の問題

  • モバイル デバイスについてサインインの頻度を構成すると、サインイン頻度の間隔後の認証が低速になる場合があります (平均で 30 秒かかる可能性があります)。 また、さまざまなアプリで同時に発生する可能性もあります。
  • iOS デバイスについて: アプリで最初の認証要素として証明書が構成されており、アプリにサインインの頻度と Intune モバイル アプリケーション管理ポリシーの両方が適用されている場合、そのポリシーがトリガーされると、エンド ユーザーがアプリにサインインできなくなります。

次のステップ