はじめに

Azure VM 上のサーバーからセキュリティログを収集し、監査や脅威検知に活用したいとお考えではないでしょうか？クラウド上で仮想マシンを運用する場合でも、ログの一元収集と監視はセキュリティ対策上欠かせません。Microsoft Azure には包括的な監視サービスである Azure Monitor が用意されており、これを活用することで Azure 環境のログやメトリックを簡単に収集・分析できます。
（参考）Azure Monitor の概要
特に近年、新しい Azure Monitor エージェント (AMA) と データ収集ルール (Data Collection Rule: DCR) の仕組みが導入され、Azure VM のログ収集がより柔軟かつ強力になりました。

本記事では Azure Monitor のデータ収集ルール (DCR) を使って、Azure VM（Windows Server）からセキュリティイベントログを収集する方法を解説します。具体的には、リモートデスクトップ (RDP) のログオン試行に関するイベント (WindowsのイベントID 4624/4625) を収集し、Log Analytics ワークスペースで分析する手順を実践形式で紹介します。Azure VM の利用を検討している方や、Azure上でのログ収集によるセキュリティ監査を行いたい方の参考になれば幸いです。

Azure Monitor とは

Azure Monitor とは、Azure やオンプレミスを含む様々な環境からモニタリングデータを収集・分析し、可視化やアラート発報まで行える統合監視ソリューションです。Azure Monitor を利用すると、クラウド上のリソースやアプリケーションのパフォーマンスや稼働状況を把握し、必要に応じて自動・手動で対応策を講じることができます。具体的には以下のような特徴があります。

• 多様なデータソースの収集: 仮想マシン (Azure VM) のゲストOSからのログ・メトリックはもちろん、Azureリソースのアクティビティログ、プラットフォームメトリック、コンテナやデータベースの指標など、あらゆるレイヤのデータを収集可能です。
• ログおよびメトリックの統合基盤: 収集したデータは Azure Monitor 内の共通プラットフォームに蓄積され、Log Analytics ワークスペースでのログ分析やワークブックによる可視化、アラートルールによる通知といった形で横断的に活用できます。
• 他サービスとの連携: Azure Monitor は単体でも機能しますが、必要に応じてMicrosoft Sentinel（SIEM機能）や他のITSMツール、サードパーティ製監視ツールへのエクスポートも可能で、柔軟に統合できます。

要するに、Azure Monitor は Azure 環境の「見える化」と「集中管理」を支える土台です。本記事で扱うログ収集も、Azure Monitor の機能の一部として行われます。

Azure データ収集ルール (DCR) とは

データ収集ルール (Data Collection Rule, DCR) は、Azure Monitor における新しいログ収集設定の単位です。DCR を使うことで「どのデータを収集し、必要に応じてどのように変換し、どこへ送るか」を一元的に定義できます。これは従来のログ収集方法に比べ柔軟で管理しやすいアプローチであり、Azure Monitor エージェント(AMA)と組み合わせて動作します。

DCR の仕組みは ETL（Extract, Transform, Load） パイプラインに似ており、Azure Monitor における統一的なデータ取り込み基盤を活用しますAzure Monitor でのデータ収集ルール (DCR)。具体的に、DCR では次の内容を指定します。

• 収集するデータ: 例えば「Windowsのセキュリティイベントログから特定のイベントIDのログ」を収集、など対象データを定義。
• データのスキーマ（構造）: 収集対象データの構造をAzure Monitorに認識させる設定。
• オプションの変換処理: 取り込んだデータに対してフィルタやマスク処理、フォーマット変更などKustoクエリベースの変換を適用可能（不要なデータを除外したり機密情報を削除したりできます）。
• 送信先: データを送る先として、Log Analytics ワークスペースやAzure Monitorのメトリックストアを指定（後述）。

DCR 自体は Azure リソース（※リソースグループ内に作成されるオブジェクト）として管理され、Azure Portalの「Monitor > Data Collection Rules」から一覧・編集できます。DCR を有効化するには、対象とするリソース（例えばVM）に DCR を関連付け (Association) します。Azure VM に AMA がインストールされ接続されると、そのVMは自分に関連付けられたDCRを参照し、収集すべきデータ項目を認識してAzure Monitorへログを送信する仕組みです。

従来、Azure VM のログ収集には Log Analytics エージェント(MMA/OMSエージェント)によるWindowsイベントログ収集やDiagnostic Settingsによるプラットフォームログ転送など複数の方法が存在しました。しかし、DCR/AMA の登場により統一的かつ高機能なログ収集が可能となり、将来的にこれらレガシー方式を置き換える方向です。例えば、旧エージェント(MMA)はAzure Monitor Agent(AMA)＋DCRで置き換えられ、Diagnostic Settingsでのカスタムログ収集等も将来DCRに集約される見込みです。

Azure データ収集ルール (DCR) で出来ること

では、DCR を使うことで具体的に何ができるのか、その主なポイントを整理します。

• 統一された設定方法: Windowsイベントログ、LinuxのSyslog、パフォーマンスカウンター、IISログ、テキスト/JSONログなど、異なる種類のデータソースも一貫した方法で設定できます(Azure Monitor を使用して仮想マシン クライアントからデータを収集する)。これにより、Windows VM・Linux VM双方のログ収集を単一の枠組みで管理可能です（DCR作成時にプラットフォーム種別をWindows/Linux選択。またPlatform type=Noneを選べば両方含むDCRも作成可能です）。
• フィルタリングと変換: DCRでは収集データに対し事前にフィルタ条件を適用できます。例えば「セキュリティログの中でも特定のEventIDのみ収集」や「Syslogの特定の施設・優先度のログのみ収集」といった絞り込みが可能です。さらに前述のように高度なデータ変換 (Transformation) 機能を使えば、ログ取り込み時に不要な項目を除去したり、データ形式を整えてから保存するといった処理も行えます。
• 複数宛先へのデータ送信: 1つのDCR内で、収集したデータを複数の宛先に並行送信する設定も可能です（同種の宛先であれば複数指定可）。例えば、同じWindowsイベントを二つのLog Analyticsワークスペースに送る、といったことも設定上は可能です。ただしその場合、データが重複保存されコストが増加する点には注意が必要です。
• IaCによる大規模展開: DCRは Azure Resource Manager によるテンプレート（ARM/Bicep）やAzure CLI/PowerShell、さらにはAzure Policyとも統合可能です。そのためコードベースで数百台のVMに対しログ収集設定を一括適用したり、環境ごとにDCRを分離してDevOps的に管理するといった運用もスムーズに行えます。
• エッジパイプラインとの連携 (高度なシナリオ): Azure Monitor はクラウド側のパイプラインだけでなくオンプレミス側に配置可能なエッジパイプライン機能も提供しています。DCRはクラウド側パイプラインの構成定義ですが、エッジ側と組み合わせることでオフライン環境で一旦ログを蓄積し後で同期する、ネットワーク分離環境から段階的にログ送信するといったケースにも対応できます。

以上のように、DCR は Azure Monitor エージェントとセットで用いることで「何を・どこに・どうやって」を細かく制御できる強力な仕組みです。次章からは、実際の設定手順やLog Analytics連携について詳しく見ていきましょう。

Log Analytics との連携

Azure Monitor で収集されたログデータは、通常 Log Analytics ワークスペース に格納されます。Log Analytics はAzure Monitorのログデータをクエリ・分析するための基盤であり、DCRで収集したVMのログも最終的にはワークスペース内のテーブルにレコードとして蓄積されます。たとえば

• Windowsイベントログのデータは Event テーブルに格納されます。このテーブルにはSystemやApplication、SecurityといったWindowsイベントログから収集したエントリが保存されます。
• LinuxのSyslogデータは Syslog テーブルに、パフォーマンスカウンターは Perf テーブルに、IISログは W3CIISLog テーブルに、それぞれ保存されます。

Log Analytics 上では、これらのテーブルに対して Kusto クエリ（KQL）を実行することで詳細な分析が可能です。Azure Monitor 上でログを収集した後、Microsoft Sentinel を有効化すれば、Sentinel側の検知ルールや可視化テンプレートも活用できます。また、SentinelにはAMA用の専用コネクタ（「Windows Security Events via AMA」等）が用意されており、これを使うとセキュリティログが Log Analytics 内の SecurityEvent テーブル に格納されます。ただし通常のDCR経由で既に同じSecurityログをEventテーブルに送っている場合、Sentinelコネクタを有効化するとデータが二重に取り込まれる点に注意が必要です。セキュリティ用途でAMAを使う場合は、Azure Monitor (Eventテーブル) で収集する方法かSentinelコネクタ(SecurityEventテーブル)を使う方法か、要件に応じて片方に絞るのが望ましいでしょう。

いずれにせよ、Log Analytics に蓄積されたログはポータル上でクエリを実行して調査したり、ログに基づくアラートルールを作成して自動通知を受けたりすることができます。たとえば、後述するようにRDPの不正ログオンを検知したり、特定イベント発生をトリガーにアラートメールを飛ばすことも容易に実現できます。Azure Monitor と Log Analytics の組み合わせにより、Azure VM 上のログはクラウド上で一元管理・分析できます。

Azure データ収集ルール (DCR) の設定

では、実際に Azure Portal 上でデータ収集ルール (DCR) を設定する方法を見てみましょう。ここでは例として Windows Server VM のセキュリティイベントログを収集するケースを想定していますが、Linux VMの場合も流れはほぼ同様です（データソースに「Syslog」を選ぶ等の違いがあります）。

データソースとターゲットの指定

1. DCRの新規作成: Azure ポータルでMonitorサービスのメニューから「Data Collection Rules（データ収集ルール）」を開き、「作成」ボタンを押します。まず基本情報として、ルール名、所属サブスクリプションとリソースグループ、リージョンを指定します。リージョンは後で指定する Log Analytics ワークスペースのリージョンと同一である必要がある点に注意してください（ワークスペースが他リージョンの場合は別のDCRが必要）。またプラットフォームの種類として今回は Windows を選択します（Linux VM用の場合は Linux を選択）。
   
2. 対象リソースの追加: 続いて「リソース」タブで、このDCRを適用する対象VMを選択します。Add resourcesボタンからAzure VMを一台または複数選択可能です。ここでVMを追加せずに後から関連付けを行うこともできますが、Portal上で作成時に選択しておくとスムーズです。対象として選択できるのはAzure VMやAzure Arc経由で管理されているマシンなどです（VMスケールセットの柔軟オーケストレーションモードは個別VM選択が必要）。
   
   
3. データ収集の設定: 「収集と送信 (Collect and deliver)」タブで、収集するデータソースと送信先を定義します。「+ データソースの追加」をクリックし、まずデータの種類を選択します。今回は Windows Event Logs（Windowsイベントログ）を選択しましょう。すると項目設定欄が現れるので、以下のように構成します。
   • イベントログの種類: Security（セキュリティログ）を指定します。これはWindowsのイベントビューアで「セキュリティ」ログと表示されるログです。収集するイベント: All（すべて）/Critical/Error/Warning/Information/Verbose などから絞り込みできますが、ここではカスタムクエリを使うため一旦任意のレベルを選択しておきます（※GUI上は一つ以上レベル選択必須のため）。
   
   
   • フィルタの種類: デフォルトでは基本的なレベルフィルタですが、より細かく対象イベントを絞り込むため Custom (カスタム) を選択します。カスタム (XPath) クエリ: イベントログから収集対象とするイベントをXPath構文で指定します。今回はリモートアクセスのログオン成功・失敗イベントである 4624 と 4625 番のイベントに限定するため、次のように記述します。
   
   
   • Security!*[System[(EventID=4624 or EventID=4625)]]
   上記は「Securityログ内の、EventIDが4624または4625のイベント」を意味するXPathクエリです。実際、Microsoft Sentinelの公式ドキュメントでも 4624/4625 イベントを収集するXPath例として同様の指定が紹介されています。このようにXPathを用いることで、イベントログ内の必要なイベントだけに絞って効率的にログを収集できます。 （※補足: EventID 4624 はWindowsにおけるログオン成功イベント、4625はログオン失敗イベントです。RDP経由のログオン試行もこれらのIDで記録されるため、両方を収集しておくことでリモートログオンの成否を把握できます。）
   
   
   
   
   • ターゲット: 続けて上記データソースの送信先を指定します。「+ ターゲットの追加」をクリックし、Azure Monitor Logs を選択、該当の Log Analytics ワークスペース を選びます。今回は監査用途のためログデータはLog Analyticsに送りますが、パフォーマンスカウンターなど一部データでは Azure Monitor メトリック への送信も可能です。
   
   
4. 設定内容の確認と作成: データソースと送信先の設定を終えたら、「次へ」または「確認と作成」に進みます。最後に基本情報・リソース・データ収集設定のサマリーが表示されるので確認し、問題なければ「作成」ボタンを押してDCRをデプロイします。デプロイが完了すると、指定したリソースグループ内にDCRが作成されます。

エージェントのインストールと有効化

DCRを作成しVMに関連付けたことで、Azure Monitor エージェント(AMA)によるログ収集の準備が整いました。Azure VMの場合、DCRにリソースを関連付けると自動的に対象VM上に Azure Monitor エージェント拡張機能がインストールされます。これはAzureポリシーによって裏側で自動実行されるため、ユーザーが手動でVMにエージェントをインストールする必要はありません。特にAzure Portal上でDCRをVMに関連付けた場合はほぼ即座に拡張機能のデプロイが走り、拡張機能名「AzureMonitorWindowsAgent」(Windowsの場合) がVMに追加されます。

※オンプレミスや他クラウドのVMでAzure Arc経由で管理しているケースでは、事前にArc登録とAzure Monitorエージェント拡張のデプロイが必要です。またLinux VMの場合も同様に「AzureMonitorLinuxAgent」拡張が自動インストールされます。Azure VM以外のサーバーについてはAzure Arcのご利用をご検討ください。

エージェントが正しくインストール・起動すると、対象VMは1分ごとにHeartbeat 信号をAzure Monitorに送信します。このHeartbeatは Log Analytics の Heartbeat テーブル で確認でき、エージェント稼働状況の指標となります。DCR適用後はまず Heartbeat が届いているか確認すると良いでしょう。

実践！Azure VM (Windows Server) のセキュリティログを収集してみよう

それでは、具体的に Azure VM 上のセキュリティログ（4624/4625イベント）を収集し、Log Analytics で分析する一連の流れを見てみます。今回は Windows Server 2019 を想定したAzure VMを例とします。

1. 環境の準備: あらかじめ Azure 上に Windows Server VM を構築し、Log Analytics ワークスペースも作成しておきます。VMはAzure ADログインまたはローカル管理者アカウントでRDP接続できる状態にしておきます（監査のため、意図的に複数回ログオン試行を行い、4624/4625イベントが発生する状況を用意しておきます）。
2. DCRの作成・適用: 前章「Azure DCRの設定」で説明した手順に従い、Securityログから4624/4625イベントを収集するDCRを作成し、対象VMに関連付けます（既に実施済みの場合は次へ進みます）。DCR適用後、数分待ってエージェントの自動インストールとログ収集開始を待ちます。
3. ログ収集の確認: Azure Portalで対象VMを開き、「ログ」メニューからLog Analyticsのクエリエディタを起動します。クエリウィンドウに以下のようなクエリを入力し、直近収集されたイベントを確認してみましょう。
   Event | where TimeGenerated > ago(10m) | where Source == "Microsoft-Windows-Security-Auditing" | where EventID in (4624, 4625) | sort by TimeGenerated desc
   このクエリは直近10分間に収集された4624/4625イベントを時系列で表示するものです。実行すると、結果にSecurityログ由来の4624 (ログオン成功) および 4625 (ログオン失敗) イベントが一覧表示されるはずです。もし結果が空の場合、イベントが発生していない可能性があります。その場合は実際に対象VMへRDPログイン（成功/失敗）を試みてログを発生させ、数分待ってから再度クエリを実行してください。
4. ログ内容の分析: 無事イベントが収集できていれば、次はそれらのログを分析してみましょう。生のイベントを一覧表示するだけでは有用な知見を得にくいため、KQLを用いて情報を加工・集計します。今回はRDPによる不正アクセスの痕跡を洗い出すことを目的に、以下のクエリを実行してみます。
   

// RDPアクセスをソースIPごとに集計（成功/失敗の回数やユーザー名を分析）
Event | where TimeGenerated > ago(30d) | where Source == "Microsoft-Windows-Security-Auditing"
| where EventID in (4624, 4625) // イベントデータXMLから必要なフィールドを抽出
| parse EventData with * '<Data Name="LogonType">' LogonType:string '</Data>' *
| parse EventData with * '<Data Name="IpAddress">' IpAddress:string '</Data>' *
| parse EventData with * '<Data Name="TargetUserName">' TargetUserName:string '</Data>' *
| parse EventData with * '<Data Name="LogonProcessName">' LogonProcessName:string '</Data>' * // RDP関連のログオン試行に絞り込み
| where ( LogonType == "10" or (LogonType == "3" and (LogonProcessName contains "svchost" or LogonProcessName contains "NtLmSsp")) or (LogonType == "7" and isnotempty(IpAddress)))
| where isnotempty(IpAddress) and IpAddress !in ("-", "::1", "127.0.0.1") // 成功/失敗を示すフラグを付与
| extend AccessResult = case(EventID == 4624, "Success", EventID == 4625, "Failed", "Unknown")
| extend SourceIP = IpAddress // IPアドレス単位で集計
| summarize SuccessCount = countif(AccessResult == "Success"), FailureCount = countif(AccessResult == "Failed"), TotalAttempts = count(), FirstAttempt = min(TimeGenerated), LastAttempt = max(TimeGenerated), UniqueUsers = dcount(TargetUserName), Users = make_set(TargetUserName, 10), LogonTypes = make_set(LogonType) by SourceIP // 見やすく項目選択
| project SourceIP, SuccessCount, FailureCount, TotalAttempts, SuccessRate = round(100.0 * SuccessCount / TotalAttempts, 2), UniqueUsers, Users, LogonTypes, FirstAttempt, LastAttempt
| order by TotalAttempts desc

// RDPアクセスをソースIPごとに集計（成功/失敗の回数やユーザー名を分析）
Event | where TimeGenerated > ago(30d) | where Source == "Microsoft-Windows-Security-Auditing"
| where EventID in (4624, 4625) // イベントデータXMLから必要なフィールドを抽出
| parse EventData with * '<Data Name="LogonType">' LogonType:string '</Data>' *
| parse EventData with * '<Data Name="IpAddress">' IpAddress:string '</Data>' *
| parse EventData with * '<Data Name="TargetUserName">' TargetUserName:string '</Data>' *
| parse EventData with * '<Data Name="LogonProcessName">' LogonProcessName:string '</Data>' * // RDP関連のログオン試行に絞り込み
| where ( LogonType == "10" or (LogonType == "3" and (LogonProcessName contains "svchost" or LogonProcessName contains "NtLmSsp")) or (LogonType == "7" and isnotempty(IpAddress)))
| where isnotempty(IpAddress) and IpAddress !in ("-", "::1", "127.0.0.1") // 成功/失敗を示すフラグを付与
| extend AccessResult = case(EventID == 4624, "Success", EventID == 4625, "Failed", "Unknown")
| extend SourceIP = IpAddress // IPアドレス単位で集計
| summarize SuccessCount = countif(AccessResult == "Success"), FailureCount = countif(AccessResult == "Failed"), TotalAttempts = count(), FirstAttempt = min(TimeGenerated), LastAttempt = max(TimeGenerated), UniqueUsers = dcount(TargetUserName), Users = make_set(TargetUserName, 10), LogonTypes = make_set(LogonType) by SourceIP // 見やすく項目選択
| project SourceIP, SuccessCount, FailureCount, TotalAttempts, SuccessRate = round(100.0 * SuccessCount / TotalAttempts, 2), UniqueUsers, Users, LogonTypes, FirstAttempt, LastAttempt
| order by TotalAttempts desc

かなり長いクエリになりましたが、ポイントを簡単に説明します。

• WindowsイベントログのEventDataはXML形式の文字列として格納されているため、parse 演算子を用いてログオン種別(LogonType)、接続元IP(IpAddress)、対象ユーザー名(TargetUserName)、ログオンプロセス名(LogonProcessName)を抽出しています。それぞれ4624/4625イベントの詳細フィールドです。where 句で LogonType に基づきRDP関連のログオンのみを抽出しています。WindowsではLogonType=10が「リモート対話型（RDPなど）」、LogonType=3が「ネットワーク（NLA経由のRDP含む）」、LogonType=7が「ロック解除（リモートセッション再開）」を意味します。上記クエリではそれらに該当するログだけを残すことで、不要なログオン（例えばコンソールログオン等）を除外しています。また IpAddress フィールドが空やローカルアドレス(::1/127.0.0.1)でないものに限定することで、実際のリモート元IPが存在する記録に絞っています。その上で、EventID 4624を成功(Success)、4625を失敗(Failed) としてフラグを付与し、summarize で 接続元IPアドレスごと に集計しています。各IPからの総ログオン試行回数(TotalAttempts)や成功/失敗の内訳、初回・最終試行日時、延べ利用ユーザー数(UniqueUsers)および実際に使われたユーザー名一覧(Users)などをまとめて算出しています。

5. 分析結果の活用: 集計クエリの結果はそのまま調査に使えるだけでなく、Azure Monitor/Sentinel上で分析ルールやアラートに発展させることもできます。例えば「短時間に失敗ログオンが一定回数以上あったIPを検知してアラートを上げる」「成功率が低いIPをピックアップしてブロックする」といったセキュリティ対策に応用可能です。Azure Monitor にはログアラート機能があり、KQLの集計結果に基づきアラートを発報できます。またMicrosoft Sentinelを利用している場合は、同様のKQLを分析ルールとしてスケジューリングし、検知時にSOARプレイブックを実行して自動対処することもできます。

以上が、Azure Monitor のDCRを用いた Azure VMログ収集とその分析手順の一例です。今回はWindowsのSecurityログを題材にしましたが、LinuxサーバーについてもSyslogから認証ログを収集したり、カスタムログファイルを収集する設定を行うことで同様の監視を実現できます。

まとめ

Azure Monitor のデータ収集ルール (DCR) を活用することで、Azure VM のログ収集は非常に柔軟かつ強力になります。従来はエージェントごとやサービスごとに別々だったログ収集設定を、DCRで統一的に管理できるようになりました。特にセキュリティ監査の観点では、必要なログだけを効率よく集めて集中管理し、クラウド上で高度な分析ができる点が大きなメリットです。今回取り上げたRDPログオンの監視は一例に過ぎませんが、同様の手法でAzure VM内の様々なイベント（例: アプリケーションログ、システムログ、カスタムアプリのログなど）を収集・分析できます。Azure MonitorとLog Analyticsを組み合わせれば、オンプレミスで個別にログサーバーを立てる場合と比べてスケーラビリティや可用性の面でも優れ、組織全体のログ管理基盤として活用できるでしょう。

セキュリティ要件が厳しいシステムほど、監視すべきログは増えがちですが、Azure MonitorのDCR機能であれば必要なログを必要なだけ集めて取捨選択し、コストコントロールもしやすいという利点があります。ぜひ Azure 環境の構築に際しては、ログ収集基盤としてAzure MonitorのDCRを活用し、効率的な監視と迅速なインシデント対応につなげてください。

弊社のご紹介

弊社ではAzure構築・導入支援サービスを提供しております。

マイクロソフト出身、 Azure 認定資格を保持するエンジニアが Azure に関するアドバイスや、環境構築などのご支援をいたします。

200を超えるAzureのサービスの中から、どのようなサービスを利用すれば良いのか、どういう組み合わせで利用できるのか、ランニングコストはどれくらいかかるのかなど、様々な角度から生じるお客様の疑問にお答えし、弊社にて Azure 環境の構築や Azure の導入をサポートします。

Azure をより活用し、最適な構成を構築するご支援をいたしますので、ご検討の方はお気軽にお問い合わせください。