ブック: リスク ベースのアクセス ポリシーの影響分析

すべてのユーザーに対してリスクベースの条件付きアクセス ポリシーを有効にすることをお勧めします。これを展開するには (望ましくない影響を把握するために)、時間、変更管理、場合によってはリーダーによる慎重な精査が必要になることはわかっています。 管理者に、これらのシナリオに自信をもって解決策を提供し、環境を迅速に保護するために必要な、リスクベースのポリシーを導入するための知識を提供します。

レポート専用モードでリスクベースの条件付きアクセス ポリシーを作成して、結果を得るために数週間/数か月待つ代わりに、リスクベースのアクセス ポリシーの影響分析ブックを使用すると、サインイン ログに基づいた影響をすぐに確認できます。

説明

ブックは、ユーザーのサインインをブロックしたり、多要素認証を要求したり、セキュリティ保護されたパスワードの変更を実行したりするポリシーを有効にする前に、環境を理解するのに役立ちます。 ユーザーが選んだサインインの日付範囲に基づいて、次のような詳細が提供されます。

• 次の概要を含む、推奨されるリスク ベースのアクセス ポリシーの影響の概要:
  • ユーザー リスクのシナリオ
  • サインイン リスクと信頼されているネットワークのシナリオ
• 一意のユーザーの詳細を含む影響の詳細:
  • 次のようなユーザー リスクのシナリオ:
    • リスク ベースのアクセス ポリシーによってブロックされなかった高リスク ユーザー。
    • リスク ベースのアクセス ポリシーによってパスワード変更を求められなかった高リスク ユーザー。
    • リスク ベースのアクセス ポリシーのためにパスワードを変更したユーザー。
    • リスク ベースのアクセス ポリシーのためにサインインできなかった危険なユーザー。
    • オンプレミスのパスワード リセットによってリスクを修復したユーザー。
    • クラウドベースのパスワード リセットによる修復によってリスクを修復したユーザー。
  • 次のようなサインイン リスクのポリシーのシナリオ:
    • リスク ベースのアクセス ポリシーによってブロックされなかった高リスク サインイン。
    • リスク ベースのアクセス ポリシーによる多要素認証を使って自己修復しない高リスク サインイン。
    • リスク ベースのアクセス ポリシーのために成功しなかった危険なサインイン。
    • 多要素認証によって修復された危険なサインイン。
  • 信頼されているネットワークとしてリストされない上位の IP アドレスを含むネットワークの詳細。

管理者は、この情報を使って、リスク ベースの条件付きアクセス ポリシーを有効にした場合、一定の期間影響を受ける可能性があるユーザーを確認できます。

ブックにアクセスする方法

このブックでは、レポート専用モードのものであっても、条件付きアクセス ポリシーを作成する必要はありません。 唯一の前提条件は、サインイン ログを Log Analytics ワークスペースに送信することです。 この前提条件を有効にする方法について詳しくは、「Microsoft Entra ブックの使用方法」をご覧ください。 [Identity Protection] ブレードでブックに直接アクセスすることも、編集可能なバージョンのブックに移動することもできます。

[Identity Protection] ブレードで、次の手順を実行します。

1. Microsoft Entra 管理センターにレポート閲覧者以上でサインインしてください。
2. Protection>Identity Protection>影響分析レポートを参照します。

ブックの場合:

1. Microsoft Entra 管理センターにレポート閲覧者以上でサインインしてください。
2. [ID]>[監視と正常性]>[ブック] の順に移動します。
3. [Identity Protection] の下の [Impact analysis of risk-based access policies] (リスク ベースのアクセス ポリシーの影響分析) ブックを選びます。

ブック内を移動する

ブック内に入ると、右上隅にいくつかのパラメーターがあります。 どのワークスペースからブックを作成するかを設定したり、ガイドのオンとオフを切り替えたりすることができます。

すべてのブックと同様に、視覚化のデータを抽出する Kusto 照会言語 (KQL) クエリを表示または編集できます。 変更を加えた場合は、いつでも元のテンプレートに戻すことができます。

まとめ

最初のセクションは概要であり、選択した時間の範囲内に影響を受けたユーザーまたはセッションの合計数が示されます。 さらに下にスクロールすると、関連する詳細が表示されます。

概要の中で扱われている最も重要なシナリオは、ユーザーおよびサインイン リスク シナリオの、シナリオ 1 と 2 です。 これらは、ブロックされなかった、パスワード変更を求められなかった、または MFA によって修復されなかった高リスク ユーザーまたはサインインを示します。つまり、高リスク ユーザーがまだ環境内にいる可能性があるということです。

それから下にスクロールして、それらのユーザーが正確に誰であるかの詳細を確認できます。 すべての概要コンポーネントには、それに対応する詳細が続きます。

ユーザー リスクのシナリオ

