セッション管理と継続的アクセス評価を実装する

  • 3 分

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

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

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

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

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

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

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

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

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

  • Word、Excel、PowerPoint Online
  • OneNote オンライン
  • Office.com
  • Microsoft 365 管理者ポータル
  • Exchange Online
  • SharePoint と OneDrive
  • Teams Web クライアント
  • Dynamics CRM オンライン
  • 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 ツールの結果のスクリーンショット。

ポリシーの展開

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

継続的アクセス評価 (CAE)

トークンの有効期限と更新は、業界の標準メカニズムです。 Outlook などのクライアント アプリケーションが Exchange Online などのサービスに接続する場合、API 要求は OAuth 2.0 アクセス トークンを使用して承認されます。 既定では、アクセス トークンは 1 時間有効です。有効期限が切れると、クライアントは Microsoft Entra ID にリダイレクトされて、トークンは更新されます。 この更新期間によって、ユーザー アクセスのポリシーを再評価する機会を得られます。 たとえば、条件付きアクセス ポリシーのため、またはディレクトリでユーザーが無効になったために、トークンを更新しないことを選択する場合があります。

ただし、ユーザーの状態が変化してから、ポリシーの変更が適用されるまでには、遅延があります。 ポリシー違反やセキュリティの問題にタイムリーに対応するには、トークン発行者と証明書利用者 (対応アプリ) の間での "会話" が必要です。 この双方向の対話では、2 つの重要な機能が提供されます。 証明書利用者は、ネットワークの場所など、プロパティがいつ変更したかを確認し、トークンの発行者に通知できます。 また、アカウントの侵害、無効化、またはその他の懸念事項のために、特定のユーザーのトークンへの信用を停止するよう証明書利用者に指示する方法が、トークン発行元に提供されます。 この対話のメカニズムは、継続的アクセス評価 (CAE) と呼ばれます。

メリット

継続的アクセス評価には、いくつかの重要な利点があります。

  • ユーザーの終了またはパスワードの変更/リセット: ユーザー セッションの失効がほぼリアルタイムで適用されます。
  • ネットワークの場所の変更: 条件付きアクセスの場所のポリシーがほぼリアルタイムで適用されます。
  • 条件付きアクセスの場所のポリシーにより、信頼されたネットワークの外部にあるコンピュータへのトークンのエクスポートを防止できます。

評価と失効のプロセス フロー

アクセス トークンが失効となり、クライアントがアクセスを再検証する必要がある場合のプロセス フローの図。

  1. 継続的アクセス評価 (CAE) 対応のクライアントが、Microsoft Entra ID に対して資格情報または更新トークンを提示し、何らかのリソースのアクセス トークンを要求します。
  2. アクセス トークンは、他の成果物と共にクライアントに返されます。
  3. 管理者は、ユーザーのすべての更新トークンを明示的に失効します。 失効イベントは、Microsoft Entra ID からリソース プロバイダーに送信されます。
  4. リソース プロバイダーにアクセス トークンが提示されます。 リソース プロバイダーは、トークンの有効性を評価し、ユーザーの失効イベントがあるかどうかを確認します。 リソース プロバイダーは、この情報を使用して、リソースへのアクセスを許可するかどうかを決定します。
  5. この図の場合、リソース プロバイダーはアクセスを拒否し、401+ 要求チャレンジをクライアントに送り返します。
  6. CAE 対応クライアントは、401+ クレームチャレンジに対応します。 キャッシュをバイパスし、手順 1 に戻り、要求チャレンジと共に更新トークンを Microsoft Entra ID に送り返します。 その後、Microsoft Entra ID ですべての条件が再評価され、この場合はユーザーに再認証を求めるメッセージが表示されます。