Microsoft defender for cloud 有効化

本記事について

Azure を利用するときにセキュリティ対策を行うにあたり、避けて通れないのが CSPM, XDR, CWPP を担う 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 連携をして使いたい機能は主に2つです。Defender for Cloud のライセンスの中に、MDEの利用権も付いているので使っている場合は活用しないと損になってしまいます。

1. サーバーエンドポイントセキュリティ(アンチマルウェア・EDR)

ガートナー社のレポート でも解説されているとおり、アンチマルウェアや EDR の分野において MDE は最高レベルの評価を受けています。Azure VM では VM を作成すると自動的にオンボードまで行ってくれるようになっており、こちらを利用しない手はありません。

なお、Azure VM に対するアンチマルウェア・EDRの詳細についてはこちらにまとめましたので、ご覧いただけますと幸いです。

2. 脅威と脆弱性の管理(TVM)

TVM は CVE をはじめとした OS やソフトウェア・ミドルウェアの脆弱性情報を基に、サーバーが脆弱性を持っていないかを自動的にスキャンして調査し、レポートしてくれる機能です。

たとえば、マイクロソフト社では全社の PC やサーバー、モバイル上の 10,000 を越えるアプリケーションに関して TVM を利用して脆弱性対応をしています。

本題の前にまず Azure AD と Azure Resource Manager と Microsoft 365 の関係の整理

Azure AD と Azure Resource Manager と Microsoft 365 の関係を理解しておかないと、Defender for Cloud と MDE の連携を理解することはできません。こちらの図にそれらの関係性をまとめてみます。

Microsoft defender for cloud 有効化

まず重要な点は、すべてのリソースが Azure Active Directory と紐づいているということがあります。Azure 上のリソース(Azure Resource Manager 上のリソース)はサブスクリプションや Tenant Root Group が信頼する Azure Active Directory に対して関係性を持ちます。一方、MDE を含む Microsoft 365 Defender をはじめとする Microsoft 365 系の各サービスもひとつの Azure AD との1:1の関係性を持っています。Microsoft 365 Defenderのインスタンスは各 Azure AD テナントにひとつだけ存在します。

もうひとつ重要なことは、Microsoft 365 Defender やその中に含まれる MDE は、Azure Resource Manager の外の世界にいるということです。言い換えると、Azure Resource Manager の世界では共通して使える Azure IAM/RBAC や Azure Resource Graph, Azure Explorer などの機能やツールが通用しない世界にいるということになります。これが後ほどアクセス権管理などを考えるうえで重要になります。

Defender for Cloud で、MDE 連携を有効化するとは?

Defender for Cloud では、各サブスクリプションごとに、MDE 連携の有効化ができるようになっています。

Microsoft defender for cloud 有効化

この連携とは何なのでしょうか?詳細は公式ドキュメントに譲りますが、大きく分けて2つの機能があります。

  1. VM の MDE へのオンボード - Log Analytics エージェントが入っていると、OS 組み込みのセンサーを有効化させたり(Windows Server 2019 / 2022 など)、Log Analytics エージェント自体が MDE のセンサーとして機能しだしたり(Windows Server 2012 R2 / 2016 など)、モジュールをインストールして有効化したり(Linux)します。

ひとつ注意点としては、Linux に対するオンボードでは EDR はデフォルトで有効化されますが、アンチマルウェア機能はデフォルトで無効になっていることがあります。そのため、構成プロファイルを変更するなどして有効化をしておく必要があります。

  1. MDE => Defender for Cloud の情報連携 - 各サブスクリプション上のマシンで MDE が動いている場合、発見した脆弱性情報や検知された脅威情報が Defender for Cloud のポータル上で見られるように連携されます。ただし、アラートについてはすべての情報が連携されるわけではないため、詳細な調査や自動対応については MDE ポータル を参照する必要があります。

サマリすると下記のような感じです。

Microsoft defender for cloud 有効化

どこの MDE にオンボードされるの?

上記の絵にもあるように、同じ Azure AD テナントにある MDE にオンボードされます。MDEは Azure AD テナントごとにひとつのインスタンスしかないため、もしクライアントPCやモバイルデバイス用に Microsoft Defender for Endpoint を利用している場合は、そのテナントにサーバーもオンボードされていきます。

Microsoft defender for cloud 有効化

まだ、クライアント PC でも MDE を利用したことがない場合は?

一方、もしまだ MDE を利用していない場合はどうなるのでしょうか?現時点では、Microsoft Defender for Cloud が MDE の環境を裏側で勝手に作成します。この際、ヨーロッパのデータセンターを利用するように構成されます。もしそれ以外のデータセンターを使いたいなど、自分で MDE の環境設定を行いたい場合は、Microsoft 365 側で使い始めることがおすすめです。

連携の結果

MDE のアラートや脆弱性情報

M365 側では下記のようにアンチウイルス・EDR のアラートや脆弱性情報が見えてきます。

Microsoft defender for cloud 有効化

Microsoft defender for cloud 有効化

MDE から Defender for Cloud へ連携されたアラート・脆弱性情報

Defender for Cloud 側でアラートの基本情報や脆弱性情報が見ることができます。

Microsoft defender for cloud 有効化

Microsoft defender for cloud 有効化

MDE を使っていくにあたりの注意点

さきほどご紹介したように、MDE は Azure Resource Manager の外にあります。そのため、Azure の常識が通用しなく、普段 Azure だけを触られる方は戸惑われるかもしれません。

1. そもそもコンソールが異なる

Defender for Cloud は、Azure Portal からアクセスしますが、MDE は、Microsoft 365 Security Center から操作します。なので、必要に応じて使い分けていく必要があります。

2. 管理者権限が違う

Defender for Cloud は Azure IAM ロールでのサブスクリプションの所有者権限やセキュリティ管理者権限で操作します。
https://docs.microsoft.com/ja-jp/azure/defender-for-cloud/permissions

一方、Microsoft 365 Defender に初回のアクセスをするには、Azure AD ロールのグローバル管理者かセキュリティ管理者の権限が必要です。特にセキュリティ管理者は同名のロールが Azure IAM ロールと Azure AD ロールにありかなりややこしいのですが、MDEはAzure Resource Manager外にあるので、Azure AD側での設定が必要になります。Azure Portal の Azure Active Directory の各ユーザー画面などから設定されます。

Microsoft defender for cloud 有効化

3. デバイスがサブスクリプションやリソースグループに紐づかない

MDE 上では、Azure サブスクリプションやリソースグループによる階層構造が消えています。そのため、誰がどのデバイスに対してアクセス権(Read / Write)を持つか、というのは、MDE側で設定を改めて行う必要があります。

Microsoft defender for cloud 有効化

ドメイン情報、ログインユーザー情報など、各 OS から取れる情報のみが入っています。

そのため、権限分掌をした管理を行っていくためには、デバイスグループやロールを Microsoft 365 Security Center 上で定義・割り当てをしていく必要があります。詳細はこちらをご参照ください。

Microsoft defender for cloud 有効化

4. Defender for Cloud には連携されない機能

アクセス権が異なるため、Azure Portal に完結するよう Defender for Cloud オンリーで運用したいという方もいらっしゃるかもしれません。ただ、すべての MDE の情報が Defender for Cloud へ連携されるわけではないので注意が必要です。たとえば、下記の作業は M365 Security Center 上で行う必要があります。

  • 自動調査と対処によるインシデント対応の設定と実行
  • Advanced Hunting によるログ検索(これは、Microsoft Sentinel とは連携可能)
  • Microsoft 365 E5 Security の別の製品との統合管理・調査

では、Defender for Cloud と MDE のポータルをどう使い分けるべきなのか?

一概には答えづらい問いですが、参考までに下記のような役割分担が考えられるのではないでしょうか?

クラウド管理者・サーバー管理者・システムオーナーなど => Defender for Cloud

Azureのサブスクリプションや、サーバー・システム単位でそのセキュリティ状態を管理しなければいけない方は、まず Defender for Cloud をメインのコンソールにするとよいのではないでしょうか?MDEからはアラートと脆弱性情報が連携され、それに加えて Azure 上での脅威情報や CSPM のコンプライアンス情報などをまとめて参照できます。

SOC・セキュリティ運用チーム => Azure Sentinel

SOC やセキュリティ運用チームの方は、Defender for Cloud も MDE (Microsoft 365 Defender) も両方とも Azure Sentinel に連携して、Sentinel をプライマリのコンソールにするのがおすすめです。

エンドポイントセキュリティ専任担当 => Microsoft 365 Defender (MDE)

エンドポイントセキュリティが専任の方は、Microsoft 365 Defenderのポータルを日々見ていくことになるかと思います。こちらでは個々のエンドポイントへの対応まで含めた管理を行うことができます。

最後に

本記事では、Defender for Cloud と MDE の連携について見てきました。Defender for Cloud を活用していくにあたり、この連携を正しく理解しておくことが重要です。本稿がその一助となれば幸いです。

*本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。