ユーザー リスク シナリオ 3 と 4 は、いくつかのリスクベースのアクセス ポリシーが既に有効な場合に役立ちます。パスワードを変更したユーザーが、またはリスクベースのアクセス ポリシーによってサインインがブロックされた高リスク ユーザーが表示されます。 高リスク ユーザーがユーザー リスク シナリオ 1 と 2 (ブロックされなかった、またはパスワード変更を求められなかった) の中にまだ表示される場合で、それらすべてのユーザーはシナリオ 3 や 4 に該当すると想定していた場合は、ポリシーにギャップがある可能性があります。

サインイン リスク シナリオ

次に、サインイン リスク シナリオ 3 と 4 を見てみましょう。 MFA を使用する場合は、有効なリスクベースのアクセス ポリシーが何もない場合でも、ここにアクティビティが発生する可能性があります。 MFA が正常に実行されると、サインイン リスクは自動的に修復されます。 シナリオ 4 では、リスクベースのアクセス ポリシーが原因で成功しなかった、高リスク サインインを確認します。 ポリシーを有効にしたにもかかわらず、ブロックされると想定している (または MFA で修復された) サインインが引き続き表示されている場合は、ポリシーにギャップがある可能性があります。 その場合は、ポリシーを確認し、このブックの詳細セクションを使用してギャップを調査することをお勧めします。

ユーザー リスク シナリオのシナリオ 5 と 6 は、修復が発生していることを示しています。 このセクションでは、オンプレミスから、またはセルフサービス パスワード リセット (SSPR) を使用して、パスワードを変更しているユーザー数に関する分析情報が提供されます。 これらの数値が環境とつじつまが合わない場合 (SSPR を有効にしていないはず、など) は、詳細を使用して調査します。

サインイン シナリオ 5 の信頼されていない IP アドレスでは、選択した時間の範囲内のすべてのサインインの IP アドレスと、信頼されていない IP アドレスが表示されます。

フェデレーション サインイン リスク ポリシーのシナリオ

複数の ID プロバイダーを使用している顧客の場合、(MFA またはその他の形式の修復のために) それらの外部プロバイダーにリダイレクトされる危険なセッションがあるかどうかを確認するのに、次のセクションが役立ちます。 このセクションでは、修復が行われている場所と、それが想定どおりに発生しているかどうかの分析情報が提供されます。 このデータを事前設定するには、フェデレーション環境内に “federatedIdpMfaBehavior” を設定して、フェデレーション ID プロバイダーからの MFA を適用する必要があります。

レガシ ID 保護ポリシー

次のセクションでは、環境内にまだ存在し、2026 年 10 月までに移行する必要があるレガシのユーザーおよびサインインのポリシー数を追跡します。 このタイムラインを認識し、できるだけ早く条件付きアクセス ポータルへのポリシーの移行を開始することが重要です。 新しいポリシーをテストし、不要または重複したポリシーを整理して、適用範囲にギャップがないことを確認するには、十分な時間が必要です。 レガシ ポリシーの移行の詳細については、「リスク ポリシーを移行する」のリンクを参照してください。

信頼されたネットワークの詳細

このセクションでは、信頼されていない IP アドレスの詳細な一覧が示されます。 これらの IP はどこから来て、誰が所有しているのでしょうか? "信頼された" と見なす必要があるのでしょうか? この課題は、ネットワーク管理者とのチーム間作業になる可能性があります。しかし、正確な信頼された IP 一覧があると、リスクの誤検知を減らすのに役立つため、実施すると有益です。 環境に対して疑わしいと思われる IP アドレスがある場合は調査します。

よくあるご質問:

多要素認証に Microsoft Entra を使用しない場合はどうすればよいですか?

Microsoft Entra 多要素認証を使用しない場合でも、Microsoft 以外の MFA プロバイダーを使用する場合は、環境内でサインイン リスクが修復される可能性があります。 外部認証方法を使用すると、Microsoft 以外の MFA プロバイダーを使用する場合のリスクを修復できるようになります。

ハイブリッド環境の場合はどうすればよいですか?

パスワード ライトバックでセルフサービス パスワード リセットが有効な場合は、セキュリティで保護されたパスワードの変更を使用して、ユーザー リスクを自己修復できます。 パスワード ハッシュ同期のみが有効な場合は、[オンプレミスのパスワード変更によるユーザー リスクのリセットを許可する] を有効にすることを検討してください。

高リスクのアラートをちょうど受け取ったのですが、なぜレポートの中に表示されていないのでしょうか?

ユーザーに高リスクが割り当てられたものの、まだサインインしていない場合は、このレポートの中に表示されません。 このレポートでは、サインイン ログのみを使用してこのデータを設定しています。 サインインしていない高リスク ユーザーがいる場合、このレポートの中にはカウントされません。

次のステップ

• Microsoft Entra ブックとは
• 方法: リスクの調査
• リスク検出とは