Microsoft Defender for EndpointでIPアドレスやURL/ドメインを制御したい場合は、インジケーター（Indicators）を使って、組織独自の脅威インテリジェンスに基づく「許可」「警告」「ブロック」を定義します。特に2026年5月時点で管理者が押さえるべきポイントは、Microsoft EdgeなどのMicrosoftブラウザーではSmartScreen、それ以外のブラウザーやアプリケーションではNetwork Protectionが制御の中心になることです。設定だけ作成しても、前提条件やブラウザー側の挙動を確認していないと「ブロックしたはずなのに効かない」「ログ上はConnectionSuccessに見える」といった誤解が起きやすくなります。(Microsoft Learn)
この記事では、Microsoft Defender for Endpointの「Create indicators for IPs and URLs/domains」に関する公式情報をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。
Microsoft DefenderのIP・URL/ドメイン インジケーターとは
Microsoft Defender for EndpointのIP・URL/ドメイン インジケーターは、特定のIPアドレス、URL、ドメインに対して、組織独自の判断でアクセス制御を行う機能です。
たとえば、次のような用途で使います。
| 利用シーン | 設定例 | 期待する効果 |
|---|---|---|
| フィッシングサイトをすぐに止めたい | 悪性URLをBlockにする | 端末からのアクセスを防ぐ |
| 業務上グレーなサービスを利用前に注意喚起したい | ドメインをWarnにする | ユーザーに警告し、必要に応じてバイパスさせる |
| 誤検知で業務サイトがブロックされた | 該当URLをAllowにする | ブロックポリシーより優先して許可する |
| SOCや外部TIから入手したIoCを反映したい | IPやドメインを期限付きでBlockにする | 一時的な封じ込めを迅速に行う |
公式ドキュメントでは、IP、URL、ドメインのインジケーターにより、組織独自の脅威インテリジェンスに基づいて許可・ブロック・警告ができると説明されています。また、Microsoftが管理する既定の脅威インテリジェンスに加え、Custom network indicatorsを構成することで追加の悪性IP/URLをブロックできます。(Microsoft Learn)
2026年5月時点の主な変更点
今回の確認で特に重要なのは、ネットワーク保護の要件がブラウザー種別ごとに整理された点です。
GitHub上のドキュメント履歴では、2026年5月21日に該当ドキュメントへ更新があり、従来の「URL/IPの許可・ブロックにはNetwork Protectionのブロックモードが必要」という説明に対して、Microsoftブラウザーとその他のブラウザー・アプリケーションを分ける記述が追加されています。(GitHub)
整理すると、次のようになります。
| 対象 | 制御に使われる主な仕組み | 管理者が確認すべきこと |
|---|---|---|
| Microsoft EdgeなどのMicrosoftブラウザー | SmartScreen設定 | SmartScreenが無効化されていないか |
| Chrome、Firefoxなどの非Microsoftブラウザー | Network Protection | Network ProtectionがBlock modeで有効か |
| ブラウザー以外のプロセス | Network Protection | アプリ通信も対象にするならBlock modeが必須 |
| HTTPSのFQDNブロック | TLSハンドシェイク情報 | QUICやEncrypted Client Helloの影響を確認する |
この変更は、単なる表現変更ではありません。現場では「EdgeではブロックされるがChromeでは効かない」「アプリケーション通信だけ検知できない」といった問い合わせにつながるため、展開前チェックの観点が変わります。
なお、Microsoft Learnページ上のLast updated表示は2025-10-20のまま確認される場合があります。一方で、GitHub上の公開ドキュメント履歴には2026年5月の更新が残っているため、運用ドキュメントでは「Microsoftブラウザーと非Microsoftブラウザーで適用経路が異なる」と明記しておくのが安全です。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
IP・URL/ドメイン インジケーターの影響は、セキュリティ管理者だけに閉じません。ブラウザー設定、端末管理、アプリケーション通信、SOC運用、API連携まで関係します。
| 役割 | 確認すべきポイント | 放置した場合のリスク |
|---|---|---|
| Microsoft Defender管理者 | Custom network indicators、SmartScreen、Network Protectionの有効化 | インジケーターを作成しても一部端末で効かない |
| Intune・GPO管理者 | Network ProtectionのBlock mode展開、ブラウザー設定 | Chrome/Firefoxでブロックが効かない |
| SOC担当者 | AlertEvents、DeviceEvents、NetworkConnectionEventsの見方 | ブロック済み通信を成功通信と誤認する |
| 開発者・自動化担当 | Indicator APIの制限、権限、レート制限 | TI連携や自動登録が失敗する |
| 業務部門管理者 | Allow/Warn/Blockの業務影響 | 業務サイトの停止や不要な例外許可が起きる |
特に管理者は、インジケーターを「登録すれば即ブロックできるリスト」と考えないことが重要です。実際には、端末側の保護機能、ブラウザーの通信方式、ポリシー優先順位、反映遅延が絡みます。
利用前に確認すべき前提条件
IP、URL、ドメインのインジケーターを作成する前に、少なくとも次の条件を確認してください。
| 確認項目 | 必要な状態 |
|---|---|
| ライセンス・対象サービス | Microsoft Defender for Endpoint Plan 1またはPlan 2 |
| Microsoft Defender Antivirus | Active modeで構成 |
| Behavior Monitoring | 有効 |
| Cloud-based protection | 有効 |
| Cloud Protection network connectivity | 通信可能 |
| マルウェア対策クライアント | 4.18.1906.x以降 |
| Custom network indicators | Microsoft Defenderポータルで有効化 |
| 非Microsoftブラウザー・アプリ制御 | Network ProtectionをBlock modeで有効化 |
公式情報では、Microsoftブラウザーへの統合はSmartScreen設定で制御され、その他のブラウザーやアプリケーションではMicrosoft Defender AntivirusのActive mode、Behavior Monitoring、Cloud-based protection、クラウド接続、一定以上のクライアントバージョンが必要とされています。さらに、IPアドレスやURLのブロックを開始するには、Microsoft DefenderポータルのAdvanced featuresでCustom network indicatorsを有効にする必要があります。(Microsoft Learn)
Custom network indicatorsを有効にする場所
管理画面では、次の場所を確認します。
Microsoft Defender portal
設定
Endpoints
General
Advanced features
Custom network indicatorsここがオフのままだと、IPやURLのインジケーターを作成しても、期待どおりにネットワークブロックが適用されません。
Network ProtectionはAuditではなくBlock modeが必要
Network ProtectionはAudit modeでも利用できますが、カスタムインジケーターやWebコンテンツフィルタリングのブロックを実際に適用するにはBlock modeが必要です。公式ドキュメントでも、影響を評価したい場合はAudit modeを使える一方、ブロックを強制するにはBlock modeが必要とされています。(Microsoft Learn)
展開時は、最初から全社Block modeにするのではなく、次の順番がおすすめです。
| フェーズ | 推奨設定 | 目的 |
|---|---|---|
| 検証 | Audit mode | どの通信がブロック対象になるか確認 |
| パイロット | 一部デバイスでBlock mode | 業務影響と通知内容を確認 |
| 段階展開 | 部門・端末グループ単位でBlock mode | 誤ブロックを抑えながら拡大 |
| 本番運用 | 全対象端末でBlock mode | SOC運用・例外申請フローと連動 |
対応OSと端末範囲
公式ドキュメントでは、Windows 11、Windows 10 version 1709以降、Windows Server 2025/2022/2019、モダン統合ソリューションを実行するWindows Server 2016およびWindows Server 2012 R2、Azure Stack HCI OS version 23H2以降、macOS、Linux、iOS/iPadOS、Androidが対象として示されています。(Microsoft Learn)
ただし、「対象OSに含まれる」ことと「同じ挙動でブロックできる」ことは同じではありません。モバイル、macOS、Linuxでは、管理方式やNetwork Protectionの展開条件がWindowsと異なる場合があります。クロスプラットフォーム環境では、まず対象端末を次のように分類してください。
| 端末種別 | 確認ポイント |
|---|---|
| Windowsクライアント | AV Active mode、Network Protection、SmartScreen |
| Windows Server | モダン統合ソリューションの導入状態 |
| macOS/Linux | Microsoft Defender for Endpointのネットワーク保護対応状況 |
| iOS/iPadOS/Android | Microsoft Defenderアプリ側のサポート範囲 |
| BYOD・未管理端末 | MDE管理対象外であれば期待どおり制御できない |
IP・URL・ドメインごとの制限事項
インジケーターは便利ですが、ファイアウォールやプロキシのURLフィルターと同じ感覚で使うと失敗します。特にIP範囲、HTTPSパス、非Microsoftブラウザーの挙動に注意が必要です。
| 対象 | できること | 注意点 |
|---|---|---|
| 外部IPアドレス | 単一IPをブロック・許可 | 内部IPは作成不可 |
| IP範囲 | 原則不可 | CIDRブロックやIPレンジは未サポート |
| HTTP URL | フルパスを含めてブロック可能 | 任意のブラウザー・プロセスで対象 |
| HTTPS FQDN | 非Microsoftブラウザーでもブロック可能 | QUICとEncrypted Client Helloの影響に注意 |
| HTTPSフルURLパス | Microsoft Edgeでのみブロック可能 | Chrome/FirefoxではFQDN単位で考える |
| HTTP/2 connection coalescing経由のFQDN | Microsoft Edgeでのみブロック可能 | 非Microsoftブラウザーでは期待どおりにならない場合がある |
公式ドキュメントでは、インジケーターリストに追加できるのは外部IPのみで、内部IPには作成できないとされています。また、カスタムインジケーターでは単一IPのみがサポートされ、CIDRブロックやIP範囲はサポートされません。非MicrosoftブラウザーでFQDNをブロックするには、QUICとEncrypted Client Helloを無効にする必要がある点も重要です。(Microsoft Learn)
失敗しやすい例
たとえば、次のような設定は期待どおりに動かない可能性があります。
| 設定例 | 問題点 | 代替案 |
|---|---|---|
192.168.1.10をブロック | 内部IPは対象外 | ファイアウォール、ネットワーク制御、EDRの別機能を検討 |
203.0.113.0/24を登録 | CIDR未サポート | 必要な単一IPを個別登録 |
Chromeでhttps://example.com/pathだけブロック | HTTPSフルパス制御はMicrosoft Edgeのみ | FQDN単位での制御、またはプロキシ製品と併用 |
| ChromeでFQDNをブロックしたのに通る | QUIC/ECHの影響 | ブラウザー管理ポリシーでQUIC/ECHを制御 |
ポリシーの優先順位を理解する
Microsoft Defenderのインジケーター運用で最も危険なのは、意図しないAllowです。
IP、URL、ドメインの競合処理では、同じ対象に複数のアクションが設定された場合、Allow > Warn > Blockの順に優先されます。つまり、あるドメインにBlockを設定していても、同じ対象にAllowが存在すればAllowが勝ちます。(Microsoft Learn)
| 競合例 | 結果 |
|---|---|
| 同じドメインにAllowとBlockがある | Allow |
| 同じドメインにWarnとBlockがある | Warn |
| より長いURLパスのポリシーがある | 長いパスのポリシーが優先 |
| Defender for EndpointでAllow、Defender AntivirusでBlock | Allow |
Web protection全体でも、Custom indicatorsはWeb threatsやWeb Content Filteringより上位に位置づけられ、Allow indicatorはブロックの例外として機能します。(Microsoft Learn)
Allowは「一時的な例外」として扱う
Allowは業務復旧に役立ちますが、広すぎるAllowはセキュリティホールになります。
たとえば、誤検知でhttps://example.com/loginだけを許可したいのに、example.com全体をAllowにすると、同じドメイン配下の別パスまで許可される可能性があります。Allowを作成する場合は、次の情報を必ず残してください。
| 記録項目 | 例 |
|---|---|
| 作成理由 | 業務SaaSの誤検知回避 |
| 承認者 | 情報システム部門責任者 |
| 対象範囲 | 特定のマシングループのみ |
| 有効期限 | 7日後に自動失効 |
| 再評価日 | Microsoftへの誤検知報告後に見直し |
Defender for Cloud Apps連携時の注意点
Microsoft Defender for EndpointとDefender for Cloud Appsを連携している場合、未承認のクラウドアプリに対してDefender for Endpoint側にブロックインジケーターが作成されます。アプリがモニターモードの場合は、関連URLに対してWarnインジケーターが作成されます。一方、承認済みアプリに対してAllowインジケーターが自動作成されるわけではありません。(Microsoft Learn)
このため、Cloud Apps側の「未承認」「モニター」設定を変更した場合は、Defender for Endpoint側のインジケーター運用にも影響が出ます。
確認すべきポイントは次のとおりです。
| 確認項目 | 理由 |
|---|---|
| 未承認アプリの一覧 | 意図しないブロックが作成される可能性がある |
| モニターモードのアプリ | Warnとして表示され、ユーザーがバイパスできる場合がある |
| 手動Allowの有無 | Cloud Apps由来のBlockよりAllowが優先される可能性がある |
| 例外申請フロー | 業務SaaSの停止を避けるため |
インジケーターの作成手順
Microsoft Defenderポータルから作成する場合の流れはシンプルです。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Defenderポータルを開く |
| 2 | Settings > Endpoints > Indicatorsを選択 |
| 3 | IP addressesまたはURLs/Domainsタブを選択 |
| 4 | Add itemを選択 |
| 5 | Indicator、Action、Scopeを入力 |
| 6 | Summaryで内容を確認してSave |
公式ドキュメントでも、Settings > Endpoints > IndicatorsからIP addressesまたはURLs/Domainsタブを選び、Add itemでインジケーター、アクション、スコープを指定して保存する手順が示されています。(Microsoft Learn)
入力時に決めるべき項目
| 項目 | 実務上の判断基準 |
|---|---|
| Indicator | IP、URL、ドメインのどれで制御するか |
| Action | Allow、Warn、Blockのどれにするか |
| Scope | 全社か、特定マシングループか |
| Expiration | 一時対応なら必ず期限を設定 |
| Description | なぜ作ったか、誰が承認したかを記録 |
| Severity | アラート化する場合の優先度を整理 |
インジケーターは「登録した人しか意図が分からない状態」にしないことが大切です。半年後に見返して判断できるよう、説明欄には最低限、作成理由、チケット番号、承認者、期限を入れておきましょう。
反映時間と確認方法
URLまたはIPアドレスのブロックは、ポリシー作成後すぐに全端末へ反映されるとは限りません。公式ドキュメントでは、デバイスでブロックされるまで最大48時間かかる場合があり、多くの場合は2時間以内に有効になるとされています。(Microsoft Learn)
展開直後に「効かない」と判断する前に、次の順番で確認してください。
| 確認項目 | 見るべき内容 |
|---|---|
| ポータル設定 | Custom network indicatorsが有効か |
| 端末ポリシー | Network ProtectionがBlock modeか |
| ブラウザー | Edgeか、Chrome/Firefoxか |
| 通信方式 | QUICやECHが有効ではないか |
| スコープ | 対象端末がマシングループに含まれているか |
| 反映時間 | 最大48時間を考慮しているか |
| ログ | DeviceEvents、AlertEvents、NetworkConnectionEventsを確認 |
ログ確認で誤解しやすいConnectionSuccess
Network Protectionでは、TCP/IPハンドシェイクやTLSハンドシェイクの後に許可・ブロック判断が行われます。そのため、実際にはブロックされていても、Microsoft DefenderポータルのNetworkConnectionEventsにConnectionSuccessが表示されることがあります。これはTCP層のイベントであり、Network Protectionの最終判断そのものではありません。(Microsoft Learn)
運用上は、NetworkConnectionEventsだけで判断せず、AlertEventsやDeviceEventsも合わせて確認してください。
Network Protectionの監査・ブロックイベントは、Advanced HuntingでExploitGuardNetworkProtectionAuditedやExploitGuardNetworkProtectionBlockedとして確認できます。また、ResponseCategoryを見ることで、Custom indicators、Web content filtering、Defender for Cloud Apps、Web threatsなど、どの機能がブロックに関与したかを切り分けられます。(Microsoft Learn)
確認用クエリ例
DeviceEvents
| where ActionType in ("ExploitGuardNetworkProtectionAudited", "ExploitGuardNetworkProtectionBlocked")
| extend ParsedFields = parse_json(AdditionalFields)
| project Timestamp, DeviceName, ActionType, RemoteUrl, InitiatingProcessFileName,
ResponseCategory = tostring(ParsedFields.ResponseCategory),
DisplayName = tostring(ParsedFields.DisplayName)
| sort by Timestamp descCustom indicatorsによるブロックを確認したい場合は、ResponseCategoryがCustomBlockListになっているかを確認します。
DeviceEvents
| where ActionType == "ExploitGuardNetworkProtectionBlocked"
| extend ParsedFields = parse_json(AdditionalFields)
| where tostring(ParsedFields.ResponseCategory) == "CustomBlockList"
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName, AdditionalFields
| sort by Timestamp descWarnモードを使うべきケース
Warnは、完全に止めるほどではないが、ユーザーに注意喚起したい場合に使います。公式ドキュメントでは、Warnモードでバイパス機能やリダイレクトURLを構成できるとされています。Microsoft Edgeの許可ボタン、非Microsoftブラウザーのトースト通知、バイパス期間、リダイレクトURLなどが制御対象です。(Microsoft Learn)
Warnが向いているのは、次のようなケースです。
| ケース | Warnが向いている理由 |
|---|---|
| 新しいSaaSの試験利用 | 完全ブロックせず利用実態を見られる |
| リスクはあるが業務例外が多いサイト | ユーザー判断とログ収集を両立できる |
| 教育目的のセキュリティ通知 | アクセス前に注意喚起できる |
| 段階的なブロック移行 | Warn期間を経てBlockへ移行できる |
ただし、Warnはユーザーがバイパスできる場合があります。マルウェア配布サイトやフィッシングサイトなど、明確な悪性IoCにはBlockを使うべきです。
CSVインポートとAPI連携時の注意点
インジケーターはポータルから手動作成するだけでなく、CSVインポートやAPIで管理できます。大量のIoCを扱うSOCや外部Threat Intelligenceと連携する場合は、こちらが現実的です。
CSVインポートの注意点
公式ドキュメントでは、CSVファイルでインジケーター属性、アクション、その他詳細を定義してアップロードできるとされています。ただし、1バッチでアップロードできるインジケーターは500個までです。また、CIDR表記はサポートされず、ネットワークインジケーターではBlockAndRemediateアクションはサポートされません。(Microsoft Learn)
| 注意点 | 実務対応 |
|---|---|
| 1回500件まで | 連番ファイルに分割する |
| CIDR未サポート | 単一IPへ展開して登録する |
BlockAndRemediate非対応 | ネットワーク系はBlock/Warn/Allowed等で設計する |
| expirationTimeの形式 | YYYY-MM-DDTHH:MM:SS.0Zで統一する |
| categoryの表記 | ポータルで受け付けるカテゴリ名に合わせる |
Indicator APIの注意点
開発者がAPIで自動登録する場合は、POST https://api.security.microsoft.com/api/indicatorsを使用します。APIではindicatorValue、indicatorType、actionなどを指定します。indicatorTypeにはIpAddress、DomainName、Urlなどが含まれ、actionにはAlert、Warn、Block、Audit、AlertAndBlock、Allowedなどがあります。 (Microsoft Learn)
APIには、100 calls/min、1,500 calls/hourのレート制限があり、テナントあたり15,000個のアクティブインジケーター上限があります。権限はApplicationの場合Ti.ReadWrite.All、委任の場合Ti.ReadWriteが必要です。(Microsoft Learn)
| 開発者が確認すべき項目 | 理由 |
|---|---|
| レート制限 | TIフィードを一括投入すると失敗する可能性がある |
| 15,000件上限 | 古いIoCを自動失効・削除する設計が必要 |
| 権限 | 最小権限でアプリ登録する |
| expirationTime | 一時IoCを残し続けない |
| rbacGroupNames | 対象デバイスグループを誤らない |
| 400 Bad Request | JSON形式、enum値、必須項目を確認する |
移行・展開時の実務チェックリスト
既存環境に導入する場合、または旧運用から見直す場合は、次の順番で確認すると失敗を減らせます。
| 順番 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 既存インジケーターの棚卸し | Allowが広すぎないか、期限切れが残っていないか |
| 2 | 端末グループの整理 | 全社適用か、部門別適用か |
| 3 | SmartScreen設定確認 | Edgeで無効化されていないか |
| 4 | Network Protection確認 | 非Microsoftブラウザー向けにBlock modeか |
| 5 | ブラウザー設定確認 | QUIC/ECHを管理できているか |
| 6 | Audit modeで影響確認 | 業務サイトが巻き込まれないか |
| 7 | パイロット展開 | SOC、ヘルプデスク、業務部門で確認 |
| 8 | 本番展開 | 反映時間と問い合わせ対応を周知 |
| 9 | ログ監視 | Advanced Huntingでブロック理由を確認 |
| 10 | 定期レビュー | 古いIoC、不要なAllow、重複ルールを削除 |
特に見落としやすいのは、ブラウザー側のQUICとEncrypted Client Helloです。非MicrosoftブラウザーでHTTPS FQDNをブロックしたい場合、TLSハンドシェイク内の情報をNetwork Protectionが参照できる必要があります。QUICやECHが有効なままだと、想定した粒度で制御できない場合があります。(Microsoft Learn)
管理者が避けるべき運用パターン
全社Blockをいきなり適用する
脅威対応で急ぐ場面でも、業務サイトを巻き込むと復旧対応に追われます。重大なIoCは全社Blockでよい場合がありますが、まず影響範囲を確認し、期限付きで登録しましょう。
Allowを恒久的に残す
AllowはBlockより優先されるため、例外が増えるほど防御が弱くなります。Allowには必ず有効期限とレビュー日を設定してください。
ドメイン単位で雑に登録する
example.comをAllowまたはBlockにすると、サブドメインまで影響する場合があります。業務影響を抑えたい場合は、URLパスで制御できるか、Edge利用を前提にできるかを検討します。
ログのConnectionSuccessだけで判断する
Network Protectionでは、ブロック済みでもConnectionSuccessが見えることがあります。必ずAlertEvents、DeviceEvents、ResponseCategoryを合わせて確認してください。
ファイアウォールの代替として過信する
Microsoft Defenderのインジケーターはエンドポイント側の保護として強力ですが、ネットワーク境界のファイアウォール、プロキシ、DNSセキュリティを完全に置き換えるものではありません。端末が社外にある場合にも効く補完策として設計するのが現実的です。
すぐに取るべき対応
Microsoft Defender for EndpointでIP・URL/ドメイン インジケーターを使うなら、最初に確認すべきことは明確です。
まず、Microsoft DefenderポータルでCustom network indicatorsが有効か確認します。次に、Microsoft Edge向けにはSmartScreen、ChromeやFirefox、ブラウザー外通信向けにはNetwork ProtectionのBlock modeを確認します。そのうえで、既存のAllow/Warn/Blockを棚卸しし、特にAllowが広すぎないか、期限切れのIoCが残っていないかを見直してください。
新規展開では、Audit modeで影響を確認し、パイロット端末でBlock modeを試してから段階展開するのが安全です。SOCや開発チームがAPI連携する場合は、15,000件上限、レート制限、CIDR未サポート、ネットワークインジケーターでBlockAndRemediateが使えない点を設計に入れておきましょう。
IP・URL/ドメイン インジケーターは、正しく使えばインシデント対応の初動を速くし、社外端末も含めたWeb脅威対策を強化できます。一方で、前提条件と優先順位を誤ると、ブロック漏れや業務影響につながります。まずは「SmartScreen」「Network Protection」「Custom network indicators」「Allowの棚卸し」の4点から確認するのが、管理者にとって最も効果的な第一歩です。
コメント