Windows Azure VM に AMA (Azure Monitor Agent) を導入して Window セキュリティイベントを取得する (Microsoft Sentinel 編)

はじめに

Azure VM の監視エージェントは MMA (Microsoft Monitoring Agent / Log Analytics エージェント) と AMA (Azure Monitor Agent / Azure Monitor エージェント) の二つが提供されています。
Azure では最新版の OS (Windows 2022 以降、Ubuntu 22.04 LTS以降、SUSE Linux Enterprise Server 15.2以降など）より AMA のみのサポートになるため、イベントやメトリクス監視を行う場合は AMA の導入を進める必要が出てきます。

Azure Monitor エージェントの導入方法

AMA の導入方法は幾つかの方法が提供されています。
https://docs.microsoft.com/ja-jp/azure/azure-monitor/agents/azure-monitor-agent-manage?tabs=ARMAgentPowerShell%2CPowerShellWindows%2CPowerShellWindowsArc%2CCLIWindows%2CCLIWindowsArc

公式ドキュメントに方法が掲載されていますが、用途に応じて様々な展開方法が提供されています。

方法	概要
Azure Portal から設定する	「モニター」より DCR(Data Collection Rule) を設定する。対象の VM を選定すると自動でエージェントも導入される
Resource Manager テンプレートを用いる	事前にパラメータを記入したjsonファイルを用意し、Resource Manager テンプレートでCLIで導入する。大規模向け。
Azure CLI を用いる	Azure CLI を用いて対象 VM に Agent を導入する。
Azure Policy を用いて、ポリシー準拠しないVMを強制導入させる	Azure Policy にて自動化が適用できる。
Microsoft Sentinel のデータコネクタから設定する	Sentinel のデータコネクタから設定を行う。Azure Portal から設定を行う手順と同一。

いずれの種類も導入は出来るのですが、Microsoft Sentinel によるセキュリティ監視を行う場合は「Microsoft Sentinel のデータコネクタから設定する」を推奨します。

• Sentinel コネクタ以外の設定（Azure Monitor から DCR ルールで設定を行う）場合、取り込まれるテーブルが異なる。
  • DCR ルール経由の場合、Event テーブルに送信される
  • Sentinel コネクタ経由の場合、Security Events テーブルに送信される
• Sentinel の Windows サーバー用のテンプレートルールは、Security Events テーブルに書き込まれたものを参照している。
  • Azure Monitor / DCR ルールで手動設定した場合、テンプレートルールの検知が行えない！
  • 自分でテンプレートルールのテーブルを書き換える必要がある

詳しくは Azure サポートチームがまとめたブログに記載があります。
これを知らないと分析ルールが全く動作しない羽目に陥りますので、予め注意しておきましょう。

なお、一度 Azure Monitor / DCR ルールで設定しまった場合でも、Microsoft Sentinel コネクター側から上書きで設定変更が出来るようになっています。

設定手順

1. Microsoft Sentinel を有効化する

こちらは省略します。

2. データコネクタより、「AMA を使用した Windows セキュリティ イベント」を選択する

Sentinel のデータコネクタより、「AMA を使用した Windows セキュリティイベント」を選択します。

3. データ収集ルールの作成

データ収集のためのルール名を作成します。
※こちらは Azure Monitor 側の DCR (Data Collection Rule)名となります。

4. AMA を導入 & ログ収集する対象の VM を選択する

Azure Monitor エージェントを導入する VM を選択します。

5. Windows Security Event ログの種別を選択する

用途に応じて、取得するイベントの内容を選択することが出来ます。
詳しくは公式ドキュメントを参照下さい。

方法	概要
すべてのイベント	すべての Windows セキュリティ イベントおよび AppLocker イベント。
共通(一般)	監査の目的で使用する標準的なイベント セット。 このセットには、完全なユーザー監査証跡が含まれます。 たとえば、ユーザー サインインとユーザー サインアウトの両方のイベント (イベント ID 4624、4634) が含まれています。 また、セキュリティ グループの変更などの監査アクションや、ドメイン コントローラーの主要な Kerberos 操作、確立されているベスト プラクティスに沿った各種のイベントもあります。一般のイベント セットには、あまり一般的ではない種類のイベントも一部含まれている場合があります。 完全な監査証跡機能を保ちながらも、より扱いやすいレベルにまでイベントの量を減らすことが、一般セットの重要なポイントであるためです。
最小	潜在的な脅威を示す可能性がある小さいイベント セット。 このセットには、完全な監査証跡は含まれません。 侵害が成功したことを示す可能性があるイベントなど、発生率がきわめて低い重要イベントのみが対象となります。 たとえば、ユーザーの成功したログオンと失敗したログオン (イベント ID 4624、4625) が含まれますが、監査には重要であっても侵害の検出には重要ではない、比較的ボリュームの大きいサインアウト情報 (4634) は含まれません。 このセットのデータ量のほとんどは、サインイン イベントとプロセス作成イベント (イベント ID 4688) から構成されます。
カスタム	Xpath クエリを使用して、ストリームするセキュリティ イベントをフィルター処理して選択できます。

6. 作成する

上記パラメータを投入後、数十分もすると Azure Monitor エージェントがデプロイされ、Windows Security Event Log が確認することが出来ます。

まとめ

Windows 2022 Server といった OS アップグレードの際は AMA による監視エージェント導入、監視が求められるため、これまでの MMA / AMA をうまく使い分けて導入していただければ幸いです。