Microsoft Entra の「Help dynamically mitigate risks with Adaptive Protection」は、内部不正や情報漏えいリスクを検知したユーザーに対して、Microsoft Purview と Microsoft Entra Conditional Access の制御を動的に適用するための実装ガイドです。結論から言うと、今回の確認ポイントは「Adaptive Protection をオンにするだけ」ではなく、Insider Risk Management のリスク判定、DLP の制御、データ保持、Conditional Access のブロックや追加条件を、誤検知と業務影響を抑えながら設計することです。公式ドキュメントは 2026年6月26日に更新されており、グローバル環境での展開前に、ライセンス、対応リージョン、ロール、既存ポリシー、レポート専用モードでの検証を確認しておく必要があります。(Microsoft Learn)
Microsoft Entra 管理者が最初に押さえるべき更新ポイント
Adaptive Protection は、Microsoft Entra 単体のアクセス制御機能というより、Microsoft Purview Insider Risk Management を起点に、Microsoft Purview DLP、Microsoft Purview Data Lifecycle Management、Microsoft Entra Conditional Access を連携させる仕組みです。Purview 側でユーザーの内部リスクレベルを判定し、そのリスクレベルに応じて DLP や条件付きアクセスの制御を変える、という流れで理解すると分かりやすくなります。(Microsoft Learn)
特に Microsoft Entra 側の実務上のポイントは、Conditional Access で「Insider risk」条件を利用できることです。これにより、リスクが高いユーザーだけを対象に、アプリへのアクセスブロック、追加の認証要求、利用規約への同意要求などを適用できます。通常の全社一律ブロックではなく、ユーザーのリスク状態に応じて制御を変えられる点が大きな特徴です。(Microsoft Learn)
| 確認項目 | 内容 | 管理者が取るべき対応 |
|---|---|---|
| 対象機能 | Purview Insider Risk Management、DLP、Data Lifecycle Management、Entra Conditional Access の連携 | Entra 管理者だけでなく、コンプライアンス管理者と共同で設計する |
| リスクレベル | Elevated、Moderate、Minor の3段階 | いきなり全ユーザーに強い制御をかけず、段階別に制御を分ける |
| DLP 制御 | リスクレベルに応じてブロック、監査、警告などを適用 | まずテストモードやポリシーヒントで影響を確認する |
| Conditional Access | Insider risk 条件を使ってアクセス制御を適用 | 緊急アクセスアカウントやサービスアカウントの除外を必ず確認する |
| データ保持 | Elevated risk のユーザーが削除した SharePoint、OneDrive、Exchange Online コンテンツを保持 | 監査・調査目的で必要か、ストレージ影響も含めて確認する |
| 移行期限 | Adaptive Protection 固有の移行期限は公式情報上、明示されていない | 関連する Entra ID Protection のレガシーリスクポリシーは別途確認する |
Adaptive Protection で何ができるのか
Adaptive Protection の目的は、すべてのユーザーに同じ厳しい制限をかけることではありません。Microsoft Purview Insider Risk Management がユーザー行動やコンテンツに関するシグナルを分析し、リスクが高いと判断されたユーザーにだけ、必要な保護制御を強く適用します。
公式ドキュメントでは、Adaptive Protection が次の3つの考え方でリスク低減を支援すると説明されています。
- コンテンツとユーザー活動の分析による、文脈を踏まえた検知
- 高リスクユーザーに対する動的な制御
- 管理者の手作業を減らす自動的なリスク緩和
たとえば、通常のユーザーにはファイル共有を許可しつつ、情報持ち出しの兆候があるユーザーだけ外部共有をブロックする、といった運用が可能になります。これにより、セキュリティを高めながら、低リスクユーザーの業務を不必要に止めにくくなります。(Microsoft Learn)
リスクレベルは Elevated、Moderate、Minor の3段階で考える
Adaptive Protection では、ユーザーに割り当てられる内部リスクレベルが制御の起点になります。主なリスクレベルは、Elevated、Moderate、Minor の3段階です。公式ドキュメントでは、既定の定義を使うことも、組織の要件に合わせて条件をカスタマイズすることもできるとされています。(Microsoft Learn)
| リスクレベル | 典型的な考え方 | 制御例 |
|---|---|---|
| Elevated | 情報持ち出しや高重大度アラートなど、強いリスクがある状態 | 外部共有ブロック、アプリへのアクセスブロック、削除データの保持 |
| Moderate | 複数のリスク活動や中程度のアラートがある状態 | 警告、監査、特定アプリへの制限 |
| Minor | 低重大度のアラートや初期的なリスク兆候がある状態 | ポリシーヒント、教育的な通知、監査 |
注意したいのは、リスクレベルは単純な操作回数だけで決まるわけではない点です。たとえば、SharePoint から10ファイルを1日にダウンロードした場合でも、それは複数イベントを含む1つのインサイトとして扱われる例が示されています。しきい値設計では「ファイル数」だけでなく、インサイト、重大度、検知期間の考え方を理解しておく必要があります。(Microsoft Learn)
Microsoft Entra Conditional Access への影響
Microsoft Entra 管理者にとって最も重要なのは、Conditional Access で Insider risk 条件を使える点です。Entra の条件付きアクセスは、ユーザー、デバイス、場所、リスクなどのシグナルを組み合わせてアクセス判断を行う仕組みですが、Adaptive Protection と組み合わせることで、Purview 側の内部リスクシグナルをアクセス制御に反映できます。(Microsoft Learn)
実務では、次のような使い分けが考えられます。
| シナリオ | Conditional Access の制御例 | 判断基準 |
|---|---|---|
| Minor risk | 利用規約への同意、追加通知 | 業務を止めずに注意喚起したい場合 |
| Moderate risk | 特定アプリへのアクセス制限、強い認証要求 | 機密データへのアクセスを絞りたい場合 |
| Elevated risk | 重要アプリや全リソースへのアクセスブロック | 明確な情報持ち出しリスクがあり、即時抑止が必要な場合 |
ただし、Elevated risk を条件に全リソースをブロックするポリシーは強力です。公式の手順でも、ポリシー作成時は Report-only で有効化し、影響を確認してから On に切り替える流れが示されています。緊急アクセス用の break-glass アカウント、サービスアカウント、サービスプリンシパルなどを適切に除外しないと、管理者自身が復旧できなくなるリスクがあります。(Microsoft Learn)
DLP と Data Lifecycle Management への影響
Adaptive Protection は Conditional Access だけでなく、Microsoft Purview DLP とも連携します。DLP ポリシーでは、「User’s insider risk level for Adaptive Protection is」という条件を使い、Elevated、Moderate、Minor のリスクレベルに応じて制御を変えられます。公式情報では、Adaptive Protection の DLP 対応場所は Exchange、Microsoft Teams、デバイスとされています。(Microsoft Learn)
DLP のクイックセットアップでは、Teams と Exchange Online 向けのポリシー、Endpoint DLP 向けのポリシーが作成されます。たとえば Elevated risk のユーザーにはブロック、Moderate や Minor のユーザーには監査といった形で、リスク段階に応じたルールを構成できます。クイックセットアップで作成される DLP ポリシーはシミュレーションモードから始まるため、本番影響を確認してから有効化する運用が現実的です。(Microsoft Learn)
Data Lifecycle Management では、Elevated risk に割り当てられたユーザーが SharePoint、OneDrive、Exchange Online のコンテンツを削除した場合、そのコンテンツを120日間保持する動作が説明されています。これは情報漏えい調査や証跡保全に役立ちますが、保持対象やストレージ影響をコンプライアンス部門と事前に確認しておくべきです。(Microsoft Learn)
クイックセットアップとカスタムセットアップの選び方
Adaptive Protection には、Quick setup と Custom setup の2つの導入方法があります。どちらを選ぶかは、既存の Insider Risk Management、DLP、Conditional Access の運用状況で判断します。(Microsoft Learn)
| 導入方法 | 向いている組織 | 注意点 |
|---|---|---|
| Quick setup | まだ関連ポリシーが少なく、標準構成で試したい組織 | 自動作成されるポリシーの対象範囲と名前を必ず確認する |
| Custom setup | 既に DLP や Conditional Access を運用している組織 | 既存ポリシーとの重複、競合、対象ユーザーの差分を確認する |
Quick setup では、Insider Risk Management ポリシー、Conditional Access ポリシー、Data Lifecycle Management ポリシー、DLP ポリシーが自動的に構成されます。公式情報では、Quick setup の開始後、分析や関連ポリシー、リスクレベルと制御の適用が完了するまで最大72時間かかる可能性があるとされています。途中で無効化するとポリシーエラーにつながる可能性があるため、検証テナントや限定範囲で始めるのが安全です。(Microsoft Learn)
一方、Custom setup では、既存または新規の Insider Risk Management ポリシーを選び、リスクレベル、DLP、Conditional Access を個別に設計します。既に本番の Conditional Access ポリシーが多い環境では、Custom setup を選び、Report-only と限定グループで段階的に確認する方が管理しやすいでしょう。(Microsoft Learn)
設定変更で確認すべき手順
Adaptive Protection を展開する前に、次の順序で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 実務上のポイント |
|---|---|---|
| 1 | ライセンスと対応クラウドを確認 | 対象テナント、対象リージョン、必要ライセンスを確認する |
| 2 | 管理ロールを確認 | Purview 管理者、DLP 管理者、Conditional Access 管理者の役割を分ける |
| 3 | Insider Risk Management ポリシーを設計 | 全ユーザー対象か、特定部門から始めるかを決める |
| 4 | リスクレベル条件を調整 | Elevated、Moderate、Minor の判定条件を業務実態に合わせる |
| 5 | DLP ポリシーをテスト | いきなりブロックせず、監査やポリシーヒントで動作確認する |
| 6 | Conditional Access を Report-only で作成 | break-glass アカウントとサービスアカウントを除外する |
| 7 | Adaptive Protection をオンにする | 反映までの時間を見込み、ダッシュボードで確認する |
| 8 | 運用後にしきい値を調整 | 対象者が多すぎる、少なすぎる場合は条件を見直す |
Adaptive Protection を有効化した後、Insider Risk Management のリスクレベルや DLP、Data Lifecycle Management、Conditional Access のアクションが適用されるまで、最大36時間かかる可能性があります。すぐに結果が出ない場合でも、設定ミスと決めつけず、反映時間を考慮して確認しましょう。(Microsoft Learn)
管理者権限とプライバシー面の注意点
Adaptive Protection は、ユーザー行動やリスク判定を扱うため、管理者ロールの設計が重要です。公式ドキュメントでは、Adaptive Protection の構成には Insider Risk Management または Insider Risk Management Admins、Conditional Access ポリシーの作成には Global Administrator、Conditional Access Administrator、Security Administrator などのロールが示されています。DLP ポリシーには Compliance Administrator、Compliance Data Administrator、DLP Compliance Management などが関係します。(Microsoft Learn)
最小権限の原則を守るなら、全員に Global Administrator を付与するのではなく、作業単位に応じてロールを分けるべきです。特にグローバル企業では、地域ごとのコンプライアンス担当、ID 管理担当、セキュリティ運用担当が分かれていることが多いため、誰がリスクレベルを見られるのか、誰がアクセス制御を変更できるのかを事前に整理しておく必要があります。
プライバシー面では、Insider Risk Management でユーザー名の匿名化を有効にしていても、Conditional Access や DLP の関連画面では実ユーザー名が表示される場合があります。調査やアクセス制御の整合性を保つために必要な仕様ですが、閲覧権限を広げすぎると内部統制上の問題になり得ます。(Microsoft Learn)
移行期限はあるのか
今回の「Help dynamically mitigate risks with Adaptive Protection」更新情報を見る限り、Adaptive Protection 自体に対して「いつまでに移行必須」という期限は明示されていません。したがって、既存環境ですぐに強制移行が必要というより、内部リスクに応じた動的制御を導入するかどうかを、業務影響とセキュリティ要件から判断する位置づけです。(Microsoft Learn)
ただし、Microsoft Entra ID Protection のレガシーリスクポリシーについては別件として注意が必要です。Microsoft Learn では、レガシーの ID Protection リスクポリシーが 2026年10月1日に廃止されると説明されており、該当する場合は Conditional Access への移行計画が必要です。Adaptive Protection の話と混同しやすい部分なので、Entra 管理者は「内部リスク連携」と「ID Protection のレガシーリスクポリシー移行」を分けて棚卸しするとよいでしょう。(Microsoft Learn)
失敗しやすいポイント
Adaptive Protection の導入で最も多い失敗は、リスク判定と制御を一気に本番適用してしまうことです。特に Elevated risk に対して強い Conditional Access ブロックを設定する場合、誤検知や想定外の対象ユーザーによって、業務アプリにアクセスできない利用者が発生する可能性があります。
避けるべき設定例は、次のようなものです。
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| Elevated risk で全アプリを即時ブロック | 重要業務が止まる可能性がある | Report-only で影響を確認してから有効化する |
| break-glass アカウントを除外しない | 管理者が復旧できなくなる | 緊急アクセスアカウントを必ず除外する |
| DLP と Conditional Access を別々に設計する | 片方は許可、片方はブロックのような矛盾が起きる | リスクレベルごとの制御方針を1枚に整理する |
| リスクレベルのしきい値を既定値のまま放置 | 対象者が多すぎる、または少なすぎる | 運用後にダッシュボードを見て調整する |
| 匿名化の仕様を誤解する | 調査画面や DLP 側で実名が見えることに気づかない | 閲覧ロールと監査ログを確認する |
DLP 側でも注意が必要です。Adaptive Protection の DLP ポリシーは、現在サポートされる場所が Exchange、Teams、Devices に限られると説明されています。SharePoint や OneDrive の削除データ保持は Data Lifecycle Management 側の話であり、DLP の適用範囲と混同しないようにしましょう。(Microsoft Learn)
導入前のチェックリスト
本番展開前には、少なくとも次の項目を確認してください。
- 対象テナントが Insider Risk Management の対応リージョン・クラウドに含まれているか
- 必要な Microsoft Purview、Microsoft Entra、DLP 関連ライセンスを満たしているか
- Insider Risk Management、DLP、Conditional Access の管理ロールが適切に分離されているか
- Quick setup で自動作成されるポリシー名、対象ユーザー、対象アプリを確認したか
- Conditional Access の Report-only 結果を確認したか
- break-glass アカウント、サービスアカウント、サービスプリンシパルの除外方針を決めたか
- Elevated、Moderate、Minor の各リスクレベルに対する制御方針を文書化したか
- DLP の対象場所と、Data Lifecycle Management の保持対象を混同していないか
- ユーザー名の匿名化と実名表示の範囲を確認したか
- 反映時間として最大36時間または Quick setup の最大72時間を考慮しているか
なお、Insider Risk Management は商用クラウドでは利用可能とされる一方、公式ドキュメントでは US Government cloud programs では現時点で利用できないと説明されています。グローバル企業や多国籍テナントでは、展開地域ごとの利用可否を事前に確認しておく必要があります。(Microsoft Learn)
無効化する場合の影響
Adaptive Protection を一時的に無効化することはできます。ただし、無効化すると新たな内部リスクレベルの割り当てが停止し、DLP、Data Lifecycle Management、Conditional Access への共有も停止します。既存ユーザーのリスクレベルはリセットされますが、Insider Risk Management、DLP、Data Lifecycle Management、Conditional Access のポリシー自体は自動削除されません。(Microsoft Learn)
また、無効化後にリスクレベルの割り当て停止とリセットが完了するまで、最大6時間かかる可能性があります。検証目的でオン・オフを繰り返すと、ポリシー状態の確認が複雑になるため、本番環境では変更タイミングと確認手順を決めてから操作するのが安全です。(Microsoft Learn)
まず何から始めるべきか
Microsoft Entra の管理者が最初に行うべきことは、Conditional Access に Insider risk 条件を設定することではなく、既存のリスク対応ルールを棚卸しすることです。特に、既に DLP、Insider Risk Management、ID Protection、Conditional Access を運用している環境では、Adaptive Protection を追加することで制御が重複する可能性があります。
実務では、次の順序で進めると安全です。
まず、Elevated risk、Moderate risk、Minor risk のそれぞれに対して、どの業務影響まで許容できるかを決めます。次に、対象ユーザーを限定し、DLP と Conditional Access をテストモードまたは Report-only で動かします。そのうえで、ダッシュボードに表示される対象ユーザー数、DLP アラート、Conditional Access の影響を確認し、しきい値を調整します。
Adaptive Protection は、内部リスクに対する「動的な防御」を実現できる強力な仕組みです。一方で、設計を誤ると業務停止や過剰な監視につながります。2026年6月26日更新の公式情報を確認する際は、機能の有効化だけでなく、リスクレベルの定義、DLP の対象範囲、Conditional Access の除外設計、移行期限の有無、無効化時の影響まで含めて確認することが重要です。
コメント