Defender for Endpoint のログをストレージアカウントに転送する

Defender for Endpoint (旧称: Defender ATP) のログを Azure のストレージアカウントに転送する話です。

Defender for Endpoint の管理コンソール自体は Microsoft が SaaS として提供しており、ログも既定では30日間まで管理コンソールから確認することが可能です。 この 30日間までというのが今回の転送につながる重要なポイントとなります。  結論からいうと、30日間を超えるログを保管(保持し、また、中身を適時確認できる状態)しようと思うと Defener for Endpoint の外部に転送するしかないということです。

ログ転送の設定手順、転送されたログがどのように保管されているか、の2点を紹介します。

ログ転送の設定

ここからはDefender for Endpoint のログ転送の設定手順を具体的に紹介します。

まずは Defender Security Center にサインインします。

左メニューから Partners & APIs > Data export settings を実行します。

“Add data export settngs” をクリックます。

“Name” には定義についての任意の名称を指定します。 転送先には Azure Storage Account または Azure Event Hub を指定可能です。 最後に”Event types” で転送するログを指定します。  

設定はこれだけで、非常に簡単です。 なお、”Save” を実行したタイミングからログの転送は開始されます。

以下は、私が過去に設定済みの定義です。 この後の手順ではこの保管されたログの中身を紹介していきます。

ストレージアカウントに転送したログ

ログは Azure のストレージアカウントに転送しています。 ストレージアカウント上のデータの確認方法は色々ありますが、今回は1つのファイルの操作となりますので Azure Portal で紹介していきます。 他に視覚的にわかりやすい方法となると Storage Explorer もありますし、システムから利用するのであれば API を利用したり、az コマンドでダウンロードすることも可能です。

まずは Azure Portal からストレージアカウントのコンテナーがどのように構成されているか画面で紹介します。

以下の通り、管理コンソール側で指定した11種類のログ種別毎にコンテナーが自動的に作成されます。

deviceevents のコンテナーの中身をアクセスします。

コンテナの中身は以下のように年月日時分の時間単位で階層化されています。 

ストレージアカウントなので Windows や Linux のファイルシステムの階層化とは異なります。あくまで人間の見た目として階層化されているように見えているという表現の方が正しいかもしれません。ただ、この話は今回のログ転送とは直接関係しない話なので止めにします。

y=2021 をクリックします。 2021年ということです。

m=02 をクリックします。 2021年2月ということです。

d=13 をクリックします。 2021年2月13日ということです。

h=09 をクリックします。 2021年2月13日9時ということです。なお Timezone は UTC です。 今回クリックした h=09 は 日本の時刻で言うと +9 した 18時ということになります。

m=00 をクリックします。2021年2月13日9時0分ということです。 2つポイントがあります。 1つ目は先ほど書いた通り UTC であること。 2つ目のポイントはこの分単位を示す階層は “m=00” の常に1つだけとなります。 

“Pt1H.json” というJSON ファイル、これが転送されたログの実体となります。この1つのファイルに1時間分のログがリアルタイムに追記されていきます。 先ほど “m=00” と分の階層は1つだけと書きましたが、 2021/2/13 9:00-10:00 (UTC) の1時間のログがこの “y=2021 / m=02 / d=13 / h=09 / m=00 / PT1H.json” に追記されているということです。

“PT1H.json” をクリックします。

“ダウンロード” をクリックします。

ファイルのフォーマットですが、 Microsoft Docs では特に説明は見つかりません。

1つだけピックアップして紹介していきます。 まず “time”,”tenantid”,”operationName”,”category”、そして “properties” の中に詳細情報を保持しています。

“InitiatingProcessFileSize” に “EzCheckPC.exe” がありますが、このプロセスのアクティビティが Defender for Endpoint としてログ収集していることがわかります。 1つ上の FolderPath を見るとプロセスのインストール先までわかります。 

簡単にですが JSON ファイルとして転送されたログのストレージアカウントへの保管状況、そしてログファイルの中身を簡単に紹介できました。

まとめ

Defender for Endpoint (旧称: Defender ATP) は30日までしか保持出来ず、30日以上ログを保管したい場合は別途転送する必要があります。 標準機能では Azure ストレージアカウントと Event Hub の2つに転送可能で、設定も非常に簡単です。

転送はほぼリアルタイムに行われます。 転送開始は Defender for Endpoint 側でログ転送を行った直後から行われます。 ストレージアカウントにログを保管する場合、ログは見た目上とはなりますが年月日時分で階層化され、m=00 の階層にある1つの JSON ファイルにログが追記されていきます。 1時間分のログが1つのJSONファイルに保管されます。

ログの運用を考える際に”量”も注意が必要なポイントです。 私の個人環境では1時間で1つの JSON ファイルに 約 600KB のデータが出力されました。 1ヶ月200時間パソコンを使うとして 120MB/人・月です。また、このログは転送できるログ11種類の1つだけです。 ログの種別により量はことなりますが、適当にどんぶり勘定して11種類分の11倍とすると 1.3GB/人・月、10年間保管しようと思うと 156GB/人・10年となかなかの量となってきます。 根拠も無く11倍していますし、PC環境や使い方やセキュリティ構成によりログへの出力量も変わりますので PoC や Pilot で見極めていくしかないと思います。 もう1点。 転送ログは JSON ですがスキーマのデータ量が無視できない量です。 生データをざっと見る限り、実際の情報よりもスキーマに関するデータの方が多いです。 そういう意味では”カシコイ” JSON対応のデータベースに保管することでストレージアカウントに単純に保管するよりも少ないデータで保持出来る可能性はあります。

また、そもそもログを保管する意味や目的があるはずです。 セキュリティポリシーやルールとして例えば1年間保管する、3年間保管するということであれば今回紹介した ストレージアカウントへの転送だけで目的は達成できると考えます。 ログの可用性の観点でストレージアカウントをリージョン間冗長化することも可能ですし、コストダウンのためにライフサイクルで1ヶ月たったログファイルを安価なクラスのストレージアカウントに変更することも可能です。 

セキュリティポリシーやルールに保管だけではなく取り出しに関する制約がある場合はストレージアカウントだけでは要件を満たせないこともあります。 例えば、セキュリティインシデント発生後、10分以内にユーザIDなりデバイス名で検索する必要がある場合です。 ストレージアカウントだけでは上で紹介したとおり1つ1つJSONファイルをダウンロードし、検索していく必要があります。 JSON の中の情報を検索するリードタイムに何らかの条件がある場合は検索可能なデータベース、Cosmos DB など、にJSONデータを保持していく構成もあります。 大量のログデータをデータベースに保持することはコスト増にもつながりますので単純な話ではいのですが。

最後に、今回実施したログ転送の設定ですが、Microsoft Defender Security Center の管理画面では英語の UI となっていました。 

こちら Microsoft 365 セキュリティ の UI では日本語対応しています。 Defender ATP → Defender for Endpoint と名前が変わったり、管理画面が色々あったりちょっと混乱するところもありますが、良い方向に向かう過渡期なのだと考えています。

以上