Microsoft Defenderのセキュリティポリシー管理とは?影響範囲と移行・展開の確認ポイント

Microsoft Defenderのセキュリティポリシー管理で最初に確認すべきことは、「どのポータルで作るか」よりも、どのデバイスに、どの管理経路で、どの設定が届くのかです。Microsoft Defender for Endpointでは、Defenderポータルからウイルス対策、ファイアウォール、EDR、攻撃面の縮小などのエンドポイントセキュリティポリシーを作成・割り当て・確認できます。特にWindowsだけでなくmacOSやLinuxも対象に含む環境では、Intune管理デバイス、Defender for Endpoint管理デバイス、Configuration Manager管理デバイスが混在しやすいため、展開前に権限、対象グループ、競合設定、適用状況の確認方法を整理しておく必要があります。

2026年6月2日に更新されたMicrosoft Defender for Endpointの公式概要では、Defender for Endpointがエンドポイントの予防、検出、調査、対応を担うプラットフォームであり、Windows、macOS、Linux、Android、iOSをサポートすることが示されています。エンドポイントセキュリティポリシーは、この保護機能を実際の端末に反映するための運用レイヤーと考えると理解しやすくなります。(Microsoft Learn)

目次

Microsoft Defenderのセキュリティポリシー管理で押さえるべき変更点

Microsoft Defender for Endpointのエンドポイントセキュリティポリシー管理は、従来の「Windows端末にウイルス対策設定を配る」だけの話ではありません。現在の公式情報では、Defenderポータルを起点に、Windows、macOS、Linuxを含む複数OSのセキュリティ設定を統合的に扱う流れが前提になっています。Defenderポータルでは、Endpoints > Configuration management > Endpoint security policies からポリシーを管理できます。(Microsoft Learn)

特に重要な変更点は、Microsoft Defender for Endpointのセキュリティ設定管理が、Intuneに登録されていないデバイスにもIntuneのエンドポイントセキュリティポリシーを拡張して適用できる点です。公式ドキュメントでは、この機能は「Defender for Endpoint security settings management」と説明されており、Intune管理センターまたはMicrosoft Defenderポータルからポリシーを管理し、Microsoft Entra IDグループに割り当てられるとされています。(Microsoft Learn)

ただし、Intuneに登録済みのデバイスはDefender for Endpoint security settings managementのポリシー処理を行わず、Intune経由でポリシーを展開する設計です。つまり、同じDefender設定でも「Intuneで管理する端末」と「MDE管理で受け取る端末」を分けて考える必要があります。(Microsoft Learn)

影響範囲:対象になるデバイスと管理対象外になりやすい端末

Microsoft Defender for Endpointの管理対象は広く、公式概要ではWindows、macOS、Linux、Android、iOSがサポート対象として示されています。ただし、エンドポイントセキュリティポリシーの管理機能で実際に扱えるポリシー種別やプロファイルは、OSごとに異なります。(Microsoft Learn)

Defender for Endpoint security settings managementの公式情報では、対象プラットフォームとしてWindows、Windows Server 2012 R2以降、Linux、macOSが挙げられています。一方で、Windows Server Core 2016以前、非永続VDI、Azure Virtual Desktop、32ビット版Windowsなどはサポート対象外とされています。(Microsoft Learn)

確認項目管理者が見るべきポイント
WindowsクライアントWindows 10/11、Windows Serverを同じ「Windows」として扱わない。サーバー向けグループを分ける
macOSDefenderエージェントのバージョンと、IntuneまたはDefenderポータルで配布する設定の対応範囲を確認する
LinuxサポートされるDefender for Endpointエージェントバージョン、ディストリビューション、JSON設定との使い分けを確認する
Intune登録済み端末Intune側でポリシーを管理する。Defender管理端末と同じグループに入れる場合は競合に注意する
Intune未登録端末MDE管理として扱えるか、Entra ID上のデバイス登録や管理状態を確認する
ドメインコントローラー対応はあるが、誤設定時の影響が大きい。ファイアウォールポリシーはドメインコントローラーではサポートされない点に注意する

実務では、まず「全社PC」「サーバー」「開発端末」「macOS」「Linuxサーバー」「重要システム用端末」のように、業務影響とOSでグループを分けるのが安全です。最初から全デバイスに割り当てると、業務アプリの通信遮断、除外設定の不整合、EDRオンボーディングの失敗に気づきにくくなります。

管理できる主なエンドポイントセキュリティポリシー

Microsoft Defenderポータルのエンドポイントセキュリティポリシーでは、ウイルス対策、ディスク暗号化、ファイアウォール、エンドポイント検出と応答、攻撃面の縮小などを扱います。公式ドキュメントでは、Antivirus、Disk encryption、Firewall、Endpoint detection and response、Attack surface reductionが主なポリシー種別として説明されています。(Microsoft Learn)

ポリシー種別主な用途展開時の注意点
AntivirusMicrosoft Defender Antivirusのリアルタイム保護、除外、更新関連の管理除外設定を増やしすぎると検出力が落ちる。ローカル管理者の上書き可否も確認する
FirewallWindows 10/11やmacOSの組み込みファイアウォール設定業務アプリ、VPN、リモート管理ツールの通信要件を事前に洗い出す
Endpoint detection and responseEDR設定、Defender for Endpointへのオンボーディングオンボーディング済みか、センサーの正常性、チェックイン状況を確認する
Attack surface reductionASRルールでOfficeマクロ、スクリプト、資格情報悪用などの攻撃面を減らすいきなりBlockではなく、Auditで影響を確認してから段階的に強化する
Disk encryptionBitLockerやFileVaultなどOS標準の暗号化設定回復キーの保管、既存暗号化ポリシー、ヘルプデスク対応手順を確認する

特にASRルールとファイアウォールは、セキュリティ効果が高い一方で業務影響も出やすい設定です。開発部門ではビルドツール、スクリプト実行、ローカルWebサーバー、コンテナ、リモートデバッグなどがブロック対象になることがあります。展開前に、対象部署ごとの標準ツールを確認しておくとトラブルを減らせます。

管理者が最初に確認すべき権限とロール

Microsoft Defenderポータルのエンドポイントセキュリティポリシーページは、すべてのデバイスへのアクセス権と Core security settings (manage) 権限を持つユーザーが利用できます。Security Readerのような読み取り中心のロールではアクセスできません。また、ポリシーの表示データはIntuneの権限にも影響されます。(Microsoft Learn)

Microsoftは、可能な限り少ない権限のロールを使うことを推奨しており、Global Administratorは既存ロールでは対応できない緊急時に限定すべき高権限ロールと位置づけています。(Microsoft Learn)

実務上は、次のように役割を分けると運用しやすくなります。

担当者推奨される確認範囲
セキュリティ管理者Defenderポータルのポリシー作成、適用状況、EDR/ASR/AV設定
Intune管理者Intune側のEndpoint security設定、RBAC、デバイス登録状態
Entra ID管理者動的デバイスグループ、デバイスオブジェクト、ライセンス割り当て
サーバー管理者Windows Server、Linux、ドメインコントローラーへの影響
開発部門の代表者ASR、ファイアウォール、除外設定が開発環境に与える影響

権限設計でよくある失敗は、検証時だけGlobal Administratorで作業し、本番運用時の担当者が同じ画面を開けないケースです。ポリシー作成前に、実際に運用する担当者アカウントでDefenderポータルとIntune管理センターの両方を確認してください。

設定・展開前に必要な前提条件

Defender for Endpoint security settings managementを使うには、Microsoft Defender for Endpointのライセンスを含むサブスクリプションが必要です。公式情報では、Microsoft Defender for ServersだけをMicrosoft Defender for Cloud経由で利用している場合、このセキュリティ設定管理機能は利用できず、少なくとも1つのMicrosoft Defender for Endpointユーザーサブスクリプションライセンスが必要とされています。(Microsoft Learn)

また、対象デバイスは *.dm.microsoft.com にアクセスできる必要があります。このエンドポイントは、登録、チェックイン、レポートに使われるクラウドサービス向けの通信として説明されています。(Microsoft Learn)

設定面では、DefenderポータルとIntune管理センターの両方で連携を有効化します。Defenderポータルでは Settings > Endpoints > Configuration Management > Enforcement Scope から対象プラットフォームを有効化し、Intune管理センターでは Endpoint security > Microsoft Defender for Endpoint で「Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations」をオンにします。(Microsoft Learn)

安全な展開手順:いきなり全社展開しない

Microsoftの公式手順では、Defenderポータルからエンドポイントセキュリティポリシーを作成する場合、Microsoft Defenderポータルにサインインし、Endpoints > Configuration management > Endpoint security policies から新しいポリシーを作成し、プラットフォーム、テンプレート、設定、割り当てグループを指定して保存します。(Microsoft Learn)

ただし、実務では「作成手順」より「展開順序」が重要です。安全に進めるなら、次の順序をおすすめします。

手順作業内容判断基準
事前調査既存のIntune、GPO、Configuration Manager、サードパーティEDR/AV設定を棚卸しする同じ設定を複数経路で配っていないか確認する
対象分離OS別・用途別にMicrosoft Entra IDグループを作るWindowsクライアント、Windows Server、macOS、Linuxを分ける
小規模検証タグ付きデバイスや検証グループに限定して配布する業務アプリ、VPN、開発ツール、監視ツールが正常に動くか確認する
Audit運用ASRなど影響が出やすい設定は監査モードで確認するブロック候補を見て例外設定やルール変更を判断する
段階展開部署・拠点・OS単位で広げるエラー率、競合、ヘルプデスク問い合わせを見ながら進める
本番監視適用状況、ポリシー競合、チェックイン時刻を定期確認する失敗端末を放置しない運用を作る

初期展開では、DefenderポータルのEnforcement Scopeで「On tagged devices」を選び、MDE-Management タグを使って小規模に検証する方法が公式情報でも推奨されています。2025年7月3日時点では、この MDE-Management タグの定義に動的資産ルールを使う機能がパブリックプレビューとして示されています。(Microsoft Learn)

移行時の注意点:Intune、GPO、Configuration Managerとの競合を避ける

移行で最も多い失敗は、既存のGPOやConfiguration Manager、Intuneポリシーを残したまま、Defenderポータルから同じ設定を配ってしまうことです。公式情報でも、複数のチャネルを使うと競合や望ましくない結果が発生する可能性があるため、単一チャネルで制御する必要があると説明されています。(Microsoft Learn)

Intuneでは同じデバイスに複数のエンドポイントセキュリティポリシーを展開できますが、同じ設定が別々のポリシーから届くと競合します。一部の設定、たとえばウイルス対策の除外設定はクライアント側でマージされる場合がありますが、すべての設定が安全に統合されるわけではありません。(Microsoft Learn)

移行時は、以下のルールを決めてから作業すると安全です。

移行対象推奨方針
既存のGPOで配布しているDefender設定IntuneまたはDefenderポータルに移す設定を一覧化し、重複配布を止める
Configuration Manager管理端末どちらのチャネルを正とするか決め、同一設定を二重管理しない
サードパーティAVからの移行相互除外、パッシブモード、EDR Block mode、アンインストール順を検証する
サーバー業務停止リスクが高いため、ワークロード単位で例外とロールバック手順を用意する
macOS/LinuxMDM構成プロファイル、JSON、Defenderポータル設定が混在しないように管理台帳を作る

特に開発端末では、セキュリティ強化によってスクリプト、ビルド、ローカルサーバー、コンテナ、署名されていない社内ツールが影響を受けることがあります。セキュリティ部門だけで検証せず、開発チームから代表端末を選んで先行適用するのが現実的です。

割り当てグループ設計で失敗しやすいポイント

Defender for Endpoint security settings managementでは、デバイスはMicrosoft Entra IDデバイスオブジェクトに基づいて割り当てられたポリシーを受け取ります。Entra IDに完全登録されていないデバイスには、ポリシー取得のための合成デバイスIDが作成される場合があります。(Microsoft Learn)

公式情報では、ポリシー配布の対象としてOS種別に基づく動的Microsoft Entraグループを作成することが推奨されています。また、過去に使われていた MDEJoinedMDEManaged のシステムラベルは現在サポートされず、代わりに deviceOSType や管理種別の MicrosoftSense を使う考え方が示されています。(Microsoft Learn)

さらに、Defender for Endpoint channelで通信するデバイスでは割り当てフィルターがサポートされず、ユーザーターゲットではなくデバイスオブジェクトを対象にする必要があります。(Microsoft Learn)

失敗例起きる問題対策
「Windows」だけで動的グループを作るWindows Serverが漏れる、または想定外に含まれるWindowsクライアントとWindows Serverを分けて条件を作る
ユーザーグループに割り当てるMDE管理デバイスに正しく適用されないデバイスグループに割り当てる
MDEManagedタグ前提で運用する新しいデバイスが対象から外れるdeviceOSTypemanagementType を使った条件に見直す
全デバイスに一括適用するサーバーや開発端末に想定外の制限が入るOS別、用途別、重要度別に段階展開する
Intuneフィルターに頼るMDE管理デバイスではフィルターが無視されるEntra IDグループの条件で対象を制御する

適用確認とトラブルシュートの見方

ポリシーを作成しただけでは安全とは言えません。管理者は「作成済み」ではなく「対象デバイスに適用済み」「設定単位で成功」「競合やエラーがない」まで確認する必要があります。

公式ドキュメントでは、ポリシーがデバイスに到達するまで最大90分かかる場合があり、Defender for Endpointで管理されるデバイスではアクションメニューのPolicy syncを使うと約10分で適用できると説明されています。(Microsoft Learn)

また、Intune側ではポリシーの状態、デバイス単位の適用状況、設定単位の成功・エラー・競合を確認できます。Defenderポータル側でも、ポリシーの概要、設定値、設定ステータス、適用デバイス、割り当てグループを確認できます。(Microsoft Learn)

確認場所見るべき項目
Defenderポータルのポリシー詳細Overview、Policy settings status、Applied devices、Assigned Groups
デバイスページSecurity policiesタブ、管理者列、MDE Enrollment status
Intune管理センターEndpoint security配下のレポート、設定単位の成功・エラー・競合
端末ローカルWindowsでは Get-MpPreference などで実効設定を確認
高リスク設定ASR、ファイアウォール、除外、改ざん防止、EDR設定

デバイスがMDE管理として正しく登録されている場合、Defenderポータルのデバイス情報で Managed by がMDEであること、MDE Enrollment statusがSuccessであることを確認できます。(Microsoft Learn)

開発者・自動化担当者が確認すべきポイント

開発者や自動化担当者にとって重要なのは、ポリシー設定そのものをコードで無理に置き換えることではありません。まず、DefenderポータルとIntuneで管理される設定を正とし、その周辺の確認、棚卸し、監査、レポート取得を自動化するのが現実的です。

Microsoft Defender for Endpoint APIは、Defender for Endpointのデータやアクションをプログラムから扱うためのAPIで、利用にはOAuth 2.0認証が必要です。一般的な手順として、Microsoft Entraアプリケーションを作成し、アクセストークンを取得してAPIにアクセスします。バックグラウンドサービスのようにサインインユーザーなしで動くアプリでは、Application Contextが推奨されています。(Microsoft Learn)

自動化するなら、次の用途から始めると効果が出やすいです。

自動化対象実務での使い道
デバイス一覧の棚卸しMDE管理、Intune管理、OS種別、最終チェックインの確認
ポリシー適用状況の監査未適用端末、競合端末、エラー端末の抽出
タグ管理検証対象、重要端末、除外対象の識別
レポート連携SOC、IT運用、監査チーム向けの定期レポート作成
インシデント対応補助アラート、隔離、調査対象端末のワークフロー連携

API連携で注意すべきなのは、権限を広げすぎないことです。読み取りだけで足りる処理に隔離や修復などの強い権限を与えると、認証情報漏えい時の影響が大きくなります。Application Contextを使う場合も、証明書やシークレットの保管、ローテーション、監査ログの確認を運用ルールに含めてください。

展開前チェックリスト

本番展開前には、以下を確認してください。

チェック項目確認内容
ライセンスDefender for Endpointのユーザーサブスクリプションがあるか
権限Security Administrator、Core security settings管理権限、Intune側RBACがそろっているか
通信対象端末が *.dm.microsoft.com に到達できるか
管理経路Intune、MDE、Configuration Manager、GPOのどれを正とするか決めたか
グループOS別・用途別のMicrosoft Entraデバイスグループを作ったか
検証対象MDE-Management タグや検証グループで小規模に始められるか
競合同じ設定を複数ポリシーで管理していないか
業務影響ASR、Firewall、除外、EDR設定を代表端末で検証したか
ロールバック設定変更後に業務影響が出た場合の戻し方を決めたか
監視適用状況、競合、エラー、最終チェックインを誰が確認するか決めたか

まず取るべき対応

Microsoft Defenderのセキュリティポリシー管理は、Defenderポータルから設定を作れば終わりではありません。重要なのは、対象デバイスを正しく分け、IntuneやConfiguration Managerなど既存の管理経路と競合させず、適用状況まで確認することです。

まずは、現在の端末を「Intune管理」「MDE管理」「Configuration Manager管理」「未整理」に分類してください。次に、Windowsクライアント、Windows Server、macOS、Linuxごとに検証グループを作り、Antivirus、EDR、ASR、Firewallの順に影響を確認します。特にASRとFirewallは業務影響が出やすいため、Auditや小規模展開から始めるのが安全です。

最終的には、ポリシーの作成者、承認者、適用対象、確認担当、ロールバック手順を明文化し、DefenderポータルとIntune管理センターの両方で状態を確認できる運用にしておきましょう。これにより、Microsoft Defender for Endpointの保護機能を、単なる導入済みツールではなく、継続的に管理できるエンドポイントセキュリティ基盤として活用できます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次