Windows Event Log を安価に Sentinel(Log Analytics Workspace) に入れられないか調査した件
はじめに
Active Directory の監査ログはインシデント発生時に重要なログとなるが、量が膨大になり、通常の分析ログとしての取り込みでは Microsoft Sentinel のコストが高額になってしまいます。最近では Auxiliary ログというものが出てきて、安価にログ取り込みな仕組みはあるが、標準の Azure Monitor Agent (AMA) からは直接 Auxiliary ログに Windows イベントログを取り込むのはサポートされていないません。
しかし、今現在は AMA から Event Hub に Windows イベント ログの連携と Event Hub から Log Analytics Workspace へのデータ インジェストが Preview 機能で可能になっている為、これらの機能を組み合わせて Auxiliary ログのテーブルに Windows イベント ログのデータ取り込みを実施できないかと考えて検証してみました。
なお、AMA から安価な取り込み方法のもう一つである Basic ログへ Windows イベントログの直接取り込みは可能となっております。その方法は以下で別の方が紹介してくれているのでご参考にしてください。
注意点
本構成にはいくつかの注意点があります。本番環境で利用することはもちろん、検討や、テストする際にも十分考慮ください。
- 今回構成で組み合わせる機能は2024年8月時点ですべてプレビューの機能です。将来的にこの構成での取り込みが正しく機能し続けるかは定かではありません。
- 現時点ではサポートされているリージョンも限定的な機能があり、東日本リージョン、西日本リージョンで構成することはできません。
- Event Hub から Log Analaytics Workspace への取り込みは最低100GB/日の取り込みをコミットする価格モデルを適用するか、専用クラスターという仕組みが必要となります。これらの仕組みは取り込み量によらないある程度のコストが日次で発生しますのでご注意ください。また、コミットメントの価格モデルを一度上げたり、専用クラスターを構成すると31日間は価格モデルを落とすことができなくなります。検証に際しても十分ご注意ください。
- AMA から Event Hub への連携は Azure VM のみでサポートされる機能となり、今後も Azure Arc のシナリオへの拡張は予定されておりません。
検証と結果
構成イメージ
以下のようなイメージです。
それぞれの公開情報のリンクは以下になります。
① AMA から Event Hub へのログ転送
② Event Hub から Log Analaytics Workspace への取り込み
③ Auxiliary ログ
構成方法
基本的には各公開情報の通り構成すればいいので、細かい手順は本記事で記載しませんが、構成のうえ注意するべき点がいくつかあるのでその点を補足するような形で記載します。
対象のリージョン
「② Event Hub から Log Analaytics Workspace への取り込み」と「③ Auxiliary ログ」は公開情報にある通り現時点で利用可能なリージョンが限られており、それぞれ異なります。意外と共通で使えないところがあったりするのでちゃんと両方がサポートされるリージョンを選択しましょう。私はいったん West US のリージョンでやりました。
① AMA から Event Hub へのログ転送の構成
- 公開情報で展開するデータ収集ルールの ARM テンプレートがありますが、今回のケースは Event Hub への Windows イベント ログの連携となりますので、Storage Account や Windows イベント ログ以外向けの記載は ARM Template から削除しておきましょう。"storageAccountName" や "storageBlobsDirect"、"storageTablesDirect" また、 "performanceCounters"、"iisLogs" などの DataSource の項目です。
- Window イベントログの対象は ARM テンプレートの xPathQueries で指定する必要があります。今回は AD の監査ログ(セキュリティ ログ)を取得したかったのですが、アプリケーション ログ、システム ログの、「クリティカル」、「エラー」、「警告」も取得するように以下の内容にしました。
"xPathQueries": [
"Application!*[System[(Level=1 or Level=2 or Level=3)]]",
"Security!*[System[(band(Keywords,13510798882111488))]]",
"System!*[System[(Level=1 or Level=2 or Level=3)]]"
],
なお、ARM テンプレートのデプロイ後の設定内容は、Azure ポータルサイトのデータソースでは確認できず、リソース JSON から出ないと確認できません。Azure ポータルサイトで確認できませんので、取得するログの対象を変更する際は Azure CLI を使う必要ありますので注意ください。
一応参考に私が利用した ARM テンプレートを以下に記載しておきます。
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"dataCollectionRulesName": {
"defaultValue": "[concat(resourceGroup().name, 'DCR')]",
"type": "String"
},
"eventHubNamespaceName": {
"defaultValue": "[concat(resourceGroup().name, 'eh')]",
"type": "String"
},
"eventHubInstanceName": {
"defaultValue": "[concat(resourceGroup().name, 'ehins')]",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Insights/dataCollectionRules",
"apiVersion": "2022-06-01",
"name": "[parameters('dataCollectionRulesName')]",
"location": "[parameters('location')]",
"kind": "AgentDirectToStore",
"properties": {
"dataSources": {
"windowsEventLogs": [
{
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"Application!*[System[(Level=1 or Level=2 or Level=3)]]",
"Security!*[System[(band(Keywords,13510798882111488))]]",
"System!*[System[(Level=1 or Level=2 or Level=3)]]"
],
"name": "eventLogsDataSource"
}
]
},
"destinations": {
"eventHubsDirect": [
{
"eventHubResourceId": "[resourceId('Microsoft.EventHub/namespaces/eventhubs', parameters('eventHubNamespaceName'), parameters('eventHubInstanceName'))]",
"name": "myEh1"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Event"
],
"destinations": [
"myEh1"
]
}
]
}
}
]
}
- データ収集ルールの作成後は、「DCR の関連付けを作成し、Azure Monitor Agent をデプロイする」の手順になりますが、こちらを行う前に、ユーザー割り当てマネージド ID をちゃんと対象の仮想マシンに割り当て、必要なロールを割り当てておきましょう。公開情報を順番にやっていくと記載はないのですが、トラブルシューティングとして以下の記載があります。トラブルを避けるためにも先にきちんと構成しておくことが推奨です。
データがイベント ハブに送られていない
イベント ハブ インスタンスで組み込みロール Azure Event Hubs Data Sender にマネージド ID が割り当てられていることを確認します。
マネージド ID が VM に割り当てられていることを確認します。
AMA 設定にマネージド ID パラメータがあることを確認します。
- 公開情報の「DCR の関連付けを作成し、Azure Monitor Agent をデプロイする」も ARM テンプレートでのデプロイになりますが、VM やマネージド ID 、DCR については同じリソース グループにあることが前提の ARM テンプレートになっておりますので、リソースの作成時はリソース グループの構成にご注意ください。
② Event Hub から Log Analaytics Workspace への取り込み
- 先に Auxiliary Log のカスタムテーブルを作成しておきましょう。公開情報の Event Hub からの取り込みについては "TimeGenerated", "RawData", "Properties" となっておりますが、Auxiliary Log の制約を考慮し、今回私の検証では"TimeGenerated", "RawData" のみの構成としました。(ちなみに公開情報通り作成したカスタムテーブルを Basic ログとして取り込む事も可能であることは確認しております。)
- Auxiliary Log は変換ルールをサポートしていないので、公開情報の ARM テンプレートの “transformKql”: “source” は削除しておきましょう。
構成結果
上記の通り、注意点はありつつも公開情報に沿って構成することで、以下の通り Auxiliary ログのテーブルの RowData カラムに、Event Hub を通じて Windows イベントログを導入することができました。基本普段は直接クエリを実行せずに、長期間保存しつつ、有事の際には検索できるようにという用途ではこういった構成も選択肢として取れるかなと思います。
コストメリットが出るのか？
本構成は重ねてとなりますが Log Analaytics Workspace で 100GB/日以上の取り込みのコミットメントまたは専用クラスターが必要になったり、Event Hub もリソースとして必要になります。現時点で100GB/日以上のコミットメントになるほど取り込んでいないようなケースで、Auxiliary Log の取り込みコストが安くなってもそこでコスト メリットが出るのかという疑問もあるかと思います。Azure のコストは為替やリージョンで変動しますし、他のログ取り込みの状況なども踏まえて一概にどのような場合においてもコストメリットが出るかというと定かではありませんが、AD の監査ログなどで1日数百GBレベルで出るようなログであれば分析ログとして取り込むよりは基本的にコストを削減できる構成にはなると存じます。ただし、Auxiliary ログは分析ログと比較して制約が大きくあるので、要件として Auxiliary ログで良いのかという判断は必要となります。
今後の期待
今回は Windows イベントログ をテーマにこのような構成を試してみましたが、Event Hub から Sentinel(LAWS) への取り込みで、Auxiliary ログ(または Basic ログ)へ取り込みができるとしたら協力で、ログ量が膨大である為、Sentinel 等に取り込み難かった、Event Hub へ連携可能な、Microsoft Entra ID の非対話型のサインイン ログや、Microsoft Defender のテーブル情報なども安価に取り込むという事ができる可能性がある点はとても魅力的だと思います。特に Auxiliary ログと Event Hub から LAWS への取り込みの機能の一般提供が待ち遠しいです。
最後に
今回はほぼプレビューの機能で実験的に行った構成が期待通り動いたので本記事にまとめました。ただしこのような利用の仕方は明確にサポートされるかの記載はなく、使っている機能もすべてプレビューという事で、今後のアップデートを確認の上ご利用は各人の判断の上で実施いただくようにお願いいたします。
Discussion