本記事について
本記事は2021年の記事ですが、一部2024年1月時点での情報に更新しています。
Azure を利用するときにセキュリティ対策を行うにあたり、避けて通れないのが CSPM (Cloud Security Posture Management), XDR (eXtended Detection and Response), CWP(P) (Cloud Workload Protection (Platform)) を担う Microsoft Defender for Cloud (旧 Azure Security Center / Azure Defender ) です。その Microsoft Defender for Cloud （以下、Defender for Cloud）の中でも最も難解なポイントが、サーバーに対する Microsoft Defender for Endpoint (MDE) の利用ではないでしょうか。本記事では、Defender for Cloud から見た MDE との対応関係やアーキテクチャのポイント、注意点などをまとめていきます。
なぜ MDE を利用すべきなのか？
Defender for Cloud から見たときに、サーバー保護について MDE 連携をして使いたい機能は主に２つです。Defender for Servers P1/P2 のライセンスの中に、MDE の利用権も付いているので使っている場合は活用しないと損になってしまいます。
1. サーバーエンドポイントセキュリティ (アンチマルウェア・EDR)
ガートナー社のレポートでも解説されているとおり、アンチマルウェアや EDR の分野において MDE は最高レベルの評価を受けています。Azure VM では VM を作成すると自動的にオンボードまで行ってくれるようになっており、こちらを利用しない手はありません。
なお、Azure VM に対するアンチマルウェア・EDRの詳細については下記記事にまとめています。
2. Microsoft Defender Vulnerability Management (MDVM) - 脆弱性管理
Microsoft Defender Vulnerability Management (MDVM) は CVE をはじめとした OS やソフトウェア・ミドルウェアの脆弱性情報を基に、サーバーが脆弱性を持っていないかを自動的にスキャンして調査し、レポートしてくれる機能です。
たとえば、マイクロソフト社では全社の PC やサーバー、モバイル上の 10,000 を越えるアプリケーションに関して MDVM を利用して脆弱性対応をしています。
こちらも Defender for Servers P1/P2 のライセンスの中に含まれています。 (P1/P2でそれぞれ利用できる機能が異なります。)
本題の前にまず Microsoft Entra ID と Azure Resource Manager と Microsoft XDR、Microsoft 365 の関係の整理
Microsoft Entra ID (Azure AD) と Azure Resource Manager と Microsoft Defender XDR、Microsoft 365 の関係を理解しておかないと、Defender for Cloud と MDE の連携を理解することはできません。
なお、Microsoft Defender for Endpoint (MDE) は、Microsoft Defender XDR (旧 Microsoft 365 Defender) の一部として機能しています。
こちらの図にそれらの関係性をまとめてみます。
まず重要な点は、すべてのリソースが Microsoft Entra ID (Azure AD) と紐づいているということがあります。Azure 上のリソース (Azure Resource Manager 上のリソース) はサブスクリプションや Tenant Root Management Group が信頼する Microsoft Entra ID (Azure AD) に対して関係性を持ちます。一方、MDE を含む Microsoft Defender XDR をはじめとする Microsoft 365 系の各サービスもひとつの Microsoft Entra ID (Azure AD) との1:1の関係性を持っています。Microsoft Defender XDR のインスタンスは各 Microsoft Entra ID (Azure AD)テナントにひとつだけ存在します。
もうひとつ重要なことは、Microsoft Defender XDR やその中に含まれる MDE は、Azure Resource Manager の外の世界にいるということです。言い換えると、Azure Resource Manager の世界では共通して使える Azure IAM/RBAC や Azure Resource Graph などの機能やツールが通用しない世界にいるということになります。これが後ほどアクセス権管理などを考えるうえで重要になります。
Defender for Cloud で、MDE 連携を有効化するとは？
Defender for Cloud では、各サブスクリプションごとに、MDE 連携の有効化ができるようになっています。
この連携とは何なのでしょうか？詳細は公式ドキュメントに譲りますが、大きく分けて２つの機能があります。
1. VM の MDE へのオンボード
オンボードでは、MDE 連携の対象になっている VM に対して、OS 組み込みのセンサーを有効化させたり (Windows Server 2019 / 2022) 、モジュールをインストールして有効化したり (Windows Server 2012 R2/2016, Linux）します。
ひとつ注意点としては、Linux に対するオンボードでは EDR はデフォルトで有効化されますが、アンチマルウェア機能はデフォルトで無効になっていることがあります。そのため、構成プロファイルを変更するなどして有効化をしておく必要があります。
2. MDE → Defender for Cloud の情報連携
各サブスクリプション上のマシンで MDE が動いている場合、発見した脆弱性情報や検知された脅威情報が Defender for Cloud のポータル上で見られるように連携されます。ただし、インシデント・アラートについてはすべての情報が連携されるわけではないため、詳細な調査や自動対応については Microsoft Defender XDR を参照する必要があります。
サマリすると下記のような感じです。
ここでポイントになるのが、Azure サブスクリプションと Microsoft Defender XDR が同一の Microsoft Entra ID に紐づいているということです。その点について以下で補足します。
どこの Microsoft Defender XDR (MDE) にオンボードされるの？
上記の絵にもあるように、Azure サブスクリプション上の仮想マシンは、同じ Microsoft Entra ID テナントにある Microsoft Defender XDR (MDE) にオンボードされます。Microsoft Defender XDR は Microsoft Entra ID テナントごとにひとつのインスタンスしかないため、もしクライアント PC やモバイルデバイス用に MDE を利用している場合は、そのテナントにサーバーもオンボードされていきます。
まだ、クライアント PC でも MDE を利用したことがない場合は？
一方、もしまだ MDE を利用していない場合はどうなるのでしょうか？ 現時点では、Microsoft Defender for Cloud が Microsoft Defender XDR (MDE) の環境を裏側で勝手に作成します。自分で MDE の環境設定を行いたい場合は、Microsoft Defender XDR 側で使い始めることがおすすめです。
連携の結果
Defender for Cloud と MDE を連携している場合のデータの見方について、Microsoft Defender XDR と Defender for Cloud でそれぞれ見ていきます。
Microsoft Defender XDR 上の MDE のアラートや脆弱性情報
Microsoft Defender XDR 側では下記のようにアンチウイルス・EDR のアラートや脆弱性情報が見えてきます。
MDE から Defender for Cloud へ連携されたアラート・脆弱性情報
Defender for Cloud 側でアラートの基本情報や脆弱性情報が見ることができます。
MDE を使っていくにあたりの注意点
さきほどご紹介したように、Microsoft Defender XDR (MDE) は Azure Resource Manager の外にあります。そのため、Azure の常識が通用しなく、普段 Azure だけを触られる方は戸惑われるかもしれません。
1. そもそもコンソールが異なる
Defender for Cloud は、Azure Portal からアクセスしますが、Microsoft Defender XDR (MDE) は、Microsoft Defender XDR Portal から操作します。なので、必要に応じて使い分けていく必要があります。
2. 管理者権限が違う
Defender for Cloud は Azure IAM ロールでのサブスクリプションの所有者権限やセキュリティ管理者権限で操作します。
一方、Microsoft Defender XDR に初回のアクセスをするには、Microsoft Entra ID ロールのグローバル管理者かセキュリティ管理者の権限が必要です。特にセキュリティ管理者は同名のロールが Azure IAM ロールと Microsoft Entra ID ロールにありかなりややこしいのですが、MDEはAzure Resource Manager 外にあるので、Microsoft Entra ID 側での設定が必要になります。Azure Portal や Entra 管理センター の Microsoft Entra ID の各ユーザー画面などから設定されます。
3. デバイスがサブスクリプションやリソースグループに紐づかない
MDE 上では、Azure サブスクリプションやリソースグループによる階層構造が消えています。そのため、誰がどのデバイスに対してアクセス権（Read / Write）を持つか、というのは、Microsoft Defender XDR 側で設定を改めて行う必要があります。
ドメイン情報、ログインユーザー情報など、各 OS から取れる情報のみが入っています。
そのため、権限分掌をした管理を行っていくためには、デバイスグループやロールを Microsoft Defender XDR 上で定義・割り当てをしていく必要があります。詳細はこちらをご参照ください。
4. Defender for Cloud には連携されない機能
アクセス権が異なるため、Azure Portal に完結するよう Defender for Cloud オンリーで運用したいという方もいらっしゃるかもしれません。ただ、すべての MDE の情報が Defender for Cloud へ連携されるわけではないので注意が必要です。たとえば、下記の作業は Microsoft Defender XDR 上で行う必要があります。
-
自動調査と対処によるインシデント対応の設定と実行
-
Advanced Hunting によるログ検索（これは、Microsoft Sentinel とは連携可能）
-
Microsoft 365 E5 Security の別の製品との統合管理・調査
では、Defender for Cloud と MDE のポータルをどう使い分けるべきなのか？
ここから、実際に Defender for Cloud と MDE を利用して監視を行う際にどうポータルを使い分けるべきか、私見ですが整理していきます。ですが、その前にマイクロソフトのセキュリティ監視サービス間の関係性を確認します。
セキュリティ監視サービス間の関係性の整理
2024年1月に Microsoft Defender XDR の中に Defender for Cloud のアラートも連携され、XDR としては一画面で統合して動作するようになったことで、より広範囲の監視が Microsoft Defender XDR で行えるようになりました。
これにより、Microsoft Sentinel と Defender for Cloud の連携も変わってきています。それも踏まえて、各サービスの連携を図式化してみます。
Defender for Cloud と Defender XDR の関係性は今まで見てきたとおりです。ここに Sentinel が入る場合、Sentinel は Defender XDR から基本的にはすべての Defender 関連の情報を受け取ります。Defender for Cloud 用の新しいコネクターが Sentinel のコンテンツハブでリリースされており、こちらを利用することになります。
管理者のペルソナと利用すべきダッシュボード
私見にはなりますが、各サービスが上記の関係性である中で、下記のような役割分担と使い分けが考えられます。
① クラウド管理者・サーバー管理者・システムオーナーなど → Defender for Cloud
Azure のサブスクリプションや、サーバー・システム単位でそのセキュリティ状態を管理しなければいけない方は、まず Defender for Cloud をメインのコンソールにするとよいのではないでしょうか？ Microsoft Defender XDR からはアラートと脆弱性情報が連携され、それに加えて Azure 上での脅威情報や CSPM のコンプライアンス情報などをまとめて参照できます。
② SOC・セキュリティ運用チーム → Microsoft Sentinel + Microsoft Defender XDR
SOC やセキュリティ運用チームの方は、Defender for Cloud も Microsoft Defender XDR も両方とも Microsoft Sentinel に連携して、Sentinel をプライマリのコンソールにするのがおすすめです。
Sentinel では Defender ファミリーの他、Azure の各セキュリティサービス (Azure WAF, Azure Firewall, Azure DDoS Protection など) のログやアラートも取りこめますし、サードパーティのセキュリティ製品 (SASE/SSE, オンプレミスのファイアウォール・IDS/IPS、AWS や GCP のセキュリティサービスなど) の情報を集約することもできます。
ただ、Microsoft Defender の監視の観点では、Microsoft Defender XDR Portal のほうが情報量が多くかつ調査や対処などのアクションを取ることも可能です。そのため、多くの場合では Defender for Cloud や Defender for Endpoint の分析や調査のために、Microsoft Defender XDR Portal を併用することになります。
③ エンドポイントセキュリティ専任担当 → Microsoft Defender XDR
エンドポイントセキュリティが専任の方は、Microsoft Defender XDR のポータルを日々見ていくことになるかと思います。サーバーとクライアントPCをまとめて見ていくダッシュボードとしては Microsoft Defender XDR Portal が最適です。
最後に
本記事では、Defender for Cloud と Defender for Endpoint の連携について見てきました。Defender for Cloud を活用していくにあたり、この連携を正しく理解しておくことが重要です。本稿がその一助となれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。