Microsoft Entra ID Protectionの「risk detections（リスク検出）」は、単なるアラート一覧ではありません。サインインやユーザー単位で「侵害の可能性」を評価し、Conditional Access、Microsoft Graph API、SIEM連携、インシデント対応の起点になる重要なシグナルです。
2026年4月更新で特に押さえるべき点は、MFA承認を悪用するフィッシング系の検出が、サインインリスク検出として明確に整理されたことです。表示名は「Suspicious MFA authentication approval」、riskEventTypeはauthenticatorPhishingで、Microsoft Authenticatorのテレメトリや未知のプロパティを使い、Password + MFAのセッションで疑わしい承認をリアルタイムに検出します。Microsoft公式ドキュメントではMicrosoft Entra ID P2が必要なPremium検出として掲載されています。(GitHub)
セキュリティ管理者、ID管理チーム、コンプライアンス担当者は、今回の更新を「新しい検出名を知る」だけで終わらせず、Conditional Access、Microsoft Graph API、Microsoft SentinelやSIEMのフィルター、インシデント対応手順まで見直すのが実務上のポイントです。
Microsoft Entra ID Protectionのrisk detectionsとは
Microsoft Entra ID Protectionのrisk detectionsは、組織内の疑わしいサインインやユーザーアクティビティを検出する仕組みです。検出結果は、Risk detections、Risky sign-ins、Risky usersなどのレポートに反映され、Conditional Accessによるアクセス制御や、SIEMでの相関分析にも利用できます。(Microsoft Learn)
重要なのは、risk detectionsを「誰かが危ないかもしれない」という曖昧な通知ではなく、ID侵害の調査を始めるための構造化データとして扱うことです。
たとえば、以下のような判断に使えます。
| 判断したいこと | risk detectionsで見るポイント | 実務での使い方 |
|---|---|---|
| そのサインインを許可してよいか | サインインリスク、リスクレベル、検出タイミング | Conditional AccessでMFA要求、ブロック、再認証を実施 |
| ユーザーアカウントが侵害された可能性があるか | ユーザーリスク、漏洩資格情報、異常なトークン、PRT関連の検出 | パスワードリセット、セッション失効、MFA再登録を実施 |
| 監査証跡として何を残すべきか | riskEventType、riskLevel、riskState、検出日時、IP、相関ID | Microsoft Graph APIやSIEMに連携して保存 |
| 誤検知かどうか | 端末、場所、IP、User-Agent、アプリ、過去の行動 | 出張、VPN、業務用クラウドサービス利用と照合 |
Microsoft GraphのriskDetectionリソースでは、riskEventType、riskLevel、riskState、detectedDateTime、lastUpdatedDateTime、correlationId、requestId、additionalInfoなどを取得できます。APIやSIEMで運用している組織では、表示名だけでなくriskEventTypeを基準にルールを作ることが重要です。(Microsoft Learn)
2026年4月更新で注目すべきポイント
Microsoft Learnの該当ページはメタデータ上では2026年4月22日更新ですが、MicrosoftDocsの公開リポジトリでは2026年4月23日に「rename-detection」コミットが記録されています。実務上は、4月22日から23日にかけて整理された更新として捉えると分かりやすいです。(GitHub)
| 更新・確認ポイント | 内容 | 管理者が取るべき対応 |
|---|---|---|
| Suspicious MFA authentication approvalが掲載 | Password + MFAのセッションで、未知のASN、ブラウザー、デバイス、GPS位置情報、Authenticatorアプリのテレメトリなどを使って疑わしいMFA承認を検出 | Highリスクとして扱い、サインインブロック、セッション失効、ユーザー確認の手順を整備 |
riskEventTypeはauthenticatorPhishing | 表示名は変更されても、APIやSIEM側ではイベントタイプで検出する必要がある | Sentinel、Splunk、Defender XDR、独自SOARのフィルターを確認 |
| Premium検出として整理 | Microsoft Entra ID P2が必要な検出として掲載 | P2未導入テナントでは詳細が見えない可能性を前提に運用設計 |
| 検出名が整理された | GitHub履歴では、当初の「Authenticator-assisted phishing detection」から「Suspicious MFA authentication approval」へ名称変更 | 手順書、教育資料、アラート名、ナレッジベースを新名称に更新 |
| Highリスクとして明記 | 4月22日のコミットで、疑わしいMFA承認のサインイン試行をHigh riskとしてフラグする記述が追加 | Highリスク時のConditional Accessポリシーを再点検 |
特に注意したいのは、MFAが有効でも安全とは限らない点です。攻撃者が認証フローを誘導し、ユーザーにMFA承認を押させる攻撃では、単に「MFA成功」とだけ見ていると侵害を見逃します。今回の検出は、承認要求側と承認側の状況、未知のプロパティ、Authenticatorアプリ由来のシグナルを組み合わせて、攻撃者主導のセッションを見分ける方向に寄せたものです。(Microsoft Learn)
サインインリスク検出とユーザーリスク検出の違い
risk detectionsは大きく分けて、サインインリスク検出とユーザーリスク検出があります。混同すると、対応の優先順位を間違えやすくなります。
| 種類 | 見ている対象 | 代表的な検出 | 初動対応の考え方 |
|---|---|---|---|
| サインインリスク検出 | その認証要求が正規ユーザーによるものか | Anonymous IP address、Atypical travel、Password spray、Unfamiliar sign-in properties、Suspicious MFA authentication approval、Verified threat actor IP | そのサインインを許可するか、MFA要求・ブロック・再認証を行うかを判断 |
| ユーザーリスク検出 | アカウント自体が侵害されている可能性 | Leaked credentials、Anomalous Token、Attacker in the Middle、Possible attempt to access PRT、Suspicious API Traffic、User reported suspicious activity | パスワードリセット、セッション失効、MFA再登録、権限見直しを検討 |
サインインリスクは「今このログインを通してよいか」の判断に直結します。一方、ユーザーリスクは「このアカウントを信頼し続けてよいか」を判断するための材料です。Microsoft公式ドキュメントでは、サインインリスク検出とユーザーリスク検出の一覧がriskEventTypeとともに整理されています。(Microsoft Learn)
実務で優先して確認したい検出
すべての検出を同じ重みで扱うと、対応が遅れます。特にID侵害の実害につながりやすい検出は、インシデント対応の優先度を高く設定してください。
| 検出 | なぜ重要か | 推奨アクション |
|---|---|---|
| Suspicious MFA authentication approval | MFA承認を悪用したソーシャルエンジニアリングやフィッシングの可能性がある | 該当サインインを調査し、必要に応じてユーザーをブロック、パスワードリセット、セッション失効 |
| Leaked credentials | 有効な資格情報が既知の漏洩情報と一致したことを示す | 直ちにパスワードリセット、サインイン履歴確認、他サービスでの使い回し確認 |
| Attacker in the Middle | 悪意あるリバースプロキシを使った認証セッションの可能性がある | トークン窃取を前提にセッション失効、MFA再登録、端末確認 |
| Anomalous Token | トークンの異常な利用やトークンリプレイの可能性がある | IP、アプリ、User-Agent、場所を確認し、セッションを失効 |
| Password spray | 攻撃者がユーザーのパスワード検証に成功したことを示す | パスワード変更、同様のIP・ASN・プロトコルからの試行を横断調査 |
| Possible attempt to access PRT | Primary Refresh Tokenへのアクセス試行の可能性がある | 端末侵害や横展開を疑い、Defender for Endpoint側の調査も実施 |
| Suspicious API Traffic | 異常なGraph APIトラフィックやディレクトリ列挙の可能性 | アプリ権限、管理者操作、ディレクトリ変更を確認 |
Microsoftの調査ガイドでは、リスク検出後にサインインログ、アプリ、端末、場所、IPアドレス、User-Agentを確認し、必要に応じてパスワードリセット、MFA、ユーザーブロック、リフレッシュトークン失効を行う流れが示されています。(Microsoft Learn)
リアルタイム検出とオフライン検出を分けて考える
risk detectionsには、リアルタイムで計算されるものと、サインイン後にオフラインで計算されるものがあります。この違いを理解していないと、「なぜ後からリスクが上がったのか」「なぜサインイン時に止められなかったのか」を説明できません。
| 検出タイミング | 特徴 | 運用上の意味 |
|---|---|---|
| リアルタイム | サインイン時点で評価される | Conditional Accessで即時にMFA要求、ブロック、パスワード変更を実施しやすい |
| オフライン | サインイン後に追加分析される | 侵害の経路や影響範囲の調査に向く。後からユーザーリスクが上がる可能性がある |
| リアルタイムまたはオフライン | 検出によって両方の可能性がある | レポート反映の遅延を前提に、継続監視が必要 |
Microsoft公式ドキュメントでは、リアルタイム検出の詳細がレポートに表示されるまで5〜10分、オフライン検出は最大48時間かかる場合があると説明されています。また、低リスクは6か月後に自動的に期限切れとなり、中・高リスクは修復または却下されるまで残ります。(Microsoft Learn)
つまり、サインイン時に問題がなかったように見えても、後からオフライン検出でリスクが付与されることがあります。SOCやCSIRTは、リアルタイムブロックだけでなく、事後検出を拾う運用も設計しておく必要があります。
ライセンスで見える情報が変わる
Microsoft Entra ID Protectionのrisk detectionsは、ライセンスによって見える範囲が変わります。多くの詳細なリスク検出にはMicrosoft Entra ID P2が必要です。P2がない環境では、詳細な検出名ではなく「Additional risk detected」として表示される場合があります。(Microsoft Learn)
| ライセンス観点 | 注意点 |
|---|---|
| Microsoft Entra ID Free / P1 | 一部の検出は利用できるが、詳細情報が制限される場合がある |
| Microsoft Entra ID P2 | ID Protectionの詳細なレポート、リスク検出、リスクベースポリシー運用に必要 |
| Microsoft Defender製品 | Defender for Cloud Apps、Defender for Office 365、Defender for Endpoint由来のシグナルでは、該当製品のライセンスも確認が必要 |
| Microsoft 365 E5 | 多くのDefender連携シグナルを含めて運用しやすい構成になりやすい |
ここでよくある失敗は、「Microsoft 365を契約しているからすべて見える」と思い込むことです。実際には、Entra ID Protectionの詳細、Defender由来の検出、Graph APIでの取得、レポートの可視性は、プラン構成によって変わります。監査やインシデント対応を前提にするなら、検出名・詳細・API取得可否を事前に確認しておくべきです。
Conditional Accessで見直すべき設定
2026年4月更新を受けて、まず確認したいのはConditional Accessです。特に、Highリスクのサインインとユーザーリスクに対する動作が曖昧なままだと、せっかくの検出を防御に活かせません。
実務では、次のような方針を検討します。
| 条件 | 推奨される制御例 | 注意点 |
|---|---|---|
| Highのサインインリスク | アクセスブロック、または強力な認証要求 | 業務影響が大きい場合は対象ユーザーやアプリを段階展開 |
| Medium以上のサインインリスク | MFA要求、準拠デバイス要求 | VPNや海外拠点で誤検知が増えないか確認 |
| Highのユーザーリスク | セキュアなパスワード変更、セッション失効 | ユーザーがSSPRを使える状態か確認 |
| 管理者アカウント | より厳しいブロック条件や専用ポリシー | 緊急アクセスアカウントの除外設計も必要 |
| レガシー認証 | ブロックを基本に検討 | 古いプロトコルはリスク判断の材料が少なく、誤検知低減にも限界がある |
Microsoft公式ドキュメントでは、リスクレベルに応じてConditional Accessポリシーを設定し、MFAやパスワードリセットを要求できると説明されています。(Microsoft Learn)
特に「Suspicious MFA authentication approval」はHighリスクとして扱われるため、サインインリスクHigh時のポリシーが空白になっていないか確認してください。MFAを要求するだけでは不十分なケースもあります。MFA承認自体が攻撃に使われている可能性があるため、セッション失効やユーザー確認まで含めた対応が必要です。
Microsoft Graph APIやSIEM連携で確認すべき点
グローバル企業や大規模テナントでは、Microsoft Entra管理センターだけで全件を追うのは現実的ではありません。Microsoft Graph APIやSIEMに連携し、riskEventType単位で検出・通知・証跡保存を行う設計が必要です。
今回の更新では、特に以下を見直してください。
| 確認項目 | 見直す理由 |
|---|---|
riskEventType = authenticatorPhishingを拾えているか | 新しいMFA承認系フィッシング検出をSIEM側で見逃さないため |
| 表示名に依存したルールになっていないか | 検出名が変更されるとルールが機能しなくなる可能性があるため |
riskLevel = highの自動通知があるか | HighリスクをSOCが即時に確認できるようにするため |
riskStateの変化を記録しているか | confirmedCompromised、confirmedSafe、dismissedなどの判断履歴を監査に残すため |
correlationIdやrequestIdを保存しているか | サインインログ、Defender XDR、Sentinelとの突合に使うため |
| データ保持期間を補完しているか | 標準の保持期間だけでは監査要件を満たせない場合があるため |
Microsoft GraphのriskDetectionリソースは、リスク検出データにプログラムからアクセスするためのAPIです。ただし、利用可能なデータはMicrosoft Entraのデータ保持ポリシーに従うため、長期保管が必要な組織はLog Analytics、ストレージ、Event Hubs、SIEMなどへのエクスポートも検討する必要があります。(Microsoft Learn)
調査時の具体的な確認手順
リスク検出が出たら、次の順で確認すると対応漏れを減らせます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 検出タイプとリスクレベルを確認 | Highなら即時対応を優先 |
| 2 | 対象ユーザーの直近サインインを確認 | 見慣れない場所、IP、アプリ、端末、User-Agentがないか |
| 3 | 同じIP・ASN・アプリで他ユーザーも影響していないか確認 | パスワードスプレーや横断的攻撃の可能性を判断 |
| 4 | ユーザーに確認 | メールやTeamsが侵害されている可能性も考え、別経路で確認 |
| 5 | 必要に応じて封じ込め | パスワードリセット、ユーザーブロック、MFA再登録、セッション失効 |
| 6 | 事後調査 | メール転送ルール、アプリ登録、権限変更、ファイルアクセス、API操作を確認 |
| 7 | 状態を更新 | confirmedCompromised、confirmedSafe、dismissedなどを適切に記録 |
注意したいのは、ユーザー確認だけで安全と判断しないことです。攻撃者がメールボックスやTeamsにアクセス済みの場合、本人確認の連絡自体が攻撃者に届く可能性があります。Microsoftの調査ガイドでも、ユーザーに確認する際は、メールやTeamsが侵害されている可能性を考慮するよう示されています。(Microsoft Learn)
よくある失敗と回避策
「MFA成功だから安全」と判断する
MFAは重要ですが、MFA承認をユーザーに押させる攻撃では、MFA成功が安全の証明にはなりません。authenticatorPhishingやSuspicious MFA authentication approvalが出ている場合は、MFAを突破された可能性ではなく、MFA承認プロセスが悪用された可能性として扱うべきです。
P2なしで詳細調査できると思い込む
Microsoft Entra ID P2がないと、Premium検出の詳細が見えず「Additional risk detected」と表示される場合があります。SOCや監査チームが詳細な検出名を前提に運用するなら、ライセンスの見直しが必要です。
表示名でSIEMルールを作る
検出名は変更されることがあります。今回もGitHub履歴では名称変更が確認できます。SIEMやSOARでは、可能な限りriskEventTypeを基準にルールを作ってください。(GitHub)
VPNや海外拠点を未整理のまま運用する
Atypical travelやNew country系の検出では、出張、VPN、海外拠点、クラウドサービスのIPがノイズになることがあります。正規のVPNや拠点IPはNamed locationsに登録し、誤検知を減らす運用が必要です。Microsoftの調査ガイドでも、承認済みVPNのIP範囲をNamed locationsに追加する考え方が示されています。(Microsoft Learn)
セッション失効を忘れる
パスワードを変更しても、既存トークンが悪用される可能性があります。Anomalous Token、Attacker in the Middle、PRT関連の検出では、パスワードリセットだけでなく、リフレッシュトークンや既存セッションの失効も検討してください。
セキュリティ管理者・ID管理チーム・コンプライアンス担当者の次のアクション
今回の更新を受けて、まず行うべきことは次の3つです。
| 担当 | 次にやること |
|---|---|
| セキュリティ管理者 | Highリスクのサインイン・ユーザーリスクに対するConditional Accessポリシーを確認し、Suspicious MFA authentication approval発生時の対応を手順化する |
| ID管理チーム | Microsoft Entra ID P2、Defender連携、MFA、SSPR、Named locations、レガシー認証ブロックの状態を棚卸しする |
| コンプライアンス担当者 | riskEventType、リスク状態、対応履歴、セッション失効、ユーザー確認、証跡保存のルールを監査要件に合わせて整備する |
Microsoft Entra ID Protectionのrisk detectionsは、検出名を覚えるだけでは効果を発揮しません。riskEventTypeで機械的に拾い、Conditional Accessで即時制御し、Graph APIやSIEMで証跡を残し、インシデント対応手順に落とし込んで初めて実運用に効きます。
2026年4月更新では、特にMFA承認を悪用する攻撃への検出が実務上の注目点です。まずは自社テナントでauthenticatorPhishingを検知・通知できるか、Highリスク時のポリシーが機能するか、P2やDefender連携の前提が満たされているかを確認してください。
コメント