Microsoft Defender for EndpointをIntuneで構成する場合、最初に押さえるべき結論は「DefenderとIntuneを接続するだけでは不十分」という点です。実際の運用では、デバイスのオンボーディング、プラットフォーム別の統合設定、リスクレベルを使った準拠ポリシー、条件付きアクセスまでを一連の流れで確認する必要があります。
Microsoft Learnの公式ドキュメント「Configure Microsoft Defender for Endpoint with Intune and onboard devices」は、IntuneとMicrosoft Defender for Endpointを連携し、Windows、macOS、Android、iOS/iPadOSをDefender for Endpointへオンボードし、デバイスリスクに応じて企業リソースへのアクセスを制御する手順を整理したものです。Microsoft Learn上の最終更新日は2026年5月26日と表示されています。(Microsoft Learn)
この記事では、Microsoft DefenderとIntuneを利用している管理者向けに、今回の公式情報で確認すべき変更点、影響範囲、設定・移行・展開時の注意点を実務目線で整理します。
Microsoft DefenderとIntune連携で何ができるのか
Microsoft Defender for EndpointとMicrosoft Intuneを連携すると、Defenderが検出したデバイスリスクをIntuneの準拠性評価に反映できます。たとえば、マルウェア感染や高リスク状態が検出されたデバイスをIntune側で「非準拠」と判定し、Microsoft Entra IDの条件付きアクセスでSharePoint OnlineやExchange Onlineなどへのアクセスをブロックできます。(Microsoft Learn)
単にエンドポイント保護を導入するだけでなく、リスクのある端末を業務アプリから切り離すところまで自動化できるのが、この連携の重要なポイントです。
実務上は、次の4つをセットで考える必要があります。
| 項目 | 役割 | 確認すべきポイント |
|---|---|---|
| Defender for Endpointとの接続 | IntuneとDefenderのサービス間連携 | 接続状態がEnabledになっているか |
| デバイスのオンボーディング | 端末をDefender管理下に置く | Windows、macOS、Android、iOS/iPadOSで手順が異なる |
| 準拠ポリシー | デバイスリスクを非準拠判定に使う | 許容するリスクレベルを適切に設定する |
| 条件付きアクセス | 非準拠端末のアクセスを制御 | いきなり本番適用せずReport-onlyで検証する |
この構成では、Defenderが「危険な端末を見つける」、Intuneが「端末の準拠状態を判定する」、Entra IDが「アクセスを許可またはブロックする」という役割分担になります。
今回の公式情報で確認すべき主な変更点
今回の公式情報は、単一の新機能だけを告知する内容ではなく、Microsoft Defender for EndpointとIntune連携の構成手順を、より実運用に近い形で整理した更新と見るべきです。特に管理者が確認すべきポイントは次の通りです。
| 確認ポイント | 内容 | 影響を受けやすい環境 |
|---|---|---|
| Windowsのオンボーディング手順 | 事前構成済みポリシーによる一括展開と、手動作成による詳細制御の選択肢が整理されている | Windows端末を多数管理する組織 |
| AndroidのMTDロール | Android Enterpriseの会社所有端末でDefender for Endpointの権限強化やセットアップ時の自動起動が扱われている | COBO、COPE構成のAndroid端末 |
| モバイルアプリ保護 | 登録済み端末だけでなく、未登録端末にもアプリ保護ポリシーでリスク評価を適用できる | BYOD、個人所有端末を許可している組織 |
| クラシック条件付きアクセス | 旧来のクラシックCAポリシーは新規作成されず、既存の古いポリシーは確認対象 | 古くからDefender連携を使っているテナント |
| Windows 10の扱い | Intuneで利用可能でも、サポート終了後は機能保証に注意が必要 | Windows 10端末が残る組織 |
GitHub上のMicrosoftDocs履歴では、2026年5月15日に「add defenders extra toggle」という更新があり、Android EnterpriseのCOBO/COPEデバイスで、Defender for Endpointアプリをデバイスセットアップ中に自動起動するトグルに関する説明が追加されています。(GitHub)
この変更は、Android端末の初期セットアップ時にDefenderアプリをユーザーが手動で開かないまま保護が不完全になる、といった展開上の抜け漏れを減らすうえで重要です。
影響範囲はWindowsだけではない
Microsoft Defender for Endpointという名称からWindows中心の機能に見えますが、今回のIntune連携ではWindows、macOS、Android、iOS/iPadOSが対象になります。公式ドキュメントでも、Windowsは自動オンボーディングパッケージが推奨され、macOS、Android、iOS/iPadOSは手動構成が必要とされています。(Microsoft Learn)
| プラットフォーム | オンボーディングの考え方 | 管理者が注意すべき点 |
|---|---|---|
| Windows | IntuneがDefender for Endpointからオンボーディング構成を自動取得 | 事前構成済みポリシーを使うか、対象グループを絞るかを決める |
| macOS | Defenderアプリ展開とIntuneアプリ構成ポリシーが必要 | Windowsと同じ感覚で自動展開できると思い込まない |
| Android | Defenderアプリ、Web保護、VPNベースのスキャン、MTDロールを検討 | Android Enterpriseの管理方式によって使える機能が変わる |
| iOS/iPadOS | Defenderアプリ展開、監視対象デバイスの検出、アプリ脆弱性評価を検討 | 個人所有端末で共有するアプリ情報の範囲に注意する |
特に混乱しやすいのは、Intuneに登録されているかどうかと、Defenderでリスク評価できるかどうかを分けて考える点です。
たとえば、会社貸与のWindows PCはIntune登録済みでDefenderオンボーディング済みという構成が一般的です。一方、個人所有のスマートフォンでは、デバイス全体をMDM管理せず、アプリ保護ポリシーでMicrosoft 365アプリの利用だけを制御する構成もあります。公式情報でも、AndroidとiOS/iPadOSのアプリ保護ポリシーは登録済み端末と未登録端末の両方で機能するとされています。(Microsoft Learn)
管理者が最初に確認すべき前提条件
設定作業に入る前に、権限とライセンスの確認が必要です。公式の前提条件では、Intune側のMobile Threat Defense、Endpoint Detection and Response、Device compliance policiesに関する権限が必要で、組み込みロールではEndpoint Security Managerが必要権限を含む最小権限の組み込みロールとして示されています。条件付きアクセスの管理には、別途Microsoft Entra ID側の権限が必要です。(Microsoft Learn)
確認すべき権限
| 作業 | 必要な主な権限 |
|---|---|
| IntuneとDefenderの接続 | Mobile Threat DefenseのRead、Modify |
| EDRオンボーディングポリシー作成 | Endpoint Detection and ResponseのAssign、Create、Read、Updateなど |
| 準拠ポリシー作成 | Device compliance policiesのAssign、Create、Read、Updateなど |
| 条件付きアクセス作成 | Microsoft Entra IDのConditional Access Administrator相当 |
よくある失敗は、Intune管理者権限だけで全作業ができると思い込むことです。条件付きアクセスはMicrosoft Entra IDの機能であり、Intune管理センターから入口が見えても、実際のポリシー管理にはEntra ID側の権限が必要です。
IntuneとDefender for Endpointを接続する手順
まずはテナント単位でIntuneとMicrosoft Defender for Endpointを接続します。公式手順では、Intune管理センターの「Endpoint security > Defender for Endpoint」で接続状態を確認し、未接続の場合はMicrosoft Defenderポータルの「System > Settings > Endpoints > General > Advanced features」からIntune connectionをオンにします。接続状態の反映には最大15分かかる場合があります。(Microsoft Learn)
実務では、次の流れで確認すると安全です。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Intune管理センターで接続状態を確認 | Connection statusがEnabledかUnavailableか |
| 2 | Defenderポータルを開く | 適切なテナントで操作しているか |
| 3 | Intune connectionをOnにする | 保存後に設定が反映されているか |
| 4 | Intune側に戻って確認 | 最大15分程度待ってから再確認 |
| 5 | 対象プラットフォームの連携設定へ進む | Windows、Android、iOS/iPadOSを必要に応じて有効化 |
ここで注意したいのは、接続をオンにしただけでは各プラットフォームの評価やオンボーディングが完了しないことです。接続はあくまで入口であり、その後にコンプライアンスポリシー評価、アプリ保護ポリシー評価、デバイスオンボーディングを構成します。
統合設定では対象プラットフォームを明確にする
Intune管理センターの「Endpoint security > Defender for Endpoint」では、Defender for Endpointを使った準拠性評価やアプリ保護ポリシー評価を有効化します。
公式情報では、準拠ポリシー評価についてAndroid、iOS/iPadOS、WindowsをDefender for Endpointへ接続する設定が示されています。また、アプリ保護ポリシー評価ではAndroidとiOS/iPadOSを有効化します。(Microsoft Learn)
設定時の判断基準
| 設定 | 有効化すべきケース | 注意点 |
|---|---|---|
| Windowsの準拠ポリシー評価 | Windows端末のリスクを準拠状態に反映したい | オンボーディングポリシー展開とセットで考える |
| Androidの準拠ポリシー評価 | Android Enterprise端末をMDM管理している | Androidデバイス管理方式を確認する |
| iOS/iPadOSの準拠ポリシー評価 | iPhone、iPadをIntune登録している | 追加のアプリ脆弱性評価設定も検討する |
| Android/iOSのアプリ保護評価 | BYODや未登録端末の業務アプリ利用を制御したい | デバイス全体ではなくアプリ単位の制御になる |
全プラットフォームを無条件にオンにするのではなく、自社の端末管理方式に合わせて有効化することが重要です。たとえば、BYODスマートフォンをMDM登録させない方針なら、デバイス準拠ポリシーよりもアプリ保護ポリシーのリスク評価が中心になります。
Windowsデバイスのオンボーディングは「早く広く」か「段階的に細かく」かで選ぶ
Windowsデバイスでは、IntuneとDefender for Endpointの接続後、Intuneがオンボーディング構成パッケージを自動的に受け取ります。これにより、Defender for Endpointサービスとの通信、ファイルスキャンと脅威検出、準拠ポリシー向けのリスクレベル報告が可能になります。(Microsoft Learn)
展開方法は大きく2つあります。
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| 事前構成済みポリシー | すべてのWindows端末へ素早く展開したい | All Devicesへの展開になるため、検証環境では慎重に使う |
| カスタムポリシー | 部門、端末種別、検証グループごとに段階展開したい | グループ設計とスコープタグの整理が必要 |
事前構成済みポリシーは、短時間で全社展開したい場合に便利です。一方、すでにEDRポリシーやセキュリティベースラインを複数運用している環境では、設定競合を避けるためカスタムポリシーで対象を絞るほうが安全です。
Windows展開で失敗しやすいポイント
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 一部端末がオンボーディングされない | ユーザーグループに割り当て、サインイン前の端末に適用されていない | 即時展開したい場合はデバイスグループを優先する |
| 同じ設定で競合が起きる | 複数のEDRポリシーや構成プロファイルが同じ項目を管理している | 既存ポリシーを棚卸ししてから展開する |
| Defenderポータルに端末が出ない | 反映待ち、接続不備、ポリシー未適用 | 15〜30分後にDevice inventoryとIntuneのDevice statusを確認する |
| 検証なしで全社展開してしまう | 事前構成済みポリシーを本番全体に適用 | パイロットグループで確認してから対象を広げる |
公式手順でも、Windowsデバイスはオンボーディング後15〜30分程度でDefenderポータルのDevice inventoryに表示されることが示されています。(Microsoft Learn)
macOS、Android、iOS/iPadOSは手動構成を前提にする
Windowsと違い、macOS、Android、iOS/iPadOSではIntuneが自動オンボーディングパッケージをそのまま用意するわけではありません。公式情報でも、macOS、Android、iOS/iPadOSは手動構成が必要とされています。(Microsoft Learn)
macOS
macOSでは、Defender for Endpointアプリの展開、Intuneアプリ構成ポリシー、Defenderポータルでの登録確認を行います。Windowsと同じEDRポリシー展開だけで完了すると考えると、オンボーディング漏れが起きやすくなります。
特に、macOSではユーザー承認、拡張機能、ネットワーク保護関連の許可など、OS側のプライバシー制御が展開品質に影響します。実運用では、アプリ配布だけでなく、必要な構成プロファイルをまとめて検証してください。
Android
Androidでは、Microsoft Defender for Endpointアプリの展開、Web保護、VPNベースのスキャン、プライバシー設定、脅威検出設定などを確認します。公式情報では、Android Enterpriseの会社所有フルマネージド端末や会社所有ワークプロファイル端末で、Mobile Threat DefenseロールによりDefenderへ強化された権限を付与できることも示されています。(Microsoft Learn)
特に注目すべきは、Android Enterprise COBO/COPEデバイスで、セットアップ中にDefender for Endpointを自動起動できるトグルです。この設定により、ユーザーがアプリを開き忘れて初期構成が完了しないリスクを下げられます。ただし、この自動起動トグルには、MTDロール権限の付与が前提になります。(Microsoft Learn)
iOS/iPadOS
iOS/iPadOSでは、Defender for Endpointアプリの展開に加え、監視対象デバイスの検出設定が重要です。公式手順では、アプリ構成ポリシーでissupervisedキーを使い、値に{{issupervised}}を設定する例が示されています。(Microsoft Learn)
また、iOSではアプリの脆弱性評価に関連して、App Syncや個人所有iOS/iPadOS端末で送信するアプリインベントリ情報の範囲を制御できます。個人所有端末では、セキュリティ強化とプライバシー配慮のバランスを事前に決めておくべきです。
Android device administrator利用環境は移行計画が必要
公式情報では、Google Mobile Servicesにアクセスできる端末におけるAndroid device administrator管理は非推奨で、利用できなくなっていると説明されています。現在device administrator管理を使っている場合は、別のAndroid管理方式への移行が推奨されています。(Microsoft Learn)
これは、古いAndroid管理方式を残している組織にとって大きな確認ポイントです。特に、次のような環境では早めに棚卸ししてください。
- Android device administratorで業務端末を管理している
- Android Enterpriseへの移行が完了していない
- 個人所有端末と会社所有端末の管理方式が混在している
- Defender for Endpointのモバイル展開状況が端末ごとに不明
移行時は、単に管理方式を変更するだけでなく、Defenderアプリの再展開、アプリ構成ポリシー、準拠ポリシー、条件付きアクセスの対象グループも見直す必要があります。
準拠ポリシーではリスクレベルのしきい値を決める
Defender for Endpoint連携の中心になるのが、デバイスリスクを使った準拠ポリシーです。公式情報では、Android、iOS/iPadOS、Windowsデバイスが対象で、設定したリスクしきい値を超えたデバイスは自動的に非準拠として扱われます。(Microsoft Learn)
リスクレベルは、次のように考えると判断しやすくなります。
| 設定値 | 許容する状態 | 向いている用途 | 注意点 |
|---|---|---|---|
| Clear | 脅威なしのみ許可 | 特権管理者端末、金融・医療など高セキュリティ領域 | 誤検知や軽微な検出でも業務影響が出やすい |
| Low | 低リスクまで許可 | 多くの一般業務端末 | セキュリティと利便性のバランスを取りやすい |
| Medium | 中リスクまで許可 | 検証段階、制限が緩い部門 | 中程度のリスク端末が業務アプリへアクセスできる |
| High | 高リスクまで許可 | レポート目的、段階導入の初期 | 実質的なブロック効果は弱い |
公式情報でも、多くの組織では「Low」がセキュリティと生産性のバランスを取りやすい推奨設定として示されています。(Microsoft Learn)
ただし、すべての端末に同じしきい値を適用するのが正解とは限りません。たとえば、経営層や管理者端末、機密情報を扱う部門はClearまたはLow、一般部門はLow、初期導入中の一部端末はMediumで監視から始める、といった段階設計が現実的です。
アプリ保護ポリシーはBYOD対策で重要
スマートフォンやタブレットでは、端末をIntuneに完全登録しない運用もあります。その場合でも、Intuneのアプリ保護ポリシーを使えば、Microsoft Defender for Endpointの脅威評価に基づき、モバイルアプリの起動条件を制御できます。
公式情報では、アプリ保護ポリシーはiOS/iPadOSとAndroidが対象で、登録済み・未登録を問わず、保護対象アプリに対して脅威レベルに応じたブロックやデータワイプを構成できると説明されています。(Microsoft Learn)
アプリ保護で検討すべき設定
| 設定 | 選択肢 | 実務での考え方 |
|---|---|---|
| Max allowed device threat level | Secured、Low、Medium、High | 初期はLowまたはMediumで影響を確認し、必要に応じて厳格化する |
| しきい値超過時のアクション | Block access、Wipe data | まずBlock access、重大リスクや退職・紛失対策ではWipe dataも検討 |
| 対象アプリ | Outlook、Teams、OneDriveなど | 業務データを扱うアプリを漏れなく含める |
| 対象ユーザー | 部門、雇用形態、BYOD利用者 | 端末ではなくユーザー割り当てになる点に注意 |
アプリ保護ポリシーは「会社データをアプリ単位で守る」仕組みです。デバイス全体の制御と混同しないようにしてください。BYODでは、端末全体をロックするよりも、業務アプリ内のデータを守る設計がユーザー受容性の面でも現実的です。
条件付きアクセスはReport-onlyから始める
準拠ポリシーでデバイスを非準拠にするだけでは、アクセス制御は完結しません。Microsoft Entra IDの条件付きアクセスで、「準拠としてマークされたデバイスを要求する」設定を行うことで、非準拠端末のSharePoint OnlineやExchange Onlineなどへのアクセスをブロックできます。
公式情報では、すべてのクラウドアプリに対してデバイス準拠を要求するポリシーは、対象ユーザーに即時影響するため、最初はReport-onlyモードで作成することが強く推奨されています。Report-onlyでは、実際にはブロックせず、ポリシーが有効だった場合の結果をサインインログで確認できます。(Microsoft Learn)
本番適用前のチェックリスト
| チェック項目 | 理由 |
|---|---|
| 緊急用のbreak-glass管理者アカウントを除外しているか | 誤設定による管理者ロックアウトを防ぐ |
| Directory Synchronization Accountsを除外しているか | 同期処理への影響を避ける |
| 最初からAll cloud appsを対象にしていないか | 影響範囲が大きすぎる可能性がある |
| Report-onlyで24時間以上ログを確認したか | 業務影響を事前に把握する |
| 非準拠端末で実際にアクセス制御をテストしたか | 想定通りブロックされるか確認する |
| 除外グループが増えすぎていないか | セキュリティホール化を防ぐ |
条件付きアクセスで最も怖い失敗は、正しいセキュリティ設定をしたつもりで、正規ユーザーや管理者を業務アプリから締め出してしまうことです。特に全社展開では、Report-only、限定グループ、本番適用の順に進めるのが安全です。
クラシック条件付きアクセスが残っていないか確認する
古くからIntuneとDefender for Endpointを連携しているテナントでは、クラシック条件付きアクセスの残存確認も必要です。公式情報では、2023年8月以降、IntuneはDefender for Endpoint向けのクラシック条件付きアクセスポリシーを作成しなくなっており、過去の統合で作成されたレガシーポリシーは削除可能とされています。(Microsoft Learn)
確認場所は、AzureポータルまたはMicrosoft Entra管理センター側の条件付きアクセス関連画面です。古いポリシーが残っている場合、現在の条件付きアクセスと重複して意図しないブロックや例外が発生する可能性があります。
移行時は、次の順で確認すると安全です。
| 順番 | 作業 |
|---|---|
| 1 | 既存のクラシック条件付きアクセスポリシーを一覧化する |
| 2 | 現在のEntra ID条件付きアクセスポリシーと重複していないか確認する |
| 3 | Defender連携に由来する古いポリシーか判断する |
| 4 | 削除前に影響範囲を記録する |
| 5 | 必要に応じて変更管理プロセスに乗せて削除する |
「公式が削除可能と言っているから即削除」ではなく、現在の業務アクセス制御に使われていないことを確認してから対応してください。
Windows 10端末が残る環境での注意点
公式ドキュメントでは、Windows 10はIntuneで許可されたバージョンとして引き続き登録や一部機能の利用が可能である一方、2025年10月14日にサポート終了しており、機能は保証されず変動する可能性があると説明されています。(Microsoft Learn)
Microsoftのライフサイクル情報でも、Windows 10 バージョン22H2などは2025年10月14日にサポート終了となり、その後はセキュリティ更新プログラムを受け取らないと案内されています。(Microsoft Learn)
つまり、IntuneやDefenderの管理画面上でWindows 10端末が見えていても、長期的なセキュリティ運用としてはWindows 11移行、端末交換、または組織向けの延長セキュリティ更新プログラムの検討が必要です。
Windows 10が残っている場合の判断基準
| 状況 | 推奨対応 |
|---|---|
| 業務上すぐに移行できる | Windows 11対応端末へ移行する |
| 専用アプリの都合で移行できない | 例外端末として台帳管理し、アクセス範囲を制限する |
| インターネット接続やMicrosoft 365利用がある | Defenderと条件付きアクセスでリスク制御を強化する |
| 重要情報を扱う | Windows 10継続利用のリスクを経営・セキュリティ部門に明示する |
サポート終了端末を「Intuneで管理できているから安全」と判断するのは危険です。管理可能であることと、OSとして安全に保守されることは別の問題です。
Security Management for Microsoft Defender for Endpointも確認する
公式情報では、Intuneに登録されていないデバイスに対しても、Defender for Endpointのセキュリティ構成をIntuneのエンドポイントセキュリティポリシーで管理できる「Security Management for Microsoft Defender for Endpoint」に触れています。この機能は、Intune未登録デバイスやLinuxを含む環境で、Defender設定を管理したい場合に関係します。(Microsoft Learn)
通常のIntune MDM管理とは別の選択肢として、次のような場面で検討できます。
- サーバーや特殊端末をIntune登録できない
- Linux端末にもDefender関連のセキュリティ設定を適用したい
- フルMDM管理ではなく、Defenderのセキュリティ設定だけを集中管理したい
- Microsoft DefenderポータルとIntune管理センターの両方から状態を確認したい
ただし、Intune登録済み端末と未登録端末の管理方式が混在すると、ポリシーの適用経路が分かりにくくなります。運用設計書には、端末種別ごとに「MDM管理」「アプリ保護」「Defenderセキュリティ設定管理」のどれで制御しているかを明記しておくと、障害対応や監査で迷いにくくなります。
管理者・開発者が確認すべき実務チェックリスト
Microsoft Defender for EndpointとIntune連携は、セキュリティ部門だけで完結する設定ではありません。業務アプリへのアクセス、モバイル利用、端末展開、アプリ検証にも影響します。管理者と開発者は、次の観点で確認してください。
| 立場 | 確認すべきこと | 実務上の注意点 |
|---|---|---|
| Intune管理者 | Defender接続、EDRポリシー、準拠ポリシー | 既存ポリシーとの競合を確認する |
| セキュリティ管理者 | リスクレベルのしきい値、検出後の対応フロー | Low、Medium、Highの運用ルールを決める |
| Entra ID管理者 | 条件付きアクセス、除外アカウント | Report-onlyでログ確認してから有効化する |
| モバイル管理者 | Android Enterprise、iOS監視対象、BYOD | 個人所有端末のプライバシー設定を確認する |
| 開発者 | 業務アプリへのアクセス条件 | 非準拠端末からのアクセス失敗をアプリ障害と誤認しない |
| ヘルプデスク | ブロック時の問い合わせ対応 | 「端末リスク」「準拠状態」「条件付きアクセス」の切り分け手順を用意する |
開発者にとっても無関係ではありません。条件付きアクセスにより、アプリやAPIへのアクセスが失敗する場合があります。その際、アプリ側の不具合ではなく、端末の準拠状態やDefenderのリスク判定が原因である可能性があります。社内アプリをMicrosoft Entra ID認証で保護している場合は、検証端末の準拠状態もテスト条件に含めてください。
展開時は段階導入が安全
全社一括展開は短期間で保護範囲を広げられる反面、誤設定時の影響も大きくなります。特に条件付きアクセスと組み合わせる場合は、段階導入が基本です。
推奨する展開ステップ
| フェーズ | 対象 | 実施内容 |
|---|---|---|
| 準備 | 管理者、セキュリティ担当 | 権限、ライセンス、既存ポリシー、対象端末を棚卸し |
| パイロット | IT部門、検証端末 | Defender接続、オンボーディング、準拠ポリシーを確認 |
| 限定展開 | 一部部門 | 条件付きアクセスをReport-onlyで評価 |
| 本番展開 | 全社または主要部門 | 影響の少ないクラウドアプリから段階的に適用 |
| 運用定着 | 全対象端末 | レポート、問い合わせ、例外管理を定期確認 |
展開中は、DefenderポータルのDevice inventory、IntuneのEDR Onboarding Status、デバイス準拠レポート、Microsoft Entra IDのサインインログをセットで確認します。1つの画面だけでは、オンボーディング失敗、準拠性違反、条件付きアクセスによるブロックのどれが原因か判断しにくいためです。
すぐに実施すべき対応ポイント
今回の公式情報を踏まえると、管理者が優先して行うべき対応は次の5つです。
| 優先度 | 対応 | 理由 |
|---|---|---|
| 高 | IntuneとDefender for Endpointの接続状態を確認 | 接続が無効だとリスクベースの準拠評価が機能しない |
| 高 | Windowsオンボーディングポリシーを確認 | EDR未オンボード端末はリスク評価の対象外になり得る |
| 高 | 条件付きアクセスをReport-onlyで検証 | 誤ブロックによる業務停止を防ぐ |
| 中 | Android device administrator利用状況を棚卸し | 非推奨・利用不可の管理方式から移行が必要 |
| 中 | Windows 10端末の残存状況を確認 | サポート終了後のセキュリティリスクを管理する |
最初の一歩としては、Intune管理センターで「Endpoint security > Defender for Endpoint」を開き、Connection status、プラットフォーム別の接続トグル、EDR Onboarding Statusを確認してください。そのうえで、条件付きアクセスをすぐに本番有効化するのではなく、Report-onlyでサインインログを確認し、想定外の対象ユーザーや端末が含まれていないかを見極めることが重要です。
Microsoft Defender for EndpointとIntuneの連携は、導入して終わりの機能ではありません。端末のオンボーディング状況、リスクしきい値、モバイルの管理方式、条件付きアクセスの適用範囲を定期的に見直すことで、脅威を検出するだけでなく、危険な端末から業務データを守る運用に近づけられます。
コメント