Microsoft Defender for Endpointを導入・運用している環境では、ファイアウォールやプロキシで許可するURLの見直しが必要になる場合があります。特に今回の「Microsoft Defender for Endpoint streamlined connectivity URLs – commercial」は、商用クラウド環境でデバイスをオンボードし、継続的に保護するために必要な接続先を整理した公式情報です。対象は主に、Microsoft Defender for Endpointの通信先を簡素化したい管理者、IntuneやMicrosoft Defender for Cloudで展開している運用担当者、オンボーディングスクリプトやネットワーク設定を管理する開発・インフラ担当者です。
結論から言うと、確認すべきポイントは3つです。まず、コア通信では *.endpoint.security.microsoft.com を中心とした簡素化された接続先を許可します。次に、SmartScreen、Windows Update、証明書失効確認、Linux構成取得、Live Responseなど、簡素化対象外のURLを落とさないようにします。最後に、既存デバイスは自動で切り替わらないケースがあるため、OS・エージェント・オンボーディング方式ごとに移行手順を分けて確認する必要があります。Microsoft Learnの該当ページでは、商用クラウド環境でDefender for Endpointのデバイスをオンボード・維持するためのstreamlined connectivity URL一覧として説明されています。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
今回の内容は、Microsoft Defenderそのものの検出機能を変える更新というより、Microsoft Defender for Endpointがクラウドサービスへ接続するためのURL設計を簡素化するための整理と捉えると分かりやすいです。
従来、Defender for Endpointの通信には、MAPS、マルウェアサンプル送信、AutoIR、Command and Control、EDR関連データなど、複数の接続先が関係していました。streamlined connectivityでは、商用クラウド向けのコア通信を *.endpoint.security.microsoft.com に集約する方向で設計されています。公式情報では、この簡素化ドメインがクラウド保護、マルウェアサンプル送信、Auto-IR、Defender for Endpointのコマンド制御、サイバー・診断データなどをまとめるものとして説明されています。(Microsoft Learn)
ただし、ここで重要なのは「すべてのURLが1つにまとまるわけではない」という点です。SmartScreen、Windows Update、証明書検証、Linuxの構成取得、Live Response、脆弱性管理のネットワークスキャナーなどは、用途に応じて別途許可が必要です。*.endpoint.security.microsoft.com だけを許可して旧URLを一気に削除すると、オンボーディング、クラウド保護、更新、応答操作の一部で障害が出る可能性があります。
何が変わったのか
2026年6月上旬時点の公式ページでは、変更履歴に reflector.defender.microsoft.com の追加が記録されています。このURLは、Microsoft DefenderがIPv6接続性を確認するために使う任意の接続先として掲載されています。(Microsoft Learn)
また、2026年春以降の変更として、SmartScreen関連URLの追加、Linux向け内部構成管理URLの追加、Macアプリ・プラットフォーム更新に関するCDN参照の整理なども変更履歴に含まれています。(Microsoft Learn)
管理者が押さえるべき実務上の変化は、次のとおりです。
| 確認項目 | 実務上の意味 | 対応の優先度 |
|---|---|---|
*.endpoint.security.microsoft.com | Defender for Endpointのコア通信先として使われる | 高 |
reflector.defender.microsoft.com | IPv6接続性の確認に使われる任意URL | 中 |
| SmartScreen関連URL | Web保護、アプリ評価、URL/IPカスタムインジケーターに影響 | 高 |
config.edge.skype.com/config/v1 | Linuxエンドポイントがクラウドから内部構成を受け取るために必要 | Linux利用時は高 |
| Windows Update・定義更新URL | セキュリティインテリジェンス、プラットフォーム、EDRセンサー更新に影響 | 高 |
| 証明書検証URL | TLS接続や証明書失効確認に影響 | 高 |
| OneDsCollectorサービス タグ | IPベース許可時にEDR Cyberdata用として別途考慮が必要 | IP制御環境では高 |
特に注意したいのは、URLベースでは簡素化されても、IPアドレスベースで制御している環境では MicrosoftDefenderForEndpoint だけで完結しない点です。公式情報では、EDR CyberdataサービスであるOneDsCollectorは MicrosoftDefenderForEndpoint サービスタグのIP範囲に含まれないため、両方のサービスタグのIP範囲が必要と説明されています。(Microsoft Learn)
影響を受ける環境
影響を受けるのは、主にDefender for Endpointの通信をファイアウォール、プロキシ、URLフィルタリング、ゼロトラスト系のゲートウェイで制御している組織です。特に、出口通信を厳格に許可リスト方式で運用している環境では、今回の情報をそのままネットワーク変更管理の対象にする必要があります。
影響が大きい環境
次のような環境では、優先して確認してください。
| 環境 | 確認すべき理由 |
|---|---|
| プロキシ必須の社内ネットワーク | Defender for EndpointのEDR通信とMicrosoft Defender Antivirusのプロキシ設定が別になる場合がある |
| URL許可リスト方式のファイアウォール | 新しいURLを許可しないとオンボードや通信確認に失敗する可能性がある |
| IntuneでオンボードしているWindows端末 | 既存ポリシーと新しいstreamlinedオンボーディングポリシーの競合に注意が必要 |
| Microsoft Defender for Cloud経由でサーバーをオンボードしている環境 | 既存サーバーが自動的に新しい接続先へ切り替わらないケースがある |
| Windows Server 2012 R2 / 2016を運用している環境 | modern unified solutionへの対応状況とEDRセンサー更新を確認する必要がある |
| macOS / Linuxを含むクロスプラットフォーム環境 | OSごとにサービス再起動や追加URLの要件が異なる |
| Windows 10 1607〜1803が残っている環境 | 新しいオンボーディングパッケージは使えても、長いURLリストが必要になる |
| MMA / Log Analytics Agentを使っている古い端末 | streamlined connectivityの対象外で、従来方式を継続する必要がある |
公式情報では、MMAまたはLog Analytics Agent経由のWindows 7 SP1、Windows 8.1、Windows Server 2008 R2、およびmodern unified solutionへ更新されていないWindows Server 2012 R2 / 2016は、引き続きレガシー方式を使うとされています。また、Windows 1607、1703、1709、1803は新しいオンボーディングパッケージを利用できるものの、追加URLを含む長いリストが必要です。(Microsoft Learn)
まず許可すべき主要URL
Microsoft Defender for Endpointのstreamlined connectivityで中心になるのは、商用クラウド向けの *.endpoint.security.microsoft.com です。これはDefender for Endpointのコアサービスに使われる必須URLとして掲載されています。(Microsoft Learn)
ただし、実際の運用では以下の分類で確認すると漏れを防げます。
コア機能に必要なURL
| 用途 | URL / エンドポイント | 注意点 |
|---|---|---|
| Defender for Endpointコアサービス | *.endpoint.security.microsoft.com | MAPS、サンプル送信、AutoIR、Command and Control、Cyberdataなどの中核通信 |
| Web / ネットワーク保護 | *.smartscreen-prod.microsoft.com、*.smartscreen.microsoft.com | SmartScreen、Webコンテンツフィルタリング、カスタムURL/IPインジケーターに関係 |
| アプリ実行時のSmartScreen評価 | *.smartscreen.microsoft.com、*.checkappexec.microsoft.com、*.urs.microsoft.com | ダウンロードアプリの評価・信頼性確認に関係 |
| IPv6接続性の確認 | reflector.defender.microsoft.com | 任意だが、接続性確認や検出補助の観点で確認対象 |
| Linux内部構成管理 | https://config.edge.skype.com/config/v1 | Linuxエンドポイントでクラウドから内部構成を受け取るために必要 |
Linux向けURLに含まれる skype という文字列は、Skype機能を意味するものではなく、後方互換性のために残っている名称です。セキュリティ審査で「Skype関連通信ではないか」と指摘されやすい部分なので、変更申請時には用途を明記しておくと説明がスムーズです。(Microsoft Learn)
更新・証明書・Live Response関連のURLも忘れてはいけない
streamlined connectivityで失敗しやすいのは、コアURLだけを許可して、更新や証明書関連の接続先を見落とすパターンです。Defender for Endpointは、オンボード後もセキュリティインテリジェンス、EDRセンサー、プラットフォーム更新、証明書検証など複数の通信に依存します。
更新に関係する接続先
Linuxアプリやプラットフォーム更新では packages.microsoft.com が使われます。Windows、macOS、Linuxのセキュリティインテリジェンス更新やWindowsのマルウェア対策プラットフォーム更新では、go.microsoft.com、definitionupdates.microsoft.com、Microsoftのセキュリティインテリジェンス関連ページなどが掲載されています。Windows Updateを更新元にしている場合は、*.update.microsoft.com、*.delivery.mp.microsoft.com、*.windowsupdate.com、*.download.windowsupdate.com、*.download.microsoft.com なども確認対象です。(Microsoft Learn)
WSUS、Configuration Manager、社内ミラー、ファイル共有で更新を配布している場合、すべての端末が直接これらに接続する必要はない場合があります。ただし、その場合でも「どの経路で定義更新・プラットフォーム更新・EDRセンサー更新を配るのか」を明確にしておく必要があります。更新元が曖昧なままURLを閉じると、検出エンジンやセキュリティインテリジェンスが古いまま残る可能性があります。
証明書検証に関係する接続先
証明書失効リストやルート証明書の更新に関係するURLも重要です。公式情報では、www.microsoft.com/pkiops/*、www.microsoft.com/pki/*、ctldl.windowsupdate.com、crl.microsoft.com などがWindowsの証明書検証チェックに使われる接続先として掲載されています。(Microsoft Learn)
閉域環境では、単純に外部通信を遮断するのではなく、信頼済みルート証明書や失効情報を別手段で更新できる設計にしておくことが重要です。TLS接続やクラウド保護で証明書検証ができないと、Defender側の機能不全に見える障害が発生することがあります。
Live Responseと脆弱性管理スキャナー
Live Responseを使う場合、Windows Push Notification Services関連の login.microsoftonline.com、*.wns.windows.com、login.live.com が関係します。公式情報では、WNSを使うLive Responseはプロキシ経由では使えず、WindowsクライアントOSでは直接接続またはプロキシバイパスが必要と説明されています。(Microsoft Learn)
また、脆弱性管理のネットワークスキャナーを使う場合は、*.security.microsoft.com、*.blob.core.windows.net/networkscannerstable/*、login.windows.net なども確認対象です。通常のエンドポイント保護だけでなく、Microsoft Defender Vulnerability Managementを使っている組織では忘れずに確認してください。
プロキシ環境での注意点
プロキシ環境では、Microsoft Defender for Endpointの通信を「ブラウザーと同じプロキシ設定で通るはず」と考えると失敗しやすくなります。Defender for EndpointセンサーはWindowsのWinHTTPを使い、LocalSystemコンテキストで通信します。WinHTTPの設定は、ユーザーのブラウザーで使われるWinINetのプロキシ設定とは独立しています。(aka.ms)
さらに、Microsoft Defender AntivirusとEDRのプロキシ設定は別々に構成される場合があります。公式情報でも、EDRとMicrosoft Defender Antivirusの2種類のプロキシ設定を正しく構成する必要があると説明されています。(aka.ms)
プロキシ設計で特に注意すべき点は次のとおりです。
| 注意点 | 失敗例 | 推奨対応 |
|---|---|---|
| ユーザー認証付きプロキシ | LocalSystemで動くDefender通信が認証できず失敗する | デバイス起点通信として認証不要または適切なバイパスを設計する |
| SSLインスペクション | 証明書ピンニングやTLS接続が壊れる | Defender関連通信はSSL検査の除外対象にする |
| WinINetだけ設定 | ブラウザーは通信できるがDefenderセンサーは通信できない | WinHTTP、EDR、Defender Antivirusの設定を分けて確認する |
| PAC / WPADの過信 | 一部端末やサーバーで解決できず接続失敗 | Client Analyzerで実機検証する |
| 閉域環境 | CRLやWindows Updateに到達できず証明書検証や更新に失敗 | WSUS、ConfigMgr、社内配布、証明書管理の代替経路を設計する |
公式情報では、Defender for Endpointの接続は証明書ピンニングとTLSを使い、トラフィック検査はサポートされないこと、接続はユーザー起点ではなくデバイス起点であること、ユーザー認証を強制するプロキシは接続を壊すことが説明されています。(Microsoft Learn)
IPアドレスで許可する場合の落とし穴
URLではなくIPアドレスで出口制御している環境では、Azureサービス タグの扱いが重要です。公式情報では、名前解決やワイルドカードに対応できない一部シナリオ向けに、Defender for Endpoint専用の静的IP範囲をURLの代替として使えると説明されています。(Microsoft Learn)
ただし、IPベース許可には次の落とし穴があります。
| 落とし穴 | 内容 |
|---|---|
MicrosoftDefenderForEndpoint だけでは足りない | EDR CyberdataのOneDsCollectorは別のサービスタグとして考慮が必要 |
| SmartScreenやWindows Updateは別扱い | コアサービスのIPだけではWeb保護や更新が成立しない場合がある |
| サービス タグの更新追従が必要 | IP範囲は変わり得るため、定期的な更新運用が必要 |
| 既存サーバーが自動切替されない | IntuneやDefender for Cloud経由でも、既存オンボード済みサーバーは再オンボードが必要になる場合がある |
公式情報では、IntuneやMicrosoft Defender for Cloudのコネクターを使って新規デバイスをオンボードする場合、Microsoft Defenderポータルの詳細設定で「Apply streamlined connectivity settings to devices managed by Intune and Defender for Cloud」を有効にする必要があるとされています。また、オンボード済みサーバーはAzureサービス タグで定義される新しい宛先へ自動的には切り替わらないため、旧宛先への接続を維持するか、再オンボードして新しいサービスタグやIPアドレスを使えるようにする必要があります。(Microsoft Learn)
対象OSと前提条件を確認する
streamlined connectivityは、すべてのOS・すべてのエージェント方式で同じように使えるわけではありません。Microsoft Learnでは、Windows 10 version 1809以降、Windows 11、Windows Server 2019以降、modern unified solutionを実行するWindows Server 2012 R2 / 2016、対応バージョンのmacOS / Linux、Azure Stack HCI OS version 23H2以降などが対象として整理されています。(Microsoft Learn)
Windowsでは、SENSE、Microsoft Defender Antivirusのクライアント、エンジン、セキュリティインテリジェンスなどの前提バージョンも確認対象です。公式情報では、Windows向けにSENSE version 10.8040系以上、Microsoft Defender AntivirusのAntimalware Client、Engine、Security Intelligenceの前提バージョンが示されています。(Microsoft Learn)
管理者は、URL許可の前に次の順番で棚卸しすると安全です。
| 順番 | 確認項目 | 確認内容 |
|---|---|---|
| 1 | OSバージョン | Windows 10 1607〜1803、Windows 7/8.1、古いServerが残っていないか |
| 2 | オンボード方式 | Intune、Group Policy、Configuration Manager、Defender for Cloud、ローカルスクリプト、MMAのどれか |
| 3 | エージェント状態 | modern unified solutionか、MMA / Log Analytics Agentか |
| 4 | Defenderコンポーネント | EDRセンサー、Defender Antivirus、セキュリティインテリジェンスが前提を満たすか |
| 5 | ネットワーク経路 | 直接接続、プロキシ、PAC/WPAD、IP許可、SSL検査の有無 |
| 6 | 更新方式 | Windows Update、WSUS、ConfigMgr、社内ミラー、ファイル共有のどれを使うか |
| 7 | 検証方法 | Client Analyzer、Advanced Hunting、Event Viewer、Live Responseテストを使うか |
この順番で確認すると、「URLは許可したのにオンボードできない」「新URLへ切り替えたはずなのにConnectivityTypeが空のまま」「古いWindowsだけ失敗する」といった切り分けがしやすくなります。
既存デバイスを移行するときの進め方
既にDefender for Endpointへオンボード済みのデバイスをstreamlined connectivityへ移行する場合、多くのケースで完全なオフボードは不要です。公式の移行ページでは、更新されたオンボーディングパッケージを実行し、Windowsでは再起動、macOSとLinuxでは再起動またはサービス再起動を行うことで切り替える流れが説明されています。(Microsoft Learn)
ただし、Windows 10 version 1607、1703、1709、1803は再オンボードによる切り替えをサポートしません。これらは一度オフボードしてから、streamlinedオンボーディングパッケージでオンボードする必要があります。また、MMAエージェントを使うデバイスはstreamlined connectivityの対象外です。(Microsoft Learn)
移行の実務手順
| フェーズ | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 小規模テスト | 代表的なOS・ネットワーク経路の端末を数台選ぶ | 本社LANだけでテストし、VPN・VDI・拠点端末を見落とす |
| ネットワーク許可 | 新URL、SmartScreen、更新、CRL、必要なサービスタグを許可 | *.endpoint.security.microsoft.com だけで済ませてしまう |
| 新オンボーディングパッケージ取得 | Microsoft Defender XDRのオンボーディング画面でConnectivity typeにStreamlinedを選ぶ | 既存の標準パッケージを再利用してしまう |
| 既存ポリシー除外 | 古いオンボーディングポリシーから対象端末を除外する | IntuneやJAMFで旧・新ポリシーが競合する |
| 再起動・サービス再起動 | Windowsは再起動、Linuxは mdatp サービス再起動など | パッケージ適用だけで切り替わったと判断する |
| 接続確認 | Client Analyzer、Advanced Hunting、Event Viewerで確認 | ポータルに表示されるだけで正常と判断する |
| 段階展開 | 部署・OS・拠点ごとに順次展開 | 一括展開して障害範囲が広がる |
| 旧URL整理 | 監視後に不要な旧URLを削除 | 旧OSやMMA端末が残っているのに削除する |
Intuneを使う場合は、新しいオンボーディングポリシーを作成してテストグループへ割り当て、既存ポリシーとの競合を避けるのが安全です。公式情報でも、Intuneの「auto from connector」オプションはオンボーディングパッケージを自動的に再適用しないため、新しいポリシーを作成してテストグループに展開することが推奨されています。(Microsoft Learn)
Microsoft Defender for Cloud経由のサーバーでは、ポータルのAdvanced Featuresでstreamlined connectivity設定を有効にすると、新しく追加されるデバイスは新しいオンボーディング情報を使い始めるとされています。ただし、既存デバイスは自動的に再オンボードされないため、必要に応じてオンボーディングスクリプトの適用を検討します。(Microsoft Learn)
管理者・開発者が確認すべき設定
今回の変更は、セキュリティ管理者だけでなく、構成管理や自動化を担当する開発者にも影響します。オンボーディングスクリプト、IaC、ファイアウォール申請テンプレート、Intuneプロファイル、Configuration Managerの展開パッケージ、Linux構成管理ツールなどに旧URLが固定で埋め込まれていないか確認してください。
管理者向けチェックリスト
*.endpoint.security.microsoft.comを許可しているか- SmartScreen関連URLをWeb保護・URL/IPインジケーター用途として許可しているか
- Windows Update、定義更新、Microsoft Defender Antivirusプラットフォーム更新の経路が決まっているか
- 証明書検証用のCRL / PKI関連URLに到達できるか
- Linux端末で
config.edge.skype.com/config/v1を許可しているか - Live Responseを使うWindowsクライアントでWNS関連通信をプロキシバイパスできるか
- IP許可の場合、
MicrosoftDefenderForEndpointとOneDsCollectorの両方を考慮しているか - Intune / Defender for Cloudのstreamlined connectivity設定を有効化しているか
- 既存オンボード済みサーバーの再オンボード要否を確認したか
- MMA端末や古いWindowsを旧URL削除の対象に含めていないか
- Defender関連プロセスがサードパーティ製EDRやAV、アプリ制御でブロックされていないか
開発者・自動化担当向けチェックリスト
- オンボーディングパッケージをリポジトリに固定配置している場合、新しいstreamlined版に差し替える手順を用意する
- Terraform、Bicep、ARMテンプレート、Ansible、Chef、PuppetなどでURLやIPを固定している場合、変数化・差し替え可能な設計にする
- Linux展開では、パッケージ更新用の
packages.microsoft.comと内部構成管理URLの両方を確認する - macOS / Linuxでは、パッケージ適用後にサービス再起動または端末再起動を展開手順に含める
- CI/CDや運用自動化サーバーからMicrosoft Defender XDRポータルやAPIへアクセスする場合、管理用URLと端末用URLを混同しない
- 監視スクリプトでAdvanced Huntingの
ConnectivityTypeを取得し、Standard / Streamlined / 空欄を可視化する
Microsoft Learnでは、DefenderポータルURLは管理・セキュリティ運用のアクセスに必要なものであり、すべてのデバイスから到達可能にする必要はないと説明されています。つまり、一般端末用の許可リストと、管理者端末・自動化基盤用の許可リストは分けて管理するのが実務上は安全です。(Microsoft Learn)
移行後の確認方法
streamlined connectivityへの移行は、ポリシーを配布して終わりではありません。Microsoft Defender XDR上でデバイスが見えていても、実際には旧接続先を使っている、または一部通信だけ失敗していることがあります。
確認には、次の方法を組み合わせるのが現実的です。
| 確認方法 | 確認できること | 向いている場面 |
|---|---|---|
| Microsoft Defender for Endpoint Client Analyzer | URL到達性、プロキシ経路、接続失敗の切り分け | 展開前・展開後の実機検証 |
| Advanced Hunting | デバイスごとのConnectivityType確認 | 大量端末の移行状況確認 |
| Windows Event Viewer | SENSEログで接続成功・失敗を確認 | 個別端末の深掘り |
| Device Inventory / Timeline | 端末が継続的にイベント送信しているか確認 | ポータル側の運用確認 |
| Live Responseテスト | 応答操作が機能するか確認 | インシデント対応機能の確認 |
MpCmdRun.exe -ValidateMapsConnection | クラウド保護の接続確認 | Microsoft Defender Antivirusの確認 |
mdatp connectivity test | macOS / Linuxの接続確認 | クロスプラットフォーム環境 |
公式の検証手順では、未オンボード端末でstreamlined接続をテストする場合、オンボーディングパッケージから取り出した .cmd を指定して mdeclientanalyzer.cmd -o <path to onboarding cmd file> を実行する方法が示されています。既にstreamlinedオンボーディングパッケージでオンボード済みの端末では、通常どおりClient Analyzerを実行すると、構成済みのオンボーディングパラメーターを使って接続確認が行われます。(Microsoft Learn)
Advanced Huntingでは、DeviceInfo テーブルの ConnectivityType 列で接続方式を確認できます。Microsoft Learnでは、値として空欄、Streamlined、Standard が説明されており、EDR Command & Controlチャネルとの通信が成功すると Streamlined として表されます。(Microsoft Learn)
確認用のKQL例は次のとおりです。
DeviceInfo
| where OnboardingStatus == "Onboarded"
| summarize arg_max(Timestamp, ConnectivityType, OSPlatform) by DeviceName
| project DeviceName, OSPlatform, ConnectivityType, TimestampOS別に集計する場合は、次のように確認できます。
DeviceInfo
| where OnboardingStatus == "Onboarded"
| summarize arg_max(Timestamp, ConnectivityType, OSPlatform) by DeviceName
| summarize DeviceCount=count() by OSPlatform, ConnectivityType
| order by OSPlatform ascWindows端末単位で確認する場合は、Event Viewerの Microsoft-Windows-SENSE/Operational ログも有効です。公式情報では、SENSE Event ID 4がEDR接続成功を追跡し、メッセージ内に endpoint.security.microsoft.com を含むURLが表示される例が示されています。(Microsoft Learn)
よくある失敗と回避策
*.endpoint.security.microsoft.com だけを許可してしまう
最も多い失敗は、streamlined connectivityを「このURLだけ許可すればよい」と誤解することです。実際には、SmartScreen、Windows Update、定義更新、証明書検証、Live Response、脆弱性管理スキャナーなど、機能ごとに別の接続先が残ります。
回避策は、機能別に許可リストを作ることです。「コア通信」「Web保護」「更新」「証明書」「応答操作」「管理ポータル」「OS別追加要件」に分けて申請すると、レビュー時の抜け漏れを減らせます。
旧OSやMMA端末を同じ移行対象に入れてしまう
Windows 10 1607〜1803やMMAエージェント端末は、最新のWindows 11やWindows Server 2022と同じ扱いにできません。特にMMA端末はstreamlined connectivityの対象外で、従来方式を継続する必要があります。(Microsoft Learn)
回避策は、移行前にOSとオンボーディング方式でグループを分けることです。IntuneやConfiguration Managerのコレクション、Defender XDRのデバイスグループ、CMDBの情報を使い、古いOSを段階展開から除外します。
プロキシ認証やSSL検査で通信を壊す
Defender for Endpointの通信はデバイス起点で、ユーザー認証前提のプロキシと相性が悪い場合があります。また、SSLインスペクションはサポートされないため、通信を検査対象に入れると接続失敗の原因になります。(Microsoft Learn)
回避策は、Defender関連通信を認証不要のデバイス通信として設計し、SSL検査対象から除外することです。セキュリティ部門には、「検査しない」のではなく「Microsoft Defenderのクラウド保護通信を壊さないための除外」と説明すると合意しやすくなります。
Intuneの既存ポリシーと新ポリシーが競合する
既存の標準オンボーディングポリシーが残ったまま、新しいstreamlinedオンボーディングポリシーを同じ端末に割り当てると、想定どおり切り替わらない可能性があります。公式の移行情報でも、既存オンボーディングポリシーから対象デバイスを除外することが案内されています。(Microsoft Learn)
回避策は、テストグループを作り、旧ポリシーから除外してから新ポリシーを割り当てることです。展開後はAdvanced Huntingで ConnectivityType を確認します。
再起動・サービス再起動を省略する
オンボーディングパッケージを適用しても、OSによっては再起動やサービス再起動をしないと新しい接続方式に切り替わりません。公式情報では、Windowsは再起動、macOSは再起動またはDefender for Endpointサービス再起動、Linuxは sudo systemctl restart mdatp によるサービス再起動が示されています。(Microsoft Learn)
回避策は、展開手順書に「適用」と「切替完了」を分けて書くことです。再起動待ち端末をレポート化し、移行完了判定には ConnectivityType やClient Analyzerの結果を使います。
変更管理で使える確認テンプレート
ネットワーク変更申請やセキュリティレビューでは、以下のように整理すると説明しやすくなります。
| 申請項目 | 記載例 |
|---|---|
| 変更目的 | Microsoft Defender for Endpointのstreamlined connectivity対応 |
| 対象範囲 | Windows 11、Windows Server 2022、macOS、LinuxのDefender for Endpointオンボード端末 |
| 除外対象 | MMA利用端末、Windows 10 1607〜1803、modern unified solution未適用サーバー |
| 追加許可URL | *.endpoint.security.microsoft.com、SmartScreen関連、更新関連、証明書検証関連、Linux構成URLなど |
| IP制御 | Azureサービス タグ MicrosoftDefenderForEndpoint と OneDsCollector を確認 |
| プロキシ方針 | ユーザー認証不要、SSL検査除外、WinHTTP確認 |
| 展開方式 | Intune新ポリシー、Configuration Manager、ローカルスクリプトなど |
| 検証方法 | Client Analyzer、Advanced Hunting、Event Viewer、Live Responseテスト |
| ロールバック | 旧URL許可を一定期間維持し、問題端末は標準接続方式または従来方式で継続 |
| 完了条件 | ConnectivityType が Streamlined、イベント送信継続、クラウド保護とLive Responseが成功 |
このテンプレートを使うと、単なるURL追加ではなく「Microsoft Defenderの保護機能を継続するための通信設計変更」として説明できます。
今すぐ取るべき対応
まず、Microsoft Defender for Endpointを利用している端末をOS、オンボーディング方式、ネットワーク経路ごとに棚卸ししてください。次に、*.endpoint.security.microsoft.com を中心に、SmartScreen、更新、証明書検証、Linux、Live Response、脆弱性管理スキャナーのURLを機能別に整理します。そのうえで、IntuneやDefender for Cloud、Configuration Manager、JAMF、Linux構成管理ツールに残っている古いオンボーディングパッケージや固定URLを確認します。
移行は一括ではなく、小さなテストグループから始めるのが安全です。Client Analyzerで接続を確認し、Advanced Huntingで ConnectivityType を見て、Event ViewerやLive Responseで実際の通信を検証します。問題がなければ、OS・拠点・ネットワーク経路ごとに段階展開し、最後に旧URLの削除可否を判断してください。
今回のstreamlined connectivity URLsは、管理するURLを減らせる一方で、古いOS、MMA、プロキシ、IP制御、更新経路を見落とすと障害につながります。Microsoft Defenderの保護を止めずに移行するには、「新しいURLを追加する作業」ではなく、「端末・ネットワーク・更新・検証をセットで見直す作業」として進めることが重要です。
コメント