はじめに
近年は、フィッシング詐欺やパスワードスプレー攻撃、認証情報の窃取を狙った攻撃が増加しており、それらに AI が活用されるケースも見られるようになっています。
私自身、個人の検証用 Microsoft Entra テナント（いわゆる「諸般の誤家庭テナント」）を運用していますが、検証であっても不審なサインインやパスワードスプレー攻撃と思われるアクセスは心配です。組織で本運用されているテナントであれば、さらに多くの脅威にさらされていることでしょう。
一方で、認証基盤を守るためには、単に MFA を有効化するだけでなく、侵害された可能性のあるアカウントや不審なサインインを検出し、自動的に対処できる仕組みも重要です。
そこで活躍するのが Microsoft Entra ID 保護 (Identity Protection) です。
Microsoft Entra ID 保護を利用すると、Microsoft が収集・分析している膨大な脅威インテリジェンスを活用し、漏洩資格情報や不審なサインインを検出できます。また、条件付きアクセスと組み合わせることで、MFA の要求やパスワード変更、アクセスのブロックといった自動対処も実現できます。
私は以前、緊急アクセス用管理アカウント (Break glass) に関する記事を公開しましたが、今回はその続編として、Microsoft Entra ID 保護の導入方法や設計のポイント、運用時の考慮事項について解説していきます。
記事の全体像
ポイント
以下の Microsoft Support Blog では、ID 保護 についての考え方が説明されています。
こちらを一読いただくのが良いと思います。
Support Blog：Entra ID 初学者向けシリーズ第 2 弾 - ID Protection 入門 - その 1: ID Protection とは
https://jpazureid.github.io/blog/azure-active-directory/starter-series-id-protection-1/
1. 前提条件
Microsoft Entra ID 保護の前提条件は、ちょっとわかりづらいのですが、以下の公開情報をもとに私が読み解いた結果を記載しています。
Microsoft Entra ID 保護は、ライセンスやロールだけでなく、条件付きアクセスや多要素認証との組み合わせによって真価を発揮する機能です。
まずは、導入前に押さえておきたい前提条件を整理します。
1-1. 必須事項
1-1-1. ライセンス
Microsoft Entra ID Protection の機能をフルに利用し、リスクポリシーや詳細なリスクレポートを利用するには、Microsoft Entra ID P2 または Microsoft Entra Suite が必要です。
※Microsoft Entra ID P1 でも一部のリスク情報は確認できますが、詳細なリスク情報やリスクポリシーなどは含まれていません。
なお、以下のライセンスでも利用できます。
Microsoft 365 E5 / E7 , EMS E5
※E3 系列のライセンスや Microsoft 365 Business Premium は、Entra ID P2 を含みません。
追加で必要となるライセンス
ID 保護 は Entra ID P2 単体でも利用できます。
ただし、一部のリスク検出は Microsoft Defender 製品から提供されるシグナルを利用しているため、Defender 製品を導入していない場合は利用できない検出があります。
そのため、Microsoft 365 E5 や Defender Suite と組み合わせることで、Defender 製品由来のシグナルも活用でき、利用可能なリスク検出の範囲を広げることができます。
-
Microsoft Defender for Cloud Apps
- 匿名 IP アドレスからのアクティビティ
- あり得ない移動
- 機密ファイルへの大量アクセス
- 初めての国
-
Microsoft Defender for Office 365
- 疑わしい受信トレイルール
-
Microsoft Defender for Endpoint
- プライマリ更新トークン (PRT) への不正アクセスの兆候（PRTを狙った攻撃検知）
Microsoft Defender
https://learn.microsoft.com/ja-jp/entra/id-protection/overview-identity-protection?wt.mc_id=MVP_407731#microsoft-defender
Microsoft 365 Business Premium を利用している場合の考え方
Microsoft 365 Business Premium には Microsoft Entra ID P2 が含まれていないため、Microsoft Entra ID Protection の高度なリスクベース機能を利用するには追加ライセンスが必要です。
Microsoft Defender Suite for Business Premium には Microsoft Entra ID P2 に加え、Microsoft Defender for Cloud Apps、Microsoft Defender for Endpoint Plan 2、Microsoft Defender for Office 365 Plan 2 などが含まれています。
Microsoft Entra ID P2 単体と Microsoft Defender Suite for Business Premium が同価格帯 (2026/8/21時点で どちらも 1,499円) で提供されているため、Microsoft 365 Business Premium を利用している組織では、Microsoft Defender Suite for Business Premium を優先的に検討する価値があります。
また、Microsoft Entra Suite は Microsoft Entra ID P2 を含み、Global Secure Access や Microsoft Entra ID Governance を利用したい場合の選択肢です。
ただし、Microsoft Defender for Cloud Apps が含まれないため、Microsoft Defender 製品由来のシグナルを利用した一部のリスク検出は対象外となる点に注意が必要です。
既に他社製 CASB や EDR を利用している場合でも、ライセンス統合や運用簡素化の観点から Microsoft Defender Suite for Business Premium への移行を検討する価値があります。
Microsoft Defender Suite for Microsoft 365 Business Premium の価格
https://www.microsoft.com/ja-jp/security/pricing/small-medium-business/security-add-on-plans
Microsoft Entra のプランと価格
https://www.microsoft.com/ja-jp/security/business/microsoft-entra-pricing
また、Microsoft 365 Business Premium を利用する 300 名未満の組織であっても、Microsoft Entra ID Protection、Microsoft Defender for Endpoint、Global Secure Access、Microsoft 365 Copilot などを組み合わせて利用する場合など、必要な機能が増えてきた場合は、個別ライセンスの追加ではなく、Microsoft 365 E5 や Microsoft 365 E7 を含めてライセンス構成全体を見直すことも検討してください。
1-1-2. 管理者ロール
以下のいずれかのロールを持っている必要があります。
-
ID 保護 の設定を参照するため
- セキュリティ閲覧者
- グローバル閲覧者
-
ID 保護の運用・管理をするため
- セキュリティオペレーター
- セキュリティ管理者
-
条件付きアクセスポリシーを編集するため
- 条件付きアクセス管理者
- セキュリティ管理者
なお、グローバル管理者でも多くの操作は可能ですが、最小特権の原則から、日常運用では専用ロールを割り当て、必要に応じて Microsoft Entra PIM による Just-in-Time 有効化を利用することを推奨します。
ID 保護によるリスクの検出・確認・対応について
Microsoft Entra ID 保護によるリスクの検出・確認・対応は、Entra ID P2 ライセンス と 管理者ロール があれば、条件付きアクセスのポリシーを構成しなくても、Microsoft Entra 管理センターの画面から確認・対応できます。
検出されたリスクの確認方法や、管理者による手動での対応（リスクの無視、侵害の確認、パスワードリセットなど）の流れについては、以下の Microsoft Support Blog で詳しく解説されています。
Support Blog：Entra ID 初学者向けシリーズ第 2 弾 - ID Protection 入門 - その 2: リスクの検出/確認/対応
https://jpazureid.github.io/blog/azure-active-directory/starter-series-id-protection-2/
上記に対して、本記事では 条件付きアクセスポリシー を用いた運用の自動化の解説を目的にしています。
1-2. 本記事で有効化する機能
公開情報では ID 保護の利用は「推奨」とされていますが、レポートや分析機能を利用するだけであれば、ここまでの構成でも利用できます。
一方で、リスク検出時に自動対処を行う ID 保護ポリシーを利用するためには、条件付きアクセスが必要になります。
-
条件付きアクセスの有効化
サインインリスクポリシー・ユーザーリスクポリシー を適用させる場合に必要になります。
本記事では、Step 3 以降で必要な構成です。
以下の私の記事では、条件付きアクセス を構成するための情報をまとめています。
セキュリティの既定値群 と 条件付きアクセス の初回利用について
https://qiita.com/carol0226/items/51a70a561b78af567972
1-3. 推奨事項
現実的な運用を考えた場合、ID 保護 の導入とともに、以下の構成も併せて導入されていることが推奨です。
-
MFA の有効化
ID 保護 のリスクベースポリシーを使用した場合、リスクが高まった場合に 以下の追加要求をユーザーに求めることができます。- MFA を要求する
- パスワード変更を要求する
- ブロックする
MFA を要求するポリシーを利用する場合は、利用者が MFA を実施できるように構成しておく必要があります。
MFA は、本記事では、Step 2 以降で必要な構成です。
なお、以下の私の記事では、MFA を実現する方法の一つとして、FIDO2 セキュリティキーを利用した認証構成について紹介しています。
Microsoft Entra ID の認証を FIDO2 セキュリティキー で出来るようにする
https://qiita.com/carol0226/items/8586291079d941f62f7b
-
緊急アクセスアカウントの導入
以下の私の記事で解説しています。
緊急アクセス用管理アカウント (Break glass) 入門： 基本構成からセオリー外の追加構成まで解説
https://qiita.com/carol0226/items/bbd69bdc907a48f0e67f
-
Microsoft Entra PIM の導入
運用中の管理者アカウントに対しても ID 保護が適用される場合があります。
ID 保護 の適用によってテナントの管理に支障が出た場合の回復用として 緊急アクセスアカウントを用意し、Entra PIM を使った特権管理を運用しておくことを推奨します。
公開情報：Microsoft Entra Privileged Identity Management とは
https://learn.microsoft.com/ja-jp/entra/id-governance/privileged-identity-management/pim-configure?wt.mc_id=MVP_407731
-
Microsoft Entra のサインインログを Log Analytics に保存する
必須要件ではありませんが、Identity Protection の導入効果やリスク検出状況を長期的に分析するために、サインインログを Log Analytics に保存することを推奨します。
Microsoft Entra ID のログを Log Analytics に保存する
https://qiita.com/carol0226/items/ded21f16f67fece2cc65
なお、ユーザーリスクポリシーやサインインリスクポリシー自体の利用には必須ではありません。
2. 構成の進め方
- 2-1. Step 1：既存のレポートの確認
- 2-2. Step 2：条件付きアクセス リスク ポリシーの計画
- 2-3. Step 3：ポリシーの構成
2-1. Step 1：既存のレポートの確認
ID 保護ポリシーを構成する前に、ポリシーを適用した場合にどのような影響があるのかを事前に確認します。
これにより、利用者への影響や、ID 保護の導入によってどの程度のリスクが検出されるのかを把握できます。また、既に危険なユーザーや危険なサインインが存在していないかを確認し、必要に応じて事前に対応することもできます。
なお、本記事では確認方法として、条件付きアクセスの 「分析情報とレポート」ワークブック を利用します。この ワークブックを使用するには、サインインログを Log Analytics ワークスペースへ送信しておく必要があります。
一方で、Microsoft Entra ID Protection の 「危険なユーザー」、「危険なサインイン」、「リスク検出」 といったレポートは、Log Analytics を利用しなくても Microsoft Entra 管理センターから確認できます。
そのため、Log Analytics を利用していない環境では、本章で紹介する ワークブック による影響分析はスキップし、そのまま Step 2 へ進めても問題ありません。
公開情報：手順 1: 既存のレポートの確認
https://learn.microsoft.com/ja-jp/entra/id-protection/how-to-deploy-identity-protection?wt.mc_id=MVP_407731#step-1-review-existing-reports
Step 1 の進め方
Microsoft Entra 管理センターを開き、ID 保護 配下にある リスクベースの条件付きアクセス を開きます。次に、分析情報とレポート を開きます。以下の画面の 緑枠 の場所を確認します。
すべて または [Log Analyticsの名称] が表示されている場合は、以下のような表示になります。
この場合は、Step 1 の条件は満たしています。
0 項目が選択されました や <設定解除> となっている場合は、以下の表示になっています。
この場合は、サインインログの取得 を構成する必要があります。
サインインログ を Log Analytics に保存する方法は、以下の私の記事を参考にしてください。
Microsoft Entra ID のログを Log Analytics に保存する
https://qiita.com/carol0226/items/ded21f16f67fece2cc65
サインインログを取得するように構成したあとは、分析情報とレポート の画面で Workspace の欄で、すべて（または 該当の Log Analytics）を選択して、レポートが表示されることを確認します。
レポートの表示を確認して、どのようなユーザーに どのような影響があるのかをチェックしておきましょう。
なお、以下の公開情報には、分析レポートについて、詳細に説明されています。
公開情報：条件付きアクセスに関する分析情報とレポート
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/howto-conditional-access-insights-reporting?wt.mc_id=MVP_407731
以下は、私のテナントで出力されているレポートの内容です。
ユーザーのサインインレポート
サービスプリンシパルのサインインレポート
以下は、Entra Connect 同期のサービスアカウントが確認できています。
2-2. Step 2：条件付きアクセス リスク ポリシーの計画
Step 1 では、既存のサインイン状況やリスク状況を確認しました。
続いて Step 2 では、実際に ID 保護を有効化した場合にどのような影響が発生するのかを考慮しながら、リスクベースポリシーの設計を行います。
特に、ID 保護のポリシーはユーザーのサインインを制御する機能であるため、十分な事前検討を行わずに有効化すると、利用者がサインインできなくなったり、管理者アカウントが意図せずロックアウトされたりする可能性があります。
そのため、以下のポイントを整理しながら計画を進めることを推奨します。
- MFA が利用できる状態になっているか
- 除外すべきアカウントが存在しないか
- サービスアカウントへの影響はないか
- ネームドロケーションを構成すべきか
- レポート専用モードで検証するか
Microsoft では、まず十分な計画と検証を行ったうえで、段階的にリスクベースポリシーを展開することを推奨しています。
公開情報：手順 2: 条件付きアクセス リスク ポリシーの計画
https://learn.microsoft.com/ja-jp/entra/id-protection/how-to-deploy-identity-protection?wt.mc_id=MVP_407731#step-2-plan-for-conditional-access-risk-policies
2-2-1. 多要素認証を構成する
前提事項の章にも記載しましたが、Microsoft の推奨構成では リスク検出時に MFA を要求する構成が一般的です。
そのため、多要素認証を事前に導入しておくことを推奨します。
2-2-2. どのようなポリシーを構成するのかを設計する
2-2.章の冒頭の公開情報で、ポリシーの除外 という章があります。その章では、どのようなアカウントを 除外対象にすべきかを検討するように説明されています。
-
緊急アクセス (Break glass) アカウント
万が一、すべての管理者がロックアウトされてしまった場合の回避策として、除外設定します。
-
サービスアカウント、サービスプリンシパル
- Microsoft Entra Connect 同期アカウントなど
2-2-3. ネームドロケーション（信頼された場所）の構成
ネームドロケーションの機能によって、 信頼済みまたは既知としてマーク された場所が構成されていることが推奨です。
この設定を行うことで、ID 保護によるリスク評価の精度向上が期待できます。
信頼済みまたは既知としてマークされた場所から認証を受けると、これらのログインはユーザーのリスクを低減します。これにより、環境内での検出の一部における誤検知が減少します。
2-2-4. レポート専用モードで状況を見る
実際の影響を確認したい場合は、Step 3 の条件付きアクセスポリシーをレポート専用モードで構成し、ユーザーへの影響を確認してから ポリシーを有効化する方法もあります。
2-3. Step 3： ポリシーの構成
Step 2 では、除外するアカウントや MFA の準備状況、ネームドロケーションの利用有無などを整理し、リスクベースポリシーの設計を行いました。
続いて Step 3 では、その設計内容をもとに Microsoft Entra ID 保護の構成を実施します。
Microsoft の推奨構成では、まず多要素認証を利用できる状態を整えたうえで、ユーザーリスクポリシーやサインインリスクポリシーを段階的に有効化していきます。
また、本番環境へ展開する際には、いきなりポリシーを有効化するのではなく、レポート専用モードを活用して影響を確認しながら進めることが推奨されています。
本章では、Microsoft Learn で紹介されている推奨構成をもとに、Microsoft Entra ID 保護の構成方法と各ポリシーの考え方について解説します。
公開情報：手順 3: ポリシーの構成
https://learn.microsoft.com/ja-jp/entra/id-protection/how-to-deploy-identity-protection?wt.mc_id=MVP_407731#step-3-configure-your-policies
2-3-1. 多要素認証登録ポリシーの構成
以下のポリシーを構成することで、利用者が次回の対話型サインイン時から MFA 登録を求められるようになります。ユーザーは一定期間内に認証方法を登録する必要があるため、リスク検出時に MFA を要求できる状態を事前に整えられます。
公開情報：方法: 多要素認証登録ポリシーを構成する
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-configure-mfa-policy?wt.mc_id=MVP_407731
Microsoft Entra の登録キャンペーンを理解する ～パスキー導入に向けた挙動と展開のポイント～
https://qiita.com/carol0226/items/4ad04ffe2141f43ad6a1
2-3-2. 条件付きアクセスポリシー
多要素認証の利用準備ができたら、続いて Microsoft Entra ID 保護の中核機能であるリスクベースの条件付きアクセスポリシーを構成します。
条件付きアクセスポリシーを利用することで、Microsoft Entra ID 保護が検出したリスクをもとに、自動的に追加認証やアクセス制御を実施できるようになります。
例えば、
- リスクの高いサインインに対して MFA を要求する
- リスクの高いユーザーにパスワード変更を要求する
- 極めて危険な場合はサインインをブロックする
といった自動対処が可能になります。
これにより、管理者が都度対応しなくても、リスクに応じたアクセス制御を自動で適用できます。
公開情報：リスク ポリシーを構成して有効にする
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-configure-risk-policies?wt.mc_id=MVP_407731
本記事では、以下の公開情報で紹介されている推奨構成をベースに、ユーザーリスクポリシーとサインインリスクポリシーを構成することを前提として解説します。
公開情報：Microsoft の推奨事項
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-configure-risk-policies?wt.mc_id=MVP_407731#microsoft-recommendations
2-3-2-1. ユーザーリスク
一言でいうと、アカウント自体が侵害されている可能性を評価する仕組みです。
代表的な例は漏洩資格情報です。Microsoft は、ダークウェブや侵害データ、法執行機関やセキュリティ研究機関などから得られる情報をもとに、漏洩したユーザー名やパスワードの組み合わせを継続的に調査しています。
ただし、ユーザーリスクは漏洩資格情報だけを意味するものではありません。異常なトークン、異常なユーザーアクティビティ、PRT へのアクセス試行の可能性など、アカウント侵害の可能性を示す複数のシグナルもユーザーリスクとして扱われます。
これは「今回のサインインが怪しい」というより、「そのアカウント自体が侵害されている可能性がある」という考え方です。
そのため、多要素認証による本人確認やパスワード変更を要求し、攻撃者が継続して利用できない状態にすることが推奨されています。
ユーザーリスクポリシーの構成例
名前を付与します（ID 保護でユーザーリスクポリシーであることが分かる名前を推奨）
すべてのユーザーを対象に構成し、
Break glass アカウントと ディレクトリ同期アカウントを除外しています。
ターゲットリソースは、すべてのリソースを選択します。
条件では、ユーザーのリスクを選択し、高 を選択します（組織のニーズによって変更してください）
アクセス制御については、ユーザーリスクが高まった際に、ユーザーに対する制御を定めます。
アクセス権の付与 を選択して、多要素認証を要求する または 認証強度が必要 を選択します。
続けて リスクの修復が必要 にチェックを入れます（これが、ユーザーリスクポリシーの特長）
上記で、リスクの修復が必要 にチェックが入っていると、以下の欄は 強制的にチェックが入り変更はできません（グレーアウト）
初めは レポート専用 で構成し、状況を見極めてから オン に切り替えます。
公開情報：条件付きアクセスでのユーザー リスク ポリシー
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-configure-risk-policies?wt.mc_id=MVP_407731#user-risk-policy-in-conditional-access
2-3-2-2. サインインリスク
一言でいうと、不審なサインインの話です。
匿名 IP アドレスからのアクセスや、通常とは異なる地域からのサインインなど、不正アクセスの可能性がある認証を Microsoft が検出した場合、「サインインリスクあり」として判定されます。
例えば、旅行していないにもかかわらず海外から突然サインインが行われた場合や、匿名化サービス経由でサインインした場合などが該当します。
これは「アカウント自体が侵害されている可能性」ではなく、「今回のサインインが不正である可能性」を評価する仕組みです。
そのため、多要素認証による本人確認を要求したり、サインインをブロックしたりすることで、攻撃者によるアクセスを防止します。
サインインリスクポリシーの構成例
名前を付与します（ID 保護でサインインリスクポリシーであることが分かる名前を推奨）
すべてのユーザーを対象に構成し、
Break glass アカウントと ディレクトリ同期アカウントを除外しています。
ターゲットリソースは、すべてのリソースを選択します。
条件では、サインインのリスク を選択し、中 と 高 を選択します（組織のニーズによって変更してください）
アクセス制御については、サインインリスクが高まった際に、ユーザーに対する制御を定めます。
アクセス制御を設定する際の組み合わせの一例です。
（私の環境は、パスキー構成なので、一番右を選択）
サインインの頻度 を毎回に設定します。
初めは レポート専用 で構成し、状況を見極めてから オン に切り替えます。
公開情報：条件付きアクセスのサインイン リスク ポリシー
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-configure-risk-policies?wt.mc_id=MVP_407731#sign-in-risk-policy-in-conditional-access
公開情報：パスワードレス サインイン リスク ポリシーを更新する
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-configure-risk-policies?wt.mc_id=MVP_407731#update-your-passwordless-sign-in-risk-policy
以下の Microsoft Support Blog でも、ポリシーの構成手順が説明されています。
Support Blog：Entra ID 初学者向けシリーズ第 2 弾 - ID Protection 入門 - その 3: リスクベースのポリシーで自動的に管理
https://jpazureid.github.io/blog/azure-active-directory/starter-series-id-protection-3/
分析レポートの活用
Step 1 で構成した 分析情報とレポート を活用して、条件付きアクセスポリシーの レポート専用 から得られたログを分析することができます。
この分析をしながら、設定を オン にするまでの流れは、分析レポートの画面上に手順が記載されています。
このブックを使用して新しい条件付きアクセスポリシーをデプロイする手順
- 一般的に適用される条件付きアクセスポリシーについて確認します。
- 新しい条件付きアクセスポリシーを レポート専用モード で作成します。
- このレポートで、[条件付きアクセスポリシー]パラメーターから、影響の概要を調べるポリシーを選択します。
- 結果タイルをクリックし、[成功]、[失敗]、[ユーザー操作が必要です]、「適用されていません]のサインインに基づいてレポートをフィルター処理します。
- [条件とサインインの状態ごとの内訳]を調べ、ポリシーが意図したとおりに機能しているかどうかを確認します。
- 必要に応じてポリシーを編集するか、ポリシーの状態をレポート専用から オン に切り替えます。
- このレポートで、[条件付きアクセスポリシー]パラメーターから“有効なすべてのポリシー”を選択して、有効なすべてのポリシーの影響を表示します。
3. 動作確認（シミュレーション）
ここまでの手順で、ID 保護 の構成は完了しました。
しかし、実際にポリシーが期待どおりに動作するかどうかは、構成しただけでは確認できません。
特に、ユーザーリスクやサインインリスクは、実際の攻撃や不審なサインインが発生した場合にのみ検出されるため、本番環境で初めて動作を確認することは避けたいところです。
そこで Microsoft では、検証環境でリスク検出をシミュレートする方法を提供しています。
シミュレーションを実施することで、
- ユーザーリスクが正しく検出されるか
- サインインリスクが正しく検出されるか
- 条件付きアクセスポリシーが期待どおりに動作するか
- MFA の要求やパスワード変更要求が適切に行われるか
といった点を事前に確認できます。
本番運用を開始する前に、一度は動作確認を実施しておくことを推奨します。
公開情報：Microsoft Entra ID 保護 でリスク検出をシミュレートする
https://learn.microsoft.com/ja-jp/entra/id-protection/howto-identity-protection-simulate-risk?wt.mc_id=MVP_407731
以下の Microsoft Support Blog では、Tor ブラウザを使ってリスクを発生させて、確認をするための手順が説明されています。
Support Blog：Entra ID 初学者向けシリーズ第 2 弾 - ID Protection 入門 - その 2: リスクの検出/確認/対応（リスクの 検出/確認/対応 を実際に試してみましょう）
https://jpazureid.github.io/blog/azure-active-directory/starter-series-id-protection-2/#リスクの-検出-確認-対応-を実際に試してみましょう
まとめ
Microsoft Entra ID 保護は、ユーザーやサインインのリスクを Microsoft が自動的に分析し、侵害の可能性があるアカウントや不審なサインインを検出できる機能です。
Microsoft Entra ID P2 または Microsoft Entra Suite を利用することで、ID Protection の詳細なリスクレポートを確認し、検出されたリスクに対して管理者が手動で対応できるようになります。
さらに、条件付きアクセスと組み合わせることで、リスク検出時に MFA の要求、パスワード変更、アクセスのブロックといった自動対処を行えるようになります。これにより、管理者が都度対応するのではなく、リスクに応じた制御を段階的に自動化できます。
また、より実運用に近い形で ID 保護を活用するためには、以下のポイントを事前に整理しておくことを推奨します。
- Microsoft Entra ID P2 相当のライセンスを準備する
- MFA を利用できる状態にする
- 条件付きアクセスを構成する
- 緊急アクセス (Break glass) アカウントを準備する
- Microsoft Entra PIM を利用して特権管理を行う
- 必要に応じて Microsoft Defender 製品由来のシグナルも活用する
- 影響分析を行う場合は、サインインログを Log Analytics に保存する
- レポート専用モードで十分に検証してから有効化する
特に「ユーザーリスク」と「サインインリスク」の違いを理解しておくことが重要です。
- ユーザーリスク：アカウント自体が侵害されている可能性を評価する
- サインインリスク：今回の認証が不正である可能性を評価する
まずは既存のリスクレポートやサインイン状況を確認し、小規模なユーザーを対象にレポート専用モードから導入を開始することで、安全に Microsoft Entra ID 保護を展開できます。