Microsoft 365 Defender XDRによる脅威対応

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Microsoft 365 Defender XDRによる脅威対応

はじめに

現代のサイバー脅威は巧妙化し、単一のセキュリティソリューションでは対応が困難です。Microsoft 365 Defenderは、エンドポイント、ID、メール＆コラボレーション、クラウドアプリケーションといった複数のドメインにわたる脅威情報を統合し、XDR (Extended Detection and Response) 機能を提供します。これにより、セキュリティチームは単一のプラットフォームで攻撃を検知、調査、自動修復し、組織全体のセキュリティ体制を強化できます。本記事では、Microsoft 365 Defender XDRのアーキテクチャ、設定手順、運用監視、セキュリティ、コスト、および導入時の落とし穴について解説します。

アーキテクチャ

Microsoft 365 Defenderは、以下の主要なDefender製品群を統合し、脅威インテリジェンスと自動化された対応を中央のポータルで提供します。

  • Microsoft Defender for Endpoint: デバイス（PC、サーバーなど）に対するEDR (Endpoint Detection and Response) 機能を提供。

  • Microsoft Defender for Identity: オンプレミスおよびクラウドのID（Azure Active Directory、現Entra ID）に対する脅威を検知。

  • Microsoft Defender for Office 365: メール、Teams、SharePoint Online、OneDrive for Businessにおけるフィッシング、マルウェア、スパムなどの脅威から保護。

  • Microsoft Defender for Cloud Apps: クラウドアプリケーション（SaaS）の利用状況を監視し、シャドーIT、データ漏洩、コンプライアンス違反を防止（CASB機能）。

これらのコンポーネントが収集した信号はMicrosoft 365 Defenderのバックエンドで相関分析され、インシデントとして集約されます。これにより、セキュリティチームは攻撃の全体像を把握し、より迅速かつ効果的な対応が可能になります。

flowchart TD
    subgraph Data Sources
        MDE["Microsoft Defender for Endpoint"] --> Collector["データコレクター"]
        MDI["Microsoft Defender for Identity"] --> Collector
        MDO["Microsoft Defender for Office 365"] --> Collector
        MDCA["Microsoft Defender for Cloud Apps"] --> Collector
    end

    subgraph Microsoft 365 Defender Service
        Collector -- |脅威信号の送信| --> CorrelationEngine["相関分析エンジン"]
        CorrelationEngine -- |インシデント生成| --> IncidentMgmt["インシデント管理"]
        CorrelationEngine -- |自動調査と修復の提案| --> AIR["自動調査と対応 (AIR)"]
        AIR -- |修復アクションの実行| --> DataSources
        AIR -- |修復結果を更新| --> IncidentMgmt
    end

    subgraph Security Operations
        SOC["セキュリティ運用センター"] --> M365DP["Microsoft 365 Defender ポータル"]
        M365DP -- |アラート/インシデントの確認| --> IncidentMgmt
        M365DP -- |カスタムハンティング/高度な検索| --> CorrelationEngine
        M365DP -- |承認/介入| --> AIR
        M365DP -- |SIEM/SOARへの連携| --> Sentinel["Microsoft Sentinel / 外部SOAR"]
        IncidentMgmt -- |ログ/アラート転送| --> Sentinel
    end

    style M365DP fill:#f9f,stroke:#333,stroke-width:2px
    style SOC fill:#fcf,stroke:#333,stroke-width:2px
    style Sentinel fill:#eef,stroke:#333,stroke-width:2px

設定手順

Microsoft 365 Defenderの導入は、各Defender製品の有効化とデバイス/サービスのオンボーディングから始まります。ここでは、Defender for Endpointへのデバイスオンボーディングを例に、PowerShellスクリプトを使用した設定手順を示します。

1. Defender for Endpointの有効化とスクリプトの取得

Microsoft 365 Defenderポータル（security.microsoft.com）にアクセスし、以下の手順でオンボーディングスクリプトを取得します。

  1. 左側のナビゲーションで「設定」 > 「エンドポイント」 > 「デバイス管理」 > 「オンボーディング」を選択します。

  2. 「デプロイ方法」ドロップダウンから「ローカルスクリプト」を選択し、OS（例: Windows 10以降）を指定します。

  3. 「オンボーディングパッケージのダウンロード」をクリックし、WindowsDefenderATPOnboardingPackage.zip をダウンロードします。

  4. ZIPファイル内のWindowsDefenderATPOnboardingScript.cmd と OnboardingScript.ps1 を解凍します。

2. PowerShellによるデバイスオンボーディング

ダウンロードした OnboardingScript.ps1 を実行することで、デバイスをDefender for Endpointにオンボーディングできます。このスクリプトは、手動実行、グループポリシー、SCCM、Microsoft Intuneなどを介して展開可能です。

以下のPowerShellコマンドは、管理者権限で実行する必要があります。

# PowerShellスクリプトの実行ポリシーを一時的に変更（必要であれば）

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

# ダウンロードしたオンボーディングスクリプトのパス

$scriptPath = "C:\temp\OnboardingScript.ps1" # ダウンロードしたスクリプトの実際のパスに置き換える

# スクリプトを実行してデバイスをDefender for Endpointにオンボーディング


# このスクリプトは、必要なレジストリ設定を行い、MDEサービスを開始します。


# 正常に実行されると、デバイスはポータルに表示されるようになります。

& $scriptPath

# オンボーディングが成功したかを確認するためのサービスステータスチェック（オプション）


# MdATPwdSvc サービスが実行中であることを確認

Get-Service -Name "Sense" | Select-Object Name, Status

# MDEポータルへのデバイスの報告状況は数時間かかる場合があります。


# （出力例）


# Name  Status


# ----  ------


# Sense Running

# 実行ポリシーを元に戻す（必要であれば）


# Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope Process -Force

この手順により、デバイスはDefender for Endpointに登録され、脅威の監視と検知が開始されます。他のDefender製品（Defender for Identity、Office 365、Cloud Apps）もそれぞれの管理ポータルから有効化し、必要な設定（コネクタの構成、ポリシーの適用など）を行います。

運用監視

Microsoft 365 Defender XDRの運用監視は、インシデント管理、高度なハンティング、自動化された調査と対応 (AIR) を中心に行われます。

1. インシデント管理

Microsoft 365 Defenderポータルは、様々な製品から収集されたアラートを自動的に相関分析し、インシデントとして統合します。これにより、SOC (Security Operations Center) チームは個々のアラートではなく、攻撃の全体像を把握し、優先度付けされたインシデントに対応できます。

2. 高度なハンティング (Advanced Hunting)

KQL (Kusto Query Language) を使用して、組織の生ログデータに対してカスタムクエリを実行し、未知の脅威や特定の攻撃パターンを能動的に探索できます。これはプロアクティブな脅威検知に不可欠な機能です。

3. 自動調査と対応 (AIR)

特定のアラートが発生した場合、Microsoft 365 Defenderは自動的に調査を開始し、関連するエンティティ（ファイル、プロセス、ユーザー、IPアドレスなど）を分析します。そして、疑わしい活動を隔離したり、ファイルを削除したりするなど、推奨される修復アクションを自動で実行、またはセキュリティアナリストに提示します。この機能はSOCチームの負担を大幅に軽減し、平均応答時間 (MTTR) を短縮します。

4. 可観測性、ログ、SLA、バックアップ/DR

  • 可観測性: Microsoft 365 Defenderポータル、Microsoft Sentinel (SIEM) との連携により、統合された可観測性を実現します。全てのセキュリティイベントは監査ログとして保持され、コンプライアンス要件に対応します。

  • ログ: Defender製品群は、詳細なセキュリティログを生成し、Microsoft 365 Defenderのデータバックエンドに保存されます。これらのログは高度なハンティングで利用できるほか、Microsoft Sentinelに連携して長期保存やカスタム分析が可能です。

  • SLA: Microsoft 365のサービスレベルアグリーメント (SLA) に準拠します。Defender機能の可用性とパフォーマンスはMicrosoftが管理します。

  • バックアップ/DR: Defenderが収集・分析するセキュリティデータはMicrosoftの管理下で冗長化され、災害復旧 (DR) 対策が講じられています。お客様側でのバックアップ作業は不要です。

セキュリティ

Microsoft 365 Defenderのセキュリティは、Entra ID (旧Azure Active Directory) を中心としたアクセス管理、ロールベースのアクセス制御 (RBAC)、条件付きアクセス (CA) によって強化されます。

1. アイデンティティと権限境界 (Entra ID)

  • Entra IDとの統合: Microsoft 365 Defenderポータルへのアクセスは、Entra IDのユーザーとグループに基づいて管理されます。

  • ロールの割り当て:

    • Entra IDの組み込みロール: 「セキュリティ管理者」ロールを持つユーザーは、Microsoft 365 Defenderのすべての設定と機能にアクセスできます。より限定的なアクセスには「セキュリティ閲覧者」などがあります。

    • Microsoft 365 Defender内のカスタムロール: よりきめ細やかな権限管理が必要な場合、Microsoft 365 Defenderポータル内でカスタムロールを作成し、特定の機能（例: ライブレスポンスの実行、設定の管理、アラートの調査のみ）に対するアクセス権を割り当てることができます。これにより、最小権限の原則が適用されます。

2. 条件付きアクセス (Conditional Access)

Entra IDの条件付きアクセスを利用して、Microsoft 365 Defenderポータルへのアクセスに追加のセキュリティ要件を課すことができます。

  • 多要素認証 (MFA) の強制: 未認証のデバイスや信頼できない場所からのアクセスに対してMFAを必須とする。

  • 管理デバイスからのアクセスのみ許可: 組織によって管理され、セキュリティポリシーに準拠しているデバイスからのみアクセスを許可する。

  • IPアドレスベースの制限: 特定のIP範囲（例: SOCのオフィスIP）からのアクセスのみを許可する。

# PowerShell (Microsoft Graph API) を使用した条件付きアクセスポリシーの作成例


# このスクリプトは概念実証であり、本番環境での利用には詳細なテストが必要です。


# 事前にMicrosoft.Graphモジュールをインストールし、必要な権限を付与したアプリ登録が必要です。


# （例：Policy.ReadWrite.ConditionalAccess権限）

# Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# ポリシーの構成

$policyDisplayName = "M365 Defender Portal Access Policy"
$appsToProtect = @("0000000c-0000-0000-c000-000000000000") # Microsoft 365 Defender (Microsoft Graph APIでのアプリケーションID)
$usersToInclude = @("All") # 全ユーザーを対象。特定のグループを指定することも可能。

$policy = @{
    displayName = $policyDisplayName
    state       = "enabled" # "enabled" | "disabled" | "enabledForReportingButNotEnforced"
    conditions  = @{
        users = @{
            includeUsers = $usersToInclude
        }
        applications = @{
            includeApplications = $appsToProtect
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa") # 多要素認証を必須とする

        # customAuthenticationFactors = @("customAuthFactorId") # カスタム認証要素の指定も可能


        # authenticationStrength = @{id = "cf25a83d-3617-4d7a-ad85-5f21d153835c"} # 認証強度も指定可能

    }
}

# 条件付きアクセスポリシーを作成

New-MgIdentityConditionalAccessPolicy -BodyParameter $policy | Format-List

# （出力例）


# DisplayName        : M365 Defender Portal Access Policy


# Id                 : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx


# State              : enabled


# Conditions         : @{users=Microsoft.Graph.PowerShell.Models.MicrosoftGraphConditionalAccessUsers;


#                      applications=Microsoft.Graph.PowerShell.Models.MicrosoftGraphConditionalAccessApplications;


#                      clientAppTypes=System.Collections.Generic.List`1[System.String];


#                      platforms=System.Collections.Generic.List`1[Microsoft.Graph.PowerShell.Models.MicrosoftGraphConditionalAccessDevicePlatform];


#                      locations=Microsoft.Graph.PowerShell.Models.MicrosoftGraphConditionalAccessLocations;


#                      signInRiskLevels=System.Collections.Generic.List`1[System.String];


#                      userRiskLevels=System.Collections.Generic.List`1[System.String];


#                      devices=Microsoft.Graph.PowerShell.Models.MicrosoftGraphConditionalAccessDevices}


# GrantControls      : @{operator=AND; builtInControls=System.Collections.Generic.List`1[System.String];


#                      authenticationStrengths=System.Collections.Generic.List`1[Microsoft.Graph.PowerShell.Models.MicrosoftGraphAuthenticationStrength];


#                      customAuthenticationFactors=System.Collections.Generic.List`1[System.String];


#                      # All other properties are null for brevity

このポリシーは、Microsoft 365 DefenderポータルへのアクセスにMFAを必須とし、セキュリティを強化します。

コスト

Microsoft 365 Defenderのコストは、主にMicrosoft 365のライセンスプランに依存します。

1. ライセンスプラン

最も包括的なMicrosoft 365 Defenderの機能を利用するには、通常、以下のライセンスが必要です。

  • Microsoft 365 E5 / A5: これには、Defender for Endpoint、Defender for Identity、Defender for Office 365 Plan 2、Defender for Cloud Appsが含まれています。組織全体の高度なセキュリティニーズに対応するための推奨ライセンスです。

  • Microsoft 365 E3 / A3 + アドオン: Microsoft 365 E3/A3ライセンスに、各Defender製品の単体プラン（例: Defender for Endpoint Plan 2、Defender for Office 365 Plan 2）をアドオンとして追加することも可能です。

各Defender製品にはPlan 1とPlan 2があり、Plan 2がより高度なXDR機能（自動調査と対応、高度なハンティングなど）を提供します。

2. コスト最適化

Microsoft 365 Defender自体には、追加の従量課金モデルはほとんどありません（一部のMicrosoft Sentinel連携時のデータ取り込み料を除く）。コスト最適化の主なポイントは以下の通りです。

  • 適切なライセンスの選択: 組織の規模、セキュリティ要件、既存のライセンス状況を評価し、過剰な機能を契約しないよう、最も費用対効果の高いライセンスプランを選択します。

  • 機能の活用: 導入したDefender製品の機能を最大限に活用することで、外部のサードパーティ製セキュリティソリューションへの依存を減らし、総所有コスト (TCO) を削減できます。

  • Microsoft Sentinelとの連携: 長期間のログ保存やSIEM/SOAR機能が必要な場合はMicrosoft Sentinelとの連携を検討しますが、Sentinelのデータ取り込みと保持には費用が発生するため、必要なログのみを取り込むように設計します。

落とし穴

Microsoft 365 Defender XDRを導入する際には、いくつかの一般的な落とし穴に注意が必要です。

1. アラート疲労 (Alert Fatigue)

初期設定では多くのアラートが生成され、セキュリティチームがすべてを調査しきれない「アラート疲労」に陥る可能性があります。

  • 対策: ポリシーや検出ルールのチューニングを継続的に行い、偽陽性 (False Positive) を削減します。AIR機能を活用し、自動化できる対応は任せることで、人間が介入すべき重要なアラートに集中できるようにします。

2. 他のセキュリティソリューションとの重複

既存のセキュリティソリューション（例: 別のEDR、CASB）と機能が重複する場合があります。

  • 対策: 導入前に既存ソリューションとの比較検討を行い、重複を最小限に抑えるか、Microsoft 365 Defenderへの移行計画を策定します。統合によるメリットを最大化するため、連携や役割分担を明確にします。

3. スキルとリソースの不足

XDRのような高度なセキュリティプラットフォームを運用するには、セキュリティ分析、インシデント対応、KQLによる高度なハンティングなどのスキルを持つ専門知識が必要です。

  • 対策: セキュリティチームへの適切なトレーニング、またはマネージドセキュリティサービスプロバイダ (MSSP) の利用を検討します。Microsoft Sentinelと連携する場合は、さらにSIEM/SOARの知識も求められます。

4. 適切なライセンスの理解不足

Microsoft 365 Defenderの機能は、ライセンスプランによって大きく異なります。必要な機能が利用できない、または過剰な機能を契約してしまうことがあります。

  • 対策: 導入前にMicrosoftのライセンスガイドを熟読し、必要な機能とそれに対応するライセンスプラン（例: M365 E5、Defender for Endpoint Plan 2など）を正確に理解します。

まとめ

Microsoft 365 Defender XDRは、エンドポイントからクラウドアプリケーションまでを包括的に保護し、統合された脅威検知、調査、自動対応を可能にする強力なセキュリティソリューションです。Entra IDベースの厳格なアクセス制御と条件付きアクセスを組み合わせることで、ポータルへのアクセス自体も強固に保護されます。適切なライセンスを選択し、機能のチューニング、そしてセキュリティチームのスキル向上に取り組むことで、組織は変化し続けるサイバー脅威に対して効果的に対抗し、セキュリティ運用を最適化することができます。計画的な導入と継続的な運用改善により、その真価を発揮するでしょう。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました