結論から言うと、2026年4月24日に更新されたMicrosoft Defender External Attack Surface Management（Defender EASM）の確認ポイントは、「外部公開資産の発見」「棚卸し状態の分類」「リスク優先度の可視化」「他ツールへのデータ連携」「Security Copilot連携」「課金対象資産の管理」の6つです。Defender EASMは、社内から見えている資産ではなく、インターネット上から攻撃者に見えるデジタル攻撃面を継続的に発見・マッピングするサービスとして位置付けられています。(Microsoft Learn)
今回の更新は、単一の派手な新機能だけを見るよりも、セキュリティ管理者、IDチーム、コンプライアンス担当が「どの資産を正式管理対象にするか」「どのリスクから直すか」「既存のSIEMやレポート基盤にどう流すか」を見直すきっかけとして捉えるのが実務的です。特にグローバル企業、複数ブランドを持つ企業、買収・分社化を経験した組織では、シャドーITや放置ドメイン、期限切れ証明書、不要な公開ポートの洗い出しに直結します。
2026年4月更新で押さえるべき要点
Defender EASMの2026年4月更新ポイントは、機能名を覚えるだけでは不十分です。重要なのは、外部攻撃面管理を「年1回の棚卸し」ではなく、「変化し続ける公開資産の運用プロセス」として扱うことです。
| 確認ポイント | 何を見るべきか | 実務でのアクション |
|---|---|---|
| Discovery | ドメイン、ホスト、IPブロック、ASN、Whois情報などを起点に外部公開資産を発見 | 主要ドメインだけでなく、ブランド名、子会社、買収企業、旧サービス名もシード候補にする |
| Inventory | Approved Inventory、Dependency、Monitor Only、Candidate、Requires Investigationの分類 | CandidateとRequires Investigationを放置せず、所有部門と管理責任を確認する |
| Dashboards | 脆弱性、コンプライアンス、セキュリティ衛生、SSL、公開ポートなどを確認 | 高リスクCVE、期限切れ証明書、不要な公開サービスを優先してチケット化する |
| Data connections | Log AnalyticsやAzure Data Explorerへの連携 | Microsoft Sentinel、Power BI、KQL調査、独自レポートに流し込む |
| Security Copilot | 自然言語で攻撃面の要約、CVE影響、期限切れ証明書などを確認 | 初動調査や経営向け説明の下書きに使う。ただし最終判断は担当者が検証する |
| Billable assets | 課金対象となるApproved資産数 | Approved Inventoryに入れる前に、所有・必要性・重複を確認する |
Microsoft Learnでは、Defender EASMが既知の正当な資産をDiscovery seedsとして使い、関連インフラを再帰的に探索して攻撃面を構成すること、また発見対象にドメイン、IPアドレスブロック、ホスト、メール連絡先、ASN、Whois組織などが含まれることが説明されています。(Microsoft Learn)
Defender EASMは「外から見える自社」を管理するサービス
Defender EASMを理解するうえで最も重要なのは、従来の資産管理台帳や社内ネットワークスキャンとは視点が違うことです。Defender EASMは、ファイアウォールの内側ではなく、インターネット上に露出している資産を外部視点で発見し、攻撃者が見つけやすいリスクを洗い出します。(Microsoft Learn)
たとえば、社内CMDBには登録されていない古いキャンペーンサイト、退職した担当者名義のドメイン、買収企業の旧ブランドサイト、テスト用に公開されたサブドメインなどは、内部の管理台帳だけでは見落とされがちです。Defender EASMでは、こうした資産をDiscoveryによって候補として浮かび上がらせ、管理対象かどうかを分類していきます。
特に次のような組織では、Defender EASMの価値が出やすくなります。
- 複数の事業部や国・地域でWebサイトを個別に運用している
- M&Aにより、管理元が異なるドメインやクラウド資産が増えている
- マーケティング部門や外部ベンダーがWeb資産を短期間で作成する
- SSL証明書、DNS、公開ポート、脆弱性対応の責任分界が曖昧になっている
- 監査やコンプライアンス対応で、外部公開資産の根拠ある一覧が必要になる
Discoveryで最初に見直すべきは「シード設計」
Defender EASMのDiscoveryは、既知の資産をシードとして登録し、そこから関連するオンラインインフラを探索します。公式ドキュメントでは、シードとして組織名、ドメイン、IPブロック、ホスト、メール連絡先、ASN、Whois組織などを使えることが示されています。(Microsoft Learn)
実務では、最初に登録するシードの質が結果を左右します。example.co.jpのような代表ドメインだけを登録しても、海外ブランド、旧社名、キャンペーン用ドメイン、子会社の資産までは十分に拾えない可能性があります。
シード設計の具体例
| 組織の状況 | 追加すべきシード候補 |
|---|---|
| グローバル展開している | 国別ドメイン、現地法人名、海外ブランド名 |
| M&Aが多い | 買収企業の旧社名、旧ドメイン、旧Whois組織名 |
| BtoCサービスが多い | キャンペーンサイト、LP用ドメイン、ブランド別サブドメイン |
| クラウド移行中 | 旧オンプレ系ホスト名、クラウド移行前後のIPブロック |
| 外部委託が多い | ベンダー管理のホスト名、CDN、ホスティング事業者との関連資産 |
一方で、関連会社やフランチャイズなど、検出されても自社の直接管理対象ではない資産もあります。その場合は、Discoveryの除外設定を使い、将来のDiscovery runでInventoryに追加されないように整理することが重要です。(Microsoft Learn)
Inventoryの分類はセキュリティ運用の出発点
Defender EASMでは、発見された資産を状態別に分類します。主な状態には、Approved Inventory、Dependency、Monitor Only、Candidate、Requires Investigationがあります。Approved Inventoryは自社が責任を持つ攻撃面、Dependencyは第三者所有だが自社サービスを支える資産、Monitor Onlyは関連はあるが直接管理しない資産、CandidateやRequires Investigationは手動確認が必要な候補です。(Microsoft Learn)
ここで失敗しやすいのは、発見された資産を十分に確認せず、すべてApproved Inventoryに入れてしまうことです。Approved Inventoryはダッシュボードやスキャン、課金にも関わるため、「本当に自社の管理責任があるか」を確認してから分類する必要があります。
| 状態 | 判断基準 | 放置した場合のリスク |
|---|---|---|
| Approved Inventory | 自社が所有・管理し、対応責任を持つ | 課金対象や対応対象が増える。誤登録すると運用ノイズが増える |
| Dependency | CDN、ホスティング、外部ITプロバイダーなど自社サービスを支える | ベンダー責任のリスクを見落とす |
| Monitor Only | フランチャイズ、関連会社、参照用に監視したい資産 | 自社資産と混同し、レポートが不正確になる |
| Candidate | 関連性はあるが所有確認が必要 | シャドーITや放置資産を見逃す |
| Requires Investigation | 関連性の確度に基づき追加調査が必要 | 高リスク資産が未対応のまま残る |
特にCandidateとRequires Investigationは、週次の確認対象に入れるべきです。公式ドキュメントでも、CandidateはDiscovery時のみスキャンされ、所有している場合はApproved Inventoryに変更することが重要とされています。(Microsoft Learn)
ダッシュボードは「眺める画面」ではなく優先順位付けに使う
Defender EASMのダッシュボードは、攻撃面の概要を把握するだけでなく、対応優先度を決めるために使います。公式ドキュメントでは、Overview、Inventory changes、Attack surface summary、Security posture、GDPR compliance、OWASP Top 10、CWE Top 25、CISA known exploitsなどのダッシュボードが説明されています。(Microsoft Learn)
特にセキュリティ管理者が最初に見るべきなのは、次の項目です。
- 高リスクCVEに関連する公開資産
- 期限切れ、または期限が近いSSL証明書
- インターネットに公開された不要なポートやサービス
- 古い暗号方式やSHA-1証明書の利用
- 管理されていないクラウドホストや不明なホスティング先
- GDPRや個人情報入力フォームに関係する公開Webサイト
- CISA Known Exploited Vulnerabilitiesに該当する可能性のある資産
ダッシュボードの値はクリックして対象資産リストに絞り込めるため、「状況把握」から「修正対象リストの作成」までつなげやすいのがポイントです。チャートデータはCSVとしてエクスポートでき、Microsoft Excelではセル文字数制限により一部フィールドが正しく表示されない場合があるため、長いバナー情報などを扱う場合はCSV対応ツールや分析基盤での確認も検討します。(Microsoft Learn)
Data connectionsで既存のセキュリティ運用に組み込む
Defender EASMを単体画面だけで使うと、担当者が見に行かない限りリスク対応が進まないことがあります。運用に組み込むには、Data connectionsを使ってLog AnalyticsやAzure Data Explorerにデータを送る設計が有効です。公式ドキュメントでは、Defender EASMの資産データをLog AnalyticsとAzure Data Explorerへ送信できること、Log Analyticsではセキュリティインシデントの作成・強化、調査プレイブック、機械学習、修復アクションなどに活用できることが説明されています。(Microsoft Learn)
データ連携では、Asset dataとAttack surface insightsのどちらを使うかを決めます。Asset dataは資産単位の詳細メタデータを扱う用途に向き、Attack surface insightsはダッシュボード由来の実行可能なインサイトを既存レポートやワークフローに組み込む用途に向きます。どちらもApproved Inventory状態の資産が対象です。(Microsoft Learn)
連携先の選び方
| 目的 | 向いている連携先 | 例 |
|---|---|---|
| セキュリティアラートやインシデント対応に組み込む | Log Analytics、Microsoft Sentinel | 高リスクCVE検出時にインシデントを作成 |
| KQLで詳細分析したい | Azure Data Explorer | 特定ポート、証明書期限、クラウド事業者別に横断分析 |
| 経営・監査向けレポートを作る | Azure Data Explorer、Power BI | 国・ブランド・部門別の攻撃面推移を可視化 |
| 修復ワークフローを自動化したい | Log Analytics、SOAR連携 | 担当チームへチケット作成、期限切れ証明書を通知 |
注意点として、Data connectionsはプライベートリンクやプライベートネットワークをサポートしないと明記されています。閉域要件が厳しい組織では、データ経路、保存先リージョン、ログ保持、監査要件を事前に確認してから設計する必要があります。(Microsoft Learn)
Security Copilot連携は初動調査を速くする
Defender EASMのSecurity Copilot連携では、自然言語で外部攻撃面の要約、リスク、CVE影響、証明書やドメインの問題を確認できます。公式ドキュメントでは、外部攻撃面のスナップショット取得、資産リスクやCVEに基づく修復優先度付け、自然言語によるインサイト抽出、ラベルや外部ID、状態変更による攻撃面整理の迅速化が説明されています。(Microsoft Learn)
実務では、Security Copilotを「最終判断を任せるAI」ではなく、「調査の入口を短縮するアシスタント」として使うのが安全です。たとえば、次のような質問は実用的です。
- 自社の外部公開資産の概要を要約して
- 高優先度のAttack Surface Insightsを教えて
- 特定のCVEに影響を受ける資産を一覧化して
- 期限切れSSL証明書があるか確認して
- SHA-1証明書を使っている資産を探して
- 不要な公開ポートがある資産を調査して
Security Copilotのプロンプトでは、最初の質問で会社名を明確に指定し、CVE IDや資産名など具体的な条件を入れると精度を上げやすいとされています。(Microsoft Learn)
権限、テナント、データ保管も確認する
Defender EASMはセキュリティ部門だけで完結するツールではありません。Azureリソースとして作成・管理するため、権限設計とテナント設計が重要です。公式ドキュメントでは、OwnerまたはContributorはDefender EASMリソースやInventory assetの作成・削除・編集が可能で、Readerはデータ閲覧のみ可能とされています。また、Defender EASMはAzure Lighthouseを含むクロステナントリソースアクセスをサポートせず、対象リソースが存在するテナントへ直接認証してアクセスする必要があります。(Microsoft Learn)
権限設計では、次のように分けると運用しやすくなります。
| 担当 | 推奨される関与 | 注意点 |
|---|---|---|
| セキュリティ管理者 | Discovery、Inventory分類、リスク優先度付け | すべてをApprovedにせず、所有確認を徹底する |
| IDチーム | アクセス権、テナント、ロール管理 | ReaderとContributorの境界を明確にする |
| クラウド管理者 | Azureリソース、リージョン、ログ連携 | データ保存先と課金を確認する |
| コンプライアンス担当 | GDPR、PII、監査レポート確認 | 公開WebフォームやCookie、証明書状況を確認する |
| 各事業部 | 資産の所有確認、修復対応 | ドメインやサービスの廃止判断を行う |
データ保管の観点では、Microsoft Defender EASMにはグローバルデータと顧客固有データがあり、顧客が適用するラベルは顧客データとして扱われ、選択したリージョンに保存されます。IPアドレスのサインイン情報や削除後のデータ保持に関する説明もあるため、監査・規制対応が必要な組織では事前に確認しておくべきです。(Microsoft Learn)
課金対象資産はApproved Inventoryとセットで管理する
Defender EASMを試用・導入する際に見落としやすいのが課金対象資産です。公式ドキュメントでは、最初のDefender EASMリソース作成時に30日間の無料試用が付与され、試用終了後はbillable assetsの数に基づいて課金されると説明されています。課金対象は、Approved host:IP combinations、Approved domains、Approved IP addressesで、Approved Inventory状態にある場合のみbillable assetに分類されます。(Microsoft Learn)
つまり、Inventory分類の精度はコストにも直結します。不要な資産や自社管理ではない資産をApproved Inventoryに入れると、対応ノイズが増えるだけでなく、課金対象の把握も難しくなります。
課金管理で失敗しやすいポイント
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| Candidateを確認せずApprovedにする | 自社管理外の資産まで対応・課金対象になり得る | 所有部門、契約、DNS、Whois、証明書情報を確認する |
| 古いサブドメインを放置する | host:IP combinationとしてカウントやリスク対象になる可能性 | 廃止可否を確認し、DNSやホスティングを整理する |
| IPアドレスだけを見て判断する | ホストとの解決関係を見落とす | ホスト、IP、ドメインの関係で確認する |
| 試用期間中にBillable assetsを見ない | 本番移行後に想定外のコストになる | 試用中にBillable assetsダッシュボードを確認する |
Billable assetsの画面では、過去30日間の課金対象資産数や資産タイプ別の内訳を確認できます。ただし、直近数日分は処理が完了していない場合があるため、月次コストを見積もる際は数日のずれを考慮します。(Microsoft Learn)
初回導入時のおすすめ手順
Defender EASMを初めて使う場合は、いきなり全社展開するよりも、重要ブランドや主要ドメインから始めるのが現実的です。
| 手順 | 作業 | 完了基準 |
|---|---|---|
| 1 | Azure上でDefender EASMリソースを作成 | 必要なAzureサブスクリプションとContributor権限が用意されている |
| 2 | 代表ドメイン、組織名、IPブロック、ASNを整理 | 最初のDiscovery seeds候補が一覧化されている |
| 3 | 自動攻撃面を確認 | 既存のpreconfigured attack surfaceがあるか確認する |
| 4 | Discovery groupを作成 | 事業部、ブランド、子会社などの単位で管理できる |
| 5 | CandidateとRequires Investigationを確認 | 所有・依存・監視のみ・除外の判断ができている |
| 6 | ダッシュボードで高リスク項目を抽出 | CVE、SSL、公開ポート、GDPR関連の優先対応リストがある |
| 7 | Data connectionsやCSVで運用に接続 | SIEM、チケット、レポートのどれに流すか決まっている |
| 8 | Billable assetsを確認 | 試用後のコスト見積もりに使える数値が把握できている |
リソース作成にはAzureサブスクリプションまたは無料試用アカウント、Contributorロールが必要です。Azureポータルでは、リソースグループを作成し、その中にDefender EASMリソースを作成する流れになります。(Microsoft Learn)
運用で見るべきKPI
Defender EASMを導入した後は、単に「資産数が見えるようになった」で終わらせないことが重要です。次のKPIを定期的に見ると、攻撃面管理の改善度を説明しやすくなります。
- Approved Inventoryに分類された資産数
- Candidate、Requires Investigationの未処理件数
- 新規追加・削除された外部公開資産数
- 高優先度Attack Surface Insightsの未対応件数
- 期限切れSSL証明書数
- 90日以内に期限切れとなる証明書数
- 不要な公開ポートや危険なサービスの件数
- 高リスクCVEに影響する資産数
- 部門別、ブランド別、国別の未対応資産数
- Billable assetsの推移
特にInventory changesダッシュボードでは、資産の追加・削除を7日または30日の範囲で確認できます。外部公開資産は常に変化するため、週次で差分を見る運用にすると、新規公開されたシャドーITや廃止漏れを早期に見つけやすくなります。(Microsoft Learn)
まとめ：まずはApproved Inventoryの精度を上げる
Defender EASMの2026年4月更新ポイントを見るうえで、最初に取り組むべきことは、機能をすべて触ることではありません。まず、Discovery seedsを適切に設計し、発見された資産を正しくInventory分類し、Approved Inventoryの精度を上げることです。
そのうえで、ダッシュボードを使って高リスク項目を優先順位付けし、Data connectionsで既存のSIEMや分析基盤に連携し、Security Copilotで初動調査を短縮します。コンプライアンス担当はGDPR、PII、Cookie、証明書の観点を確認し、IDチームはロールとテナント境界を整理します。
次に取るべき行動は明確です。まず主要ドメインと組織名をシード候補として洗い出し、Defender EASMで発見されたCandidateとRequires Investigationを週次レビュー対象にしてください。そこから、期限切れ証明書、高リスクCVE、不要な公開ポートを優先して修復リスト化することで、外部攻撃面管理を実際のリスク低減につなげられます。
コメント