Microsoft Entra ID Protection に関してよく寄せられる質問

リスクをシミュレートする方法のガイドがあります。 このガイドでは、さまざまな種類のリスクをシミュレートするためのいくつかのオプションを提供します。 また、条件付きアクセス WhatIf ツールを使用して、特定のポリシーがどのように適用されるかを確認することもできます。 We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need.

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

Identity Protection は、正しい資格情報が使用されている場合にのみ、リスク検出を生成します。 サインイン時に間違った資格情報が使用されている場合に、資格情報の侵害のリスクを示すものではありません。

資格情報漏洩などのリスク検出では、検出を行うため、パスワード ハッシュが存在する必要があります。 パスワード ハッシュ同期の詳細については、「 Microsoft Entra Connect Sync を使用したパスワード ハッシュ同期の実装」を参照してください。

まず、無効な状態のユーザー アカウントを再び有効にできることを知る必要があります。 無効になっているアカウントの資格情報が侵害され、そのアカウントが再度有効になった場合、不正なアクターがアクセス権を取得するためにそれらの資格情報を使用する可能性があります。 ID Protection は、アカウント侵害の可能性があることをお客様に警告するために、これらの無効なアカウントに対する不審なアクティビティのリスク検出を生成します。

アカウントが使用されなくなり、再び有効にならない場合は、侵害を防ぐためにアカウントを削除することを検討する必要があります。 削除されたアカウントに対してリスク検出は生成されません。

Sorting by Detection time in the Risk detections report might not always give the correct result because of a known technical constraint. To sort by Detection time, open the report in the Microsoft Entra admin center and select Download to export the data as a CSV file and sort accordingly.

Microsoft では、次のようなさまざまな場所で、漏洩した資格情報を探します。

• 悪意のあるアクターが通常このような素材を投稿するパブリック貼り付けサイト。
• 法執行機関。
• 闇サイトのリサーチを行っている Microsoft の他のグループ。

漏洩した資格情報は、検出された直後に、通常は 1 日に複数のバッチで処理されます。

漏洩した資格情報は、Microsoft が公開されている新しいバッチを検出するたびに処理されます。 その機密性のため、漏洩した資格情報は、処理の直後に削除されます。 Only new leaked credentials found after you enable password hash synchronization (PHS) are processed against your tenant. 前に検出されていた資格情報ペアに対する検証は実行されません。

テナントの ID 保護で漏洩した資格情報がどのように表示されるかを確認するには、GitHub for Workload Ids で漏洩した資格情報をシミュレートしてみてください。 詳細については、「 Microsoft Entra ID Protection でリスク検出をシミュレートする」を参照してください。

漏洩した資格情報リスク イベントが確認されていない場合、次のような理由が原因です。

• テナントに対してパスワード ハッシュ同期が有効になっていません。
• お客様のユーザーと一致する、漏洩した資格情報のペアを Microsoft が見つけていません。

ID Protection は、ユーザーがリスクの高いサインインの後に多要素認証 (MFA) などの第 2 要素をすぐに提供すると、サインイン リスクを自動修復します。 この 2 つ目の要素を指定すると、強力な認証が構成されます。

ID Protection では、サインイン時のリスク評価用に 2 つのモデルも動作します。1 つ目は、サインイン時に限られた情報を使用して迅速な判断を行うリアルタイム モデルです。 2 つ目は、サインインが完了したら他のサインイン データを使用するオフライン モデルです。 オフライン モデルは、リスク スコアを安全として再評価すると、リスクを閉じる可能性があります。 この評価は、リスク レベルのリアルタイム検出とオフライン検出に適用されます。

ID Protection は、ユーザー リスクの昇格なしで 6 か月後にユーザー リスクが低いユーザーを自動解決します。 リスクが中程度または高の危険なユーザーは、リスク ポリシーまたは管理者の解雇なしでは自動解決されません。

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

フィッシングに強いパスワードレス認証の展開に関するガイダンスを確認する: フィッシングに対するパスワードレス認証の展開を開始する

この設定は、組織のリスク許容度によって異なります。 組織によっては、高リスクをブロックすることを選択する場合があります。 サインインを毎回強制すると、サインインや MFA の疲労が発生し、フィッシング攻撃の可能性が高くなる可能性があります。

We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need. ID Protection のリスクベースのポリシーブックの影響分析を確認することもできます。

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

詳細については、「 リスクを修復し、ユーザーのブロックを解除する方法」を参照してください。

システムは、すべての修復に対して条件付きアクセス ポリシーで指定された許可コントロールに依存します。 このポリシー駆動型のアプローチでは、リソースへのアクセスをより詳細に制御できます。 ユーザー リスク ポリシーにブロックが必要な場合は、条件付きアクセスによって適用されます。 サインイン リスク ポリシーで MFA が必要な場合は、条件付きアクセスによって新しい MFA チャレンジが適用されます (既存のトークンに MFA 要求がない場合)。 そのため、Alice が別の MFA ポリシーのおかげで常にリスクの高いサインインを自動修復していた場合、MFA を必要とするリスク ポリシーをデプロイしても、ユーザー エクスペリエンスは何も変更されません。

Microsoft Entra ID Protection には、さまざまなライセンスを必要とする機能がいくつかあります。 たとえば、Microsoft Entra ID Free ライセンスを使用して危険なサインイン レポートに限られた情報を取得できますが、Microsoft Entra ID P2 または Microsoft Entra Suite ライセンスを使用してこれらのレポートにフル アクセスできます。 詳細については、 Microsoft Entra ID Protection のライセンス要件を参照してください。

Microsoft Entra ID Protection では、個別にライセンスが付与された Microsoft Defender 製品からのシグナルも使用されます。 詳細については、Microsoft Entra ID Protection の概要に関する記事を参照してください。

B2B ユーザーのリスク評価と修復はホーム ディレクトリで行われるため、ゲスト ユーザーはリソース ディレクトリの危険なユーザー レポートに表示されません。 リソース ディレクトリの管理者は、これらのユーザーに対してセキュリティで保護されたパスワードのリセットを強制することはできません。

ディレクトリ内の危険な B2B ユーザーがリスクベースのポリシーによってブロックされた場合、そのユーザーは自分のホーム ディレクトリでそのリスクを修復する必要があります。 ユーザーは、ホーム ディレクトリでセキュリティで保護されたパスワードリセットを実行することで、リスクを修復できます。 ホーム ディレクトリでセルフサービス パスワード リセット が有効になっていない場合は、自分自身で組織の IT スタッフに連絡して、管理者にリスクを手動で無視してもらうか、パスワードをリセットしてもらう必要があります。 詳細については、「 ユーザー リスクの修復」を参照してください。

B2B ユーザーを組織のリスクベースの条件付きアクセス ポリシーから除外すると、B2B ユーザーがリスク評価の影響を受けなくなります。 これらの B2B ユーザーを除外するには、組織のすべてのゲストユーザーを含むグループを Microsoft Entra ID に作成します。 その後、このグループを、組み込みの ID Protection ユーザー リスク ポリシーとサインイン リスク ポリシー、およびサインイン リスクを条件として使用している条件付きアクセス ポリシーの除外対象として追加します。