1. はじめに
Azure サービスタグに Microsoft Defender for Endpoint 通信専用のタグ MicrosoftDefenderForEndpoint がついにサポートされました！
新しい MDE エンジンを用いることで、MDEサービスタグ、もしくは簡略化されたドメイン *.endpoint.security.microsoft.com だけで通信許可設計が出来るようになります。
この記事では、Azure Firewall など、Azure から外部接続する際の通信要件を定義して、設計されている方向けに紹介します。
2. これまでの背景
このタグ自体、昔から存在していたのですが、長らくDocs 上では開発中で使用不可との記載が出ていました。
(以下、過去掲載されていたドキュメント画面の抜粋)
このため、今までは MDE 通信要件のドキュメントに掲載されている統合 URL のスレッドシートを開き、OS 要件などを確認して許可リストを登録する必要がありました。
以下画面を見て頂いてお分かりの通り、ほとんどの Microsoft ドメイン (例：www.microsoft.com や ctl.microsoft.com、*.security.microsoft.com) を通す必要があり、Proxy 通信許可解放には地獄の作業が行われていました。
今現在、本ドキュメントが更新されており、「デバイスを合理化された接続でオンボードし、要件を満たす」ことで、通信要件が整理されて、本タグで統合されたドメイン、IPアドレスによる通信でまとめられるように MDE 側が更新されています。
3. 本タグを利用するための条件とは
詳しい要件は以下 Docs に掲載されていますのでご確認下さい。
新しい MDE の Engine Version によるサポートのため、対応するバージョンが必要となります。
- Microsoft Defender ウイルス対策のバージョン (Windows)
| 要件 | バージョン |
|---|---|
| マルウェア対策クライアント | 4.18.2211.5 |
| エンジン | 1.1.19900.2 |
| ウイルス対策(セキュリティインテリジェンス) | 1.391.345.0 |
Windows MDAV / MDE のバージョンは、MDE Client Analyzer を実行することで確認することが出来ます。
- Microsoft Defender ウイルス対策のバージョン (Linux)
| 要件 | バージョン |
|---|---|
| MDE 製品バージョン |
101.24022.* 以上 |
MDE 製品バージョンは mdatp health コマンドなどで確認することが出来ます。
4. 試してみる
Azure Vnet に構築した Windows 2022 Server, Redhat Enterprise Linux から、Azure Firewall の許可設定に MDE 通信タグを入れて試してみました。
4.1 Azure Firewall アウトバウンドの設定
Azure Firewall では、ネットワークルールのサービスタグで MicrosoftDefenderForEndpoint と OneDsCollector のタグを許可しています。Docs に記載がある通り、現 MDE では 2 つのタグを利用して外部接続が行われるとのことです。
| タグ名 | 説明 |
|---|---|
| MicrosoftDefenderForEndpoint | クラウド配信の保護、マルウェア サンプル送信ストレージ、自動 IR サンプル ストレージ、Defender for Endpoint コマンドと制御 |
| OneDsCollector | Defender for Endpoint のサイバーデータと診断データ |
4.2 Windows 2022 Server の場合
Windows Server 2019 以降からは MDE センサーが同梱されているため、Defender for Servers P1 を有効化することによって、機能が有効化され、Azure VM の拡張機能に MDE.Windows が展開されることを確認出来ました。
テストアラートやデバイス情報などを Defender XDR 側で確認することが出来ます。
4.2 Redhat Enterprise Linux の場合
最初にテストしたところ、MDE.Linux のオンボーディングに失敗するエラーが発生しました。タグ MicrosoftDefenderForEndpoint や OneDsCollector は MDE センサーが導入されて以後の通信要件であり、MDE そのもののオンボーディングのための通信要件が別であることが原因でした。
このため、MDE インストール用に以下を通信要件に加えています。
| 要件 | 許可ルール | ポート | 許可設定 |
|---|---|---|---|
| Azure RHEL レポジトリ | Network Rule | https |
rhui-1.microsoft.comrhui-2.microsoft.comrhui-3.microsoft.com
|
| MDE for Linux 導入用 | Network Rule | https | pakage.microsoft.com |
MDE for Linux の場合、MDE と連動する様々な外部パッケージが存在するため、Linux が Azure RHEL 以外の場合はそれぞれのレポジトリを通信要件に加えるなどの工夫が必要になりそうです。
この設定を加えることで、オンボーディングと Defender XDR への通信確認が取れました。
5. 考察
MDE エンジン側のアップデートにより、ようやく通信先要件がシンプルになり運用が楽になるのですが、対象の OS が 2022/3/8 付けのパッチが適用されていることや、古いエンジンバージョンで放置された Windows/ Linux 端末は通信不可であるため、移行や救済措置が必要になりそうです。
Defender XDR エンジンバージョンなどのチェックを行いながらサービスタグ or 簡略化されたドメインの活用をご検討下さい。
本記事が Azure Security にご興味ある方々のためになれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。