Microsoft Defender for Endpoint を macOS に Intune で展開する場合、Intuneからアプリを配布するだけでは不十分です。結論から言うと、管理者が優先して確認すべきポイントは、システム拡張機能、ネットワークフィルター、フルディスクアクセス、バックグラウンドサービス、Microsoft AutoUpdate、オンボーディングパッケージを、公式手順どおりの順序で構成することです。
特に macOS 13 以降ではバックグラウンド実行、macOS 14 以降では Bluetooth アクセスなど、OS側のプライバシー制御が展開失敗の原因になりやすくなっています。既存のウイルス対策製品と併用する環境では、passiveMode や相互除外の設計も必要です。この記事では、Microsoft Defender for Endpoint on macOS の Intune ベース展開について、変更点、影響範囲、管理者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。Microsoft Learn の公式手順では、Intune 管理センターで複数の構成プロファイルを作成し、指定された順序で展開することが重要とされています。(Microsoft Learn)
Microsoft Defender for Endpoint on macOS のIntune展開で何が重要なのか
Microsoft Defender for Endpoint on macOS の Intune ベース展開は、Windows 端末への Defender 展開と同じ感覚で進めると失敗しやすい構成です。
理由は、macOS ではセキュリティ製品がOSの深い領域にアクセスするために、Appleのプライバシー制御やシステム拡張機能の承認が必要になるためです。Intuneから Microsoft Defender アプリを配布しても、必要な権限やオンボーディング情報がそろっていなければ、保護機能やEDR連携が正しく動作しません。
管理者が押さえるべき全体像は次のとおりです。
| 確認項目 | 目的 | 失敗した場合に起きやすいこと |
|---|---|---|
| システム拡張機能の承認 | リアルタイム保護やネットワーク関連機能を有効にする | Defenderが必要な拡張機能を読み込めない |
| ネットワークフィルター | EDRやネットワーク保護で通信を検査する | 通信検査やネットワーク保護が期待どおり動作しない |
| フルディスクアクセス | ファイルやプロセスの監視に必要な権限を付与する | 検出漏れ、権限不足、ユーザー確認の発生 |
| バックグラウンドサービス | Defenderの常駐プロセスを許可する | 常駐保護が不安定になる |
| MAU設定 | Microsoft Defenderを継続的に更新する | 古いバージョンのまま運用される |
| オンボーディングパッケージ | テナントと端末を関連付ける | 「ライセンスが見つからない」などの状態になる |
| 状態確認と検出テスト | 展開完了を確認する | 配布済みだが保護されていない端末を見落とす |
公式手順では、構成プロファイルの作成後に Microsoft Defender アプリを発行し、Defenderポータルからオンボーディングパッケージを取得してIntuneで展開し、最後にデバイス状態と検出テストを確認する流れが示されています。(Microsoft Learn)
対象になる環境とライセンス
この手順の対象は、Microsoft Intune で管理している macOS デバイスに Microsoft Defender for Endpoint を展開する組織です。公式ドキュメント上の適用対象には、Microsoft Defender for Endpoint Plan 1、Plan 2、Microsoft Defender for Business が含まれます。(Microsoft Learn)
また、macOS版 Microsoft Defender for Endpoint の前提条件として、Defender for Endpoint のサブスクリプション、Microsoft Defender ポータルへのアクセス、IntuneなどのMDMソリューション、Defender for Endpoint サービスへのネットワーク接続が挙げられています。システム要件では、macOSの最新3つのメジャーリリース、x64およびARM64プロセッサ、1GBのディスク領域などが示されています。(Microsoft Learn)
運用前に確認したいライセンス・環境条件は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft Defender for Endpoint Plan 1/Plan 2、Microsoft Defender for Business など対象ライセンスがあるか |
| MDM | 対象MacがIntuneに登録され、構成プロファイルを受け取れる状態か |
| macOS | サポート対象のmacOSバージョンか |
| ネットワーク | Defender for Endpoint のクラウドサービスへ接続できるか |
| 既存セキュリティ製品 | 他社AV/EDRと併用するか、Defenderへ移行するか |
| 管理範囲 | Defender for Endpointのみか、Purview DLPやDevice Controlも含めるか |
ここで見落としやすいのが、Intune登録済みであることと、Defenderにオンボード済みであることは別物という点です。Intune上で管理対象に見えていても、Defenderポータル側で端末が正しく認識されていなければ、EDRやアラート運用の対象としては不十分です。
管理者が確認すべき主な変更点と実務上の影響
今回のポイントは、単なる「アプリ配布手順」ではなく、macOSのセキュリティ制御に対応した複数の構成プロファイルを、Intuneから確実に配布することにあります。
Intuneのアプリ配布だけでは展開が完了しない
Microsoft Intune では、アプリの種類として「Microsoft Defender for Endpoint > macOS」を選択し、管理対象のmacOSデバイスに割り当てることができます。このアプリ種別を使うと、macOSアプリラッピングツールを使わずに Defender for Endpoint を配布でき、Microsoft AutoUpdate も付属します。(Microsoft Learn)
ただし、アプリを追加しただけでは、次のような設定は完了しません。
- システム拡張機能の事前承認
- ネットワークフィルターの許可
- フルディスクアクセスの付与
- バックグラウンドサービスの許可
- Defenderの構成設定
- オンボーディングパッケージの展開
- EDRやマルウェア検出の検証
つまり、Intuneの「アプリ」画面で配布成功になっていても、セキュリティ機能が期待通り有効化されているとは限りません。展開完了の判断は、Intuneのアプリインストール状態だけでなく、構成プロファイル、Defenderポータル、端末側の状態確認を組み合わせて行う必要があります。
macOSのプライバシー制御への対応が必須になる
macOSでは、セキュリティ製品がファイル、プロセス、ネットワーク、Bluetoothなどへアクセスするために、OS側の権限が必要です。
公式手順では、macOS Catalina以降のフルディスクアクセス、macOS 13 Ventura以降のバックグラウンドサービス、macOS 14 Sonoma以降のBluetoothアクセスについて、それぞれ構成プロファイルで許可する手順が示されています。特に、Intuneで以前から Defender を構成している場合でも、フルディスクアクセスやバックグラウンドサービスの構成プロファイルを使って展開を更新することが推奨されています。(Microsoft Learn)
実務では、次のようなトラブルが起きやすくなります。
| 状況 | 起きやすい問題 | 対応 |
|---|---|---|
| フルディスクアクセス未設定 | Defenderが必要な領域を監視できない | fulldisk.mobileconfig を配布 |
| バックグラウンドサービス未設定 | Defenderの常駐プロセスが制限される | background_services.mobileconfig を配布 |
| Bluetooth制御を使うのに権限未設定 | Device ControlのBluetooth関連ポリシーが機能しない | bluetooth.mobileconfig を配布 |
| 端末側の設定画面だけで確認している | MDMで付与した権限がUI上に見えず誤判定する | Intuneとプロファイル状態で確認 |
なお、MDM構成プロファイルで付与されたフルディスクアクセスやBluetooth権限は、macOSの「システム設定 > プライバシーとセキュリティ」上に反映されない場合があります。端末のUIだけで判断せず、Intuneの構成プロファイル配布状態とDefenderの動作状態を確認することが重要です。(Microsoft Learn)
Intuneで展開する主な構成プロファイル
Microsoft Defender for Endpoint on macOS のIntune展開では、複数の構成プロファイルを段階的に作成します。公式手順では、システム拡張機能、ネットワーク拡張機能、フルディスクアクセス、Defender構成、バックグラウンドサービス、通知、アクセシビリティ、Bluetooth、Microsoft AutoUpdate、Device Control、Data Loss Prevention、オンボーディングパッケージ、アプリ展開などが整理されています。(Microsoft Learn)
管理者向けに、実務で確認すべきプロファイルを整理すると次のようになります。
| 構成 | サンプルファイル・識別子 | 役割 |
|---|---|---|
| システム拡張機能 | com.microsoft.wdav.epsext / com.microsoft.wdav.netext | リアルタイム保護やネットワーク機能に必要 |
| ネットワークフィルター | netfilter.mobileconfig | EDRやネットワーク保護のため通信を検査 |
| フルディスクアクセス | fulldisk.mobileconfig / com.microsoft.wdav.epsext | ファイル・プロセス監視に必要な権限を付与 |
| Defender構成 | com.microsoft.wdav.xml / com.microsoft.wdav | ウイルス対策、EDR、除外、パッシブモードなどを設定 |
| バックグラウンドサービス | background_services.mobileconfig | Defenderの常駐プロセスを許可 |
| 通知 | notif.mobileconfig / com.microsoft.wdav.tray | DefenderやMAUの通知を制御 |
| アクセシビリティ | accessibility.mobileconfig / com.microsoft.dlp.daemon | 一部機能のアクセス許可に使用 |
| Bluetooth | bluetooth.mobileconfig / com.microsoft.dlp.agent | Device ControlでBluetooth制御を使う場合に必要 |
| Microsoft AutoUpdate | com.microsoft.autoupdate2.mobileconfig | Defenderの更新チャネルや更新動作を管理 |
| オンボーディング | WindowsDefenderATPOnboarding.xml | テナントと端末を関連付ける |
| アプリ配布 | Microsoft Defender for Endpoint > macOS | Defenderアプリ本体を配布 |
ここで重要なのは、必要な構成をすべて同じグループへ雑に割り当てればよいわけではないという点です。検証用グループ、段階展開用グループ、本番全体グループを分け、プロファイルの到達状況と端末状態を確認しながら広げるべきです。
展開順序で失敗しないための実務手順
公式手順では、構成プロファイルを指定された順序で作成・展開する必要があるとされています。順序を無視すると、アプリは入っているのに権限が足りない、オンボーディングは済んでいるのに検出が上がらない、といった切り分けが難しい状態になりがちです。(Microsoft Learn)
実務では、次の順序で進めると確認しやすくなります。
| フェーズ | 作業 | 確認ポイント |
|---|---|---|
| 事前確認 | ライセンス、macOS、Intune登録、ネットワーク到達性を確認 | 対象端末がIntune管理下にあるか |
| 権限プロファイル展開 | システム拡張、ネットワークフィルター、フルディスクアクセス、バックグラウンドサービスなどを配布 | 端末にプロファイルが到達しているか |
| Defender設定 | DefenderポータルまたはIntuneでAV/EDR設定を作成 | DefenderポータルとIntuneのどちらで管理するか決めているか |
| アプリ配布 | IntuneのアプリとしてMicrosoft Defender for Endpoint for macOSを割り当て | インストール状態が成功になっているか |
| オンボーディング | Defenderポータルから取得したオンボーディングパッケージをIntuneで配布 | Defenderポータルに端末が表示されるか |
| 検証 | 構成プロファイル、Defenderアイコン、マルウェア検出、EDR検出を確認 | 「配布成功」ではなく「保護状態」を確認しているか |
小規模環境でも、いきなり全社展開するのは避けた方が安全です。まずはIT部門や検証用Macに限定し、OSバージョン、CPUアーキテクチャ、既存セキュリティ製品の有無が異なる端末を含めて確認します。
Defenderポータルで管理するか、Intuneで管理するかを決める
Microsoft Defender for Endpoint のマルウェア対策とEDRポリシーは、Microsoft Defender ポータルまたは Microsoft Intune ポータルのどちらかを使って構成します。公式手順では、9aまたは9bのどちらか一方を実施するよう示されています。(Microsoft Learn)
ここは設計上の分岐点です。両方で似た設定を作ると、どちらが正なのか分かりにくくなります。
| 管理方法 | 向いている環境 | 注意点 |
|---|---|---|
| Microsoft Defender ポータル | セキュリティチームがDefender中心にポリシー管理する環境 | Defenderのセキュリティ設定管理の前提を確認する |
| Microsoft Intune | 端末管理チームがIntuneで構成を一元管理する環境 | カスタム構成プロファイル名を正確に指定する |
| 併用 | 例外的に役割分担が明確な環境 | 同じ設定領域を重複管理しない |
IntuneでDefender設定を構成する場合、カスタム構成プロファイル名として com.microsoft.wdav を正しく入力する必要があります。誤った名前を指定すると、設定が Microsoft Defender for Endpoint に認識されません。(Microsoft Learn)
設定ファイル名やプロファイル名は似たものが多いため、運用ルールとして命名規則を決めておくと管理しやすくなります。
例：
macOS-MDE-01-SystemExtensionsmacOS-MDE-02-NetworkFiltermacOS-MDE-03-FullDiskAccessmacOS-MDE-04-BackgroundServicesmacOS-MDE-05-MAUmacOS-MDE-06-Onboarding
名前の先頭に展開順を入れておくと、後任者や監査担当者が見ても構成の意図を追いやすくなります。
既存のウイルス対策製品と併用する場合の注意点
既に他社製のウイルス対策やEDRを導入しているMacに Microsoft Defender for Endpoint を追加する場合は、競合対策が必要です。
公式手順では、Microsoft以外のウイルス対策をmacOSで実行する予定がある場合、passiveMode を true に設定することが示されています。また、複数のセキュリティソリューションを並行して実行する場合は、パフォーマンス、構成、サポートに関する考慮事項や相互除外の確認が必要です。(Microsoft Learn)
実務上は、次の判断基準で進めると安全です。
| 状況 | 推奨される考え方 |
|---|---|
| Defenderを主たるAV/EDRとして使う | 既存製品の削除計画、除外解除、Defenderのアクティブ化を段階的に実施 |
| 既存AVを主、DefenderをEDR用途で併用 | passiveMode を検討し、二重スキャンや競合を避ける |
| 移行期間だけ併用 | 期間、対象グループ、切り戻し条件を明確化 |
| 開発者Macが多い | ビルドディレクトリ、仮想環境、コンテナ関連の除外設計を慎重に行う |
特に開発者端末では、ソースコード管理、パッケージマネージャー、コンテナ、仮想環境、ビルド成果物が大量に変化します。除外を広げすぎると保護が弱くなり、狭すぎるとパフォーマンス問題につながります。除外設定は「困ったら丸ごと除外」ではなく、検出ログやパフォーマンス影響を見ながら最小限に絞ることが重要です。
ネットワークフィルターは重複させない
macOSのネットワークフィルターは、構成ミスが端末利用に直接影響しやすい設定です。公式手順では、Network Filter の .mobileconfig は1つだけサポートされ、複数のネットワークフィルターを追加するとmacOSでネットワーク接続の問題が発生すると説明されています。(Microsoft Learn)
既存のVPN、Webフィルタリング、プロキシ、DLP、ゼロトラスト系エージェントを使っている環境では、次の確認が必要です。
- 既存製品がネットワーク拡張機能やフィルターを使っているか
- Defenderのネットワーク保護を有効にする範囲
- VPN接続時と社内LAN接続時の通信挙動
- プロキシやSSLインスペクションの有無
- 障害時の切り戻し方法
ネットワーク接続トラブルは、ユーザーからは「インターネットにつながらない」「Teamsが不安定」「ブラウザだけ遅い」と見えます。Defender展開直後に問い合わせが増えた場合は、アプリ本体ではなくネットワークフィルター、VPN、プロキシの組み合わせを確認しましょう。
Microsoft AutoUpdateの設定はセキュリティ運用に直結する
macOS版 Microsoft Defender for Endpoint の更新には Microsoft AutoUpdate、いわゆるMAUが使われます。公式ドキュメントでは、Defender for Endpoint on macOS の各バージョンは6か月後に自動的に期限切れとなるため、最新バージョンをインストールして機能強化を取得することが推奨されています。また、更新にはMAUが使われ、定期的に更新を確認して自動的にダウンロード・インストールします。(Microsoft Learn)
展開時に確認すべきMAUのポイントは次のとおりです。
| 項目 | 推奨される確認 |
|---|---|
| 更新チャネル | 本番端末は原則 Current、検証端末でPreviewやBetaを検討 |
| 自動更新 | セキュリティ更新を止めない設定になっているか |
| ユーザー操作 | ユーザーが勝手に更新設定を変えない運用になっているか |
| アプリ別設定 | Defenderだけチャネルを変える必要があるか |
| バージョン期限 | 古いバージョンが放置されていないか |
注意したいのは、MAUのチャネル設定が他のMicrosoftアプリにも影響する場合があることです。公式ドキュメントでは、MAUのChannelName設定はMicrosoft AutoUpdateを通じて更新されるすべてのアプリケーションのチャネルを変更するため、Defenderだけを変更したい場合はアプリごとの設定を使う方法が案内されています。(Microsoft Learn)
本番運用では、いきなり全端末をPreviewやBetaにするのではなく、少数の検証グループで先行確認し、問題がなければCurrentで全体展開するのが現実的です。
オンボーディングパッケージの展開漏れに注意する
Microsoft Defender for Endpoint on macOS の展開で、よくある失敗がオンボーディングパッケージの展開漏れです。
公式手順では、Microsoft Defender ポータルで Settings > Endpoints > Device management > Onboarding に進み、OSにmacOS、デプロイ方法に「Mobile Device Management / Microsoft Intune」を選択してオンボーディングパッケージをダウンロードします。展開時には、ZIP内の WindowsDefenderATPOnboarding.xml をIntuneのカスタム構成プロファイルとして配布します。(Microsoft Learn)
このプロファイルには、Defender for Endpoint のライセンス情報が含まれます。公式のトラブルシューティングでも、「ライセンスが見つかりません」という問題の原因はオンボーディング未完了であり、オンボーディングパッケージのダウンロードと展開手順を完了するよう案内されています。(Microsoft Learn)
現場での切り分けは次のように考えると分かりやすくなります。
| 症状 | 確認すべきこと |
|---|---|
| Defenderアプリは入っているがDefenderポータルに出ない | オンボーディングパッケージが配布済みか |
| 「ライセンスが見つからない」と表示される | WindowsDefenderATPOnboarding.xml の展開状態 |
| 一部端末だけオンボードされない | Intuneの割り当てグループ、スコープタグ、チェックイン状態 |
| 新規端末だけ失敗する | 登録順序、プロファイル配布タイミング、ネットワーク到達性 |
アプリ配布とオンボーディングは別工程です。展開チェックリストでも、この2つを別項目として管理してください。
Purview DLPやDevice Controlを使う場合の追加確認
Microsoft Defender for Endpoint on macOS の展開は、Microsoft Purview Endpoint Data Loss Prevention や Device Control と関係する場合があります。公式手順では、macOS用Microsoft Defenderアプリが Defender for Endpoint と Microsoft Purview Endpoint DLP の両方の機能を分けて扱うこと、PurviewへmacOSデバイスをオンボードする予定がある場合は、この段階でデバイス監視を有効にする必要があることが説明されています。(Microsoft Learn)
管理者は、次のように整理しておくと混乱を避けられます。
| 利用する機能 | 追加で意識すべき設定 |
|---|---|
| Defender for Endpointのみ | システム拡張、ネットワークフィルター、フルディスクアクセス、MAU、オンボーディング |
| Device Control | フルディスクアクセス、Bluetooth権限、Device Controlポリシー |
| Purview Endpoint DLP | デバイス監視、DLP構成、アクセシビリティ関連設定 |
| ネットワーク保護 | Defender AVテンプレート内のネットワーク保護設定、ネットワークフィルター |
セキュリティチームと情報管理チームが別組織の場合、Defender展開後にDLPを追加しようとして権限不足に気づくことがあります。将来的にPurview DLPを使う可能性があるなら、初期設計の段階で必要なプロファイルと運用責任者を決めておくとスムーズです。
展開後に必ず確認すべき項目
Intuneでプロファイルやアプリが「成功」と表示されても、それだけで完了とは判断しない方が安全です。公式手順では、Intune管理センターのレポート、macOS端末側のデバイス管理画面、Microsoft Defenderアイコン、マルウェア対策検出テスト、EDR検出テストを確認する流れが示されています。(Microsoft Learn)
展開後の確認項目は次のとおりです。
| 確認場所 | 確認内容 |
|---|---|
| Intune管理センター | 構成プロファイル、アプリ、オンボーディングプロファイルの配布状態 |
| macOS端末 | デバイス管理に必要な構成プロファイルが存在するか |
| メニューバー | Microsoft Defenderアイコンが表示されるか |
| Microsoft Defenderポータル | 対象Macがオンボード済みデバイスとして表示されるか |
| 検出テスト | マルウェア対策とEDRの検出テストが成立するか |
| 更新状態 | MAU経由でDefenderが更新されるか |
特に確認すべきプロファイルは次のとおりです。
accessibility.mobileconfigbackground_services.mobileconfigbluetooth.mobileconfigcom.microsoft.autoupdate2.mobileconfigfulldisk.mobileconfigWindowsDefenderATPOnboarding.xmlnetfilter.mobileconfignotif.mobileconfig- Intuneの管理プロファイル
運用開始後も、月次や四半期ごとに「Defenderポータル上で長期間非アクティブなMac」「古いDefenderバージョンのMac」「構成プロファイル適用失敗のMac」を確認する運用を入れると、見えない未保護端末を減らせます。
展開時に失敗しやすいポイント
Microsoft Defender for Endpoint on macOS のIntune展開でつまずきやすいポイントを、実務向けに整理します。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| アプリ配布だけで完了と判断する | 権限プロファイルやオンボーディングが未完了 | アプリ、プロファイル、オンボーディングを別々に確認 |
com.microsoft.wdav の指定を誤る | カスタム構成プロファイル名の入力ミス | コピー＆ペースト後に余分な空白も確認 |
| ネットワークフィルターを重複させる | 既存製品や過去設定を把握していない | 既存構成プロファイルを棚卸ししてから展開 |
| 既存AVと競合する | パッシブモードや相互除外を設計していない | 移行期間と併用条件を明確にする |
| MAUを管理していない | アプリ更新をユーザー任せにしている | MAU構成プロファイルで更新方針を管理 |
| オンボーディング漏れ | アプリ配布とオンボーディングを混同 | Defenderポータルで端末表示を確認 |
| macOSのUIだけで権限確認する | MDM付与権限がUIに見えない場合がある | IntuneとDefenderの状態で確認 |
| 全社へ一括展開する | OS差分や既存製品差分を検証していない | 検証、パイロット、本番の段階展開にする |
現場で特に危険なのは、「Intune上で成功」と「セキュリティ運用上の成功」を混同することです。Intuneは配布状態の確認に強い一方、EDRとして実際に検出・報告できるかはDefenderポータルや検出テストで確認する必要があります。
管理者向けの展開チェックリスト
実際に作業する前に、次のチェックリストを使うと漏れを減らせます。
| チェック | 項目 |
|---|---|
| □ | 対象ライセンスとDefenderポータルへのアクセス権を確認した |
| □ | 対象MacがIntuneに登録されている |
| □ | macOSバージョンとディスク容量の要件を確認した |
| □ | Defender for Endpointサービスへのネットワーク接続を確認した |
| □ | 既存AV/EDRとの併用方針を決めた |
| □ | 必要に応じて passiveMode と相互除外を設計した |
| □ | システム拡張機能を承認するプロファイルを作成した |
| □ | ネットワークフィルターが重複していないことを確認した |
| □ | フルディスクアクセス、バックグラウンドサービス、通知、アクセシビリティ、Bluetoothのプロファイルを整理した |
| □ | Microsoft AutoUpdateの更新チャネルと自動更新方針を決めた |
| □ | DefenderポータルまたはIntuneのどちらでポリシー管理するか決めた |
| □ | Microsoft DefenderアプリをIntuneで割り当てた |
| □ | Defenderポータルからオンボーディングパッケージを取得した |
| □ | WindowsDefenderATPOnboarding.xml をIntuneで配布した |
| □ | Intune、macOS端末、Defenderポータルで展開状態を確認した |
| □ | マルウェア対策検出とEDR検出のテストを実施した |
| □ | 失敗時の切り戻し手順と問い合わせ窓口を用意した |
開発者端末に展開する場合の追加ポイント
開発者が使うMacは、一般事務端末よりも検証が重要です。理由は、開発ツール、ローカルサーバー、コンテナ、仮想環境、署名ツール、パッケージマネージャーなどが、Defenderの監視対象になりやすいからです。
開発者端末では、次の点を事前に確認しましょう。
- ビルド時間が極端に伸びないか
- Dockerや仮想環境の動作に影響がないか
- npm、pip、Homebrewなどのパッケージ取得に影響がないか
- ローカルプロキシや証明書管理と競合しないか
- CI/CD用の署名・証明書・秘密情報管理に影響しないか
- 誤検知が発生した場合の申請フローがあるか
ただし、開発ディレクトリ全体を広く除外すると、攻撃者にとって都合のよい逃げ道になる可能性があります。除外は、影響が確認されたパスやプロセスに限定し、理由、期限、承認者を記録する運用が望ましいです。
今後の運用で見直すべきポイント
Microsoft Defender for Endpoint on macOS は、一度展開して終わりではありません。macOSの新バージョン、Intuneの管理画面変更、Defenderの機能追加、MAUの更新チャネル、Purview DLPやDevice Controlの利用拡大に合わせて見直しが必要です。
定期的に確認したい運用項目は次のとおりです。
| 頻度 | 確認項目 |
|---|---|
| 毎週 | Defenderポータルで非アクティブ端末、重大アラート、オンボード失敗を確認 |
| 毎月 | Intuneの構成プロファイル失敗、アプリ配布失敗、古いOS端末を確認 |
| 四半期 | 除外設定、パッシブモード、既存AVとの併用状態を棚卸し |
| macOS大型更新前 | システム拡張、ネットワークフィルター、権限プロファイルの互換性を検証 |
| DLP導入前 | Purviewのデバイス監視、アクセシビリティ、Bluetooth、Device Controlの必要性を再確認 |
特に、macOSの大型アップデート前には検証用端末で先行確認することが重要です。OSのプライバシー制御やバックグラウンド実行の仕様変更により、従来のプロファイルでは十分でなくなる可能性があります。
まとめ：Intune展開は「配布」ではなく「保護状態の完成」まで確認する
Microsoft Defender for Endpoint on macOS のIntuneベース展開では、アプリ配布だけでなく、構成プロファイル、OS権限、更新、オンボーディング、検出テストまでを一連の作業として管理する必要があります。
管理者が最初に取るべき行動は、現在のIntune構成を棚卸しし、次の3点を確認することです。
- 必要な構成プロファイルが公式手順の順序に沿って展開されているか
- Microsoft Defenderアプリの配布とオンボーディングパッケージの展開を分けて確認しているか
- Intuneの成功表示だけでなく、Defenderポータルと検出テストで保護状態を確認しているか
既存のウイルス対策製品と併用している場合は、passiveMode、相互除外、ネットワークフィルターの重複確認を優先してください。開発者MacやDLP対象端末が多い環境では、パイロット展開でパフォーマンスと業務影響を確認してから本番へ広げるのが安全です。
Microsoft Defender のmacOS展開は手順が多いものの、設計を分けて整理すれば難しくありません。重要なのは、「入ったか」ではなく「守れているか」を基準に、Intune、macOS、Defenderポータルの3点で確認することです。
コメント