セッション管理を実装する

完了

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

  • 管理対象外のデバイスまたは共有デバイスからのリソース アクセス。
  • 外部ネットワークからの機密情報へのアクセス。
  • 優先度の高いユーザーまたはエグゼクティブ ユーザー。
  • 重大なビジネス アプリケーション。

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

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

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

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

ユーザー サインインの頻度に関する Microsoft Entra ID の既定の構成は、90 日間のローリング ウィンドウです。 ユーザーに資格情報の入力を求めるのは、多くの場合、賢明な方法と考えられますが、逆効果もあり得ます。考えることなく資格情報を入力する習慣がついているユーザーが、悪意のある資格情報プロンプトで、自分の情報を誤って入力する可能性があります。

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

サインイン頻度設定は、標準に従って OAUTH2 または OIDC プロトコルを実装したアプリで動作します。 次の Web アプリケーションを含め、Windows、Mac、モバイル用のほとんどの 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 にリダイレクトされる限り、SAML アプリケーションでも機能します。

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

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

サインイン頻度を使用した多要素認証サインイン プロセスの図。

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

Microsoft Entra 参加済み、ハイブリッド Microsoft Entra 参加済み、または Microsoft Entra 登録済みデバイスがある場合、ユーザーがデバイスのロックを解除するか、対話形式でサインインすると、このイベントはサインイン頻度ポリシーも満たします。 次の 2 つの例では、ユーザーのサインイン頻度が 1 時間に設定されています。

例 1:

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

例 2:

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

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

永続的なブラウザー セッションでは、ユーザーはブラウザー ウィンドウを閉じてから再度開いた後でもサインインした状態を維持できます。 ブラウザー セッションの永続性に関する Microsoft Entra ID の既定値により、個人用デバイスのユーザーは、「サインインしたままですか?」というメッセージを表示してセッションを永続化するかどうかを選択できます。 選択できるようにしています。

検証

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

条件付きアクセス What If ツールの結果のスクリーンショット。

ポリシーのデプロイ

ポリシーが期待どおりに機能することを確実にするために推奨されるベスト プラクティスは、運用環境にロールアウトする前にポリシーをテストすることです。 テスト テナントを使用して、新しいポリシーが意図したとおりに機能するかどうかを確認するのが理想的です。