Microsoft Defender環境でLinux機器のSyslogをMicrosoft SentinelやAzure Monitorに送る場合、今後の基本構成はAzure Monitor Agent（AMA）とデータ収集ルール（DCR）を使ってLog Analyticsワークスペースへ転送する方式です。2026年5月14日に更新された公式チュートリアルは、新しいAI/Copilot機能の案内ではなく、ファイアウォールやネットワーク機器など、エージェントを直接入れられないLinuxベース機器のログを監視するための実装手順を整理した内容です。(Microsoft Learn)
管理者が今すぐ確認すべきなのは、既存のSyslog収集が古いLog Analytics Agent前提になっていないか、DCRで収集対象のfacilityと重大度を絞れているか、転送用Linux VMの514番ポートやrsyslog/syslog-ngの設定が正しく機能しているかです。特にMicrosoft SentinelをDefenderポータルへ移行する流れの中では、ログ収集の入口だけでなく、インシデント運用・自動化・権限管理までセットで見直す必要があります。
Microsoft DefenderのAI/Copilot更新ではなく、Syslog転送基盤の確認が主題
今回の「Tutorial: Forward Syslog data to Microsoft Sentinel and Azure Monitor by using Azure Monitor Agent」は、Microsoft DefenderそのものにAI/Copilotの新機能を追加する更新ではありません。内容の中心は、Linuxベースの機器からSyslogを受け取るLinux VMを用意し、そのVM上のAzure Monitor AgentがLog Analyticsワークスペースへログを送る構成です。(Microsoft Learn)
実務上は、次のように捉えると分かりやすいです。
| 観点 | 今回押さえるべき内容 |
|---|---|
| 対象 | ファイアウォール、ネットワーク機器、Linuxベースのログ送信元 |
| 目的 | SyslogをLog Analyticsワークスペースに集約し、Microsoft SentinelまたはAzure Monitorで監視する |
| 収集方式 | Azure Monitor AgentとDCRを使う |
| 保存先 | Log AnalyticsワークスペースのSyslogテーブル |
| 管理者の作業 | DCR作成、AMA稼働確認、514番ポート許可、Syslogデーモン設定、KQLでの受信確認 |
公式ページの最終更新日は2026年5月14日ですが、GitHub上の直近変更履歴を見る限り、該当ファイルではレビュー担当者メタデータの追加が主な変更で、Syslog収集手順そのものが大きく変わったとは読み取れません。したがって「新機能が追加された」と断定するのではなく、AMA/DCR前提のSyslog転送手順を再確認すべき更新として扱うのが安全です。(GitHub)
Syslog転送の基本構成
この構成では、Syslogを出力する機器にAzure Monitor Agentを直接インストールするのではなく、転送用のLinux VMを中継役として使います。たとえば、物理ファイアウォール、ネットワークアプライアンス、エージェント非対応のLinuxベース機器が該当します。
流れは次のとおりです。
- Linuxベース機器がSyslogを転送用Linux VMへ送信する
- Linux VM上のrsyslogまたはsyslog-ngがSyslogを受信する
- Azure Monitor AgentがDCRに従ってログを収集する
- Log Analyticsワークスペースの
Syslogテーブルに保存される - Microsoft SentinelまたはAzure Monitor Logsで監視・検索する
この方式のポイントは、ログ収集の設定がワークスペース側の固定設定ではなく、DCRで管理される点です。DCRは、どのデータを集めるか、どのように処理するか、どこに送るかを定義するAzureリソースとして扱われます。(Microsoft Learn)
影響を受ける管理者・開発者
今回の内容で特に影響を受けるのは、次のような担当者です。
| 対象者 | 確認すべきこと |
|---|---|
| SOC管理者 | SentinelでSyslogが継続的に受信できているか、検出ルールやブックがSyslogテーブルを正しく参照しているか |
| インフラ管理者 | 転送用Linux VM、514番ポート、NSG、OSファイアウォール、rsyslog/syslog-ngの設定 |
| クラウド管理者 | DCR、DCRA、Log Analyticsワークスペース、Azure Arc対応サーバーの構成 |
| 開発者・SRE | 既存のKQL、アラート、外部チケット連携、自動化ルールへの影響 |
| セキュリティアーキテクト | AzureポータルからDefenderポータルへの移行計画、権限設計、データ保持方針 |
特に注意したいのは、Log Analytics Agentを前提にした古い運用です。Microsoftの移行ドキュメントでは、Log Analytics Agentは2024年8月31日に廃止済みであり、2026年3月2日以降はデータアップロードが予告なく停止する可能性があると説明されています。未移行の環境では、Syslog監視の欠落がそのまま検知漏れにつながります。(Microsoft Learn)
既存環境でまず確認すべき設定
Syslog転送が動いているように見えても、DCRやポート、重大度フィルターの設定によって必要なログが欠落していることがあります。以下の順に確認すると、原因を切り分けやすくなります。
Azure Monitor Agentが動作しているか
転送用Linux VMでAMAが稼働していなければ、Syslogデーモンがログを受け取っていてもLog Analyticsには届きません。公式チュートリアルでは、Heartbeatテーブルを使ってエージェント稼働を確認する手順が示されています。(Microsoft Learn)
Heartbeat
| where Computer == "vm-linux"
| take 10vm-linuxは実際のLinux VM名に置き換えます。結果が返らない場合は、AMAのインストール状態、DCRの関連付け、VMのネットワーク到達性を確認します。
SyslogがLog Analyticsに届いているか
Syslogの転送確認には、Syslogテーブルを使います。
Syslog
| where Computer == "vm-linux"
| summarize by HostNameここで送信元機器のホスト名が出ない場合、次のどこかで止まっている可能性があります。
| 確認箇所 | よくある原因 |
|---|---|
| 送信元機器 | 転送先IP、プロトコル、ポート番号の誤り |
| Azure VMのネットワーク | NSGで514番ポートが許可されていない |
| Linux OSのファイアウォール | firewalldなどでTCP/UDP 514が閉じている |
| Syslogデーモン | rsyslogまたはsyslog-ngがリモート受信を待ち受けていない |
| DCR | facilityや重大度の条件でログが除外されている |
| AMA | DCRとの関連付けがない、またはエージェントが停止している |
DCRで収集対象を絞るときの判断基準
DCRでは、Linux Syslogデータソースを選び、facilityごとに最小ログレベルを指定します。公式ドキュメントでは、Debug、Info、Notice、Warning、Error、Critical、Alert、Emergencyの重大度が示されています。指定した重大度以上のログが収集対象になります。(Microsoft Learn)
たとえば「Warning」を指定した場合、Warningより重大なError、Critical、Alert、Emergencyも収集されます。一方、InfoやDebugは収集されません。
| 用途 | 推奨の考え方 |
|---|---|
| 本番SOC監視 | まずWarning以上を基本にし、検知要件に応じてInfoを追加 |
| 障害調査中 | 一時的にInfoまたはDebugまで広げる |
| コスト抑制 | 重要なfacilityだけに絞り、Debug常時収集は避ける |
| 監査要件 | auth、authpriv、auditなど必要なfacilityを明示的に確認 |
| 検証環境 | 広めに収集してから、本番向けに削る |
失敗しやすいのは、トラブルシューティング中にDebugまで広げた設定を本番で戻し忘れるケースです。Syslogは機器によって出力量が大きく変わるため、収集範囲を広げるとLog Analyticsの取り込み量と保存コストが増えます。
514番ポートの許可は「Azure側」と「Linux側」の両方を見る
Syslog転送では、転送用Linux VMが514番ポートでログを受け取れる必要があります。公式チュートリアルでは、Syslog送信元に応じてTCPまたはUDPの514番を許可する手順が示されています。Azure VMを使う場合は、VMのネットワーク設定で受信ポートルールを追加し、必要に応じてOS側のファイアウォールにもルールを追加します。(Microsoft Learn)
確認すべき設定は次の3層です。
| 層 | 確認内容 |
|---|---|
| 送信元機器 | 転送先IP、TCP/UDP、514番ポート |
| Azureネットワーク | NSG、サブネット、VM NICの受信規則 |
| Linux OS | firewalld、rsyslog/syslog-ngの待ち受け設定 |
firewalldを使っている場合は、TCP/UDPのどちらを使うかを確認してから許可します。両方を開けると検証は楽ですが、本番では送信元機器の仕様に合わせて最小限にするのが基本です。
sudo firewall-cmd --zone=public --add-port=514/tcp --permanent
sudo firewall-cmd --zone=public --add-port=514/udp --permanent
sudo systemctl restart firewalld.servicersyslogとsyslog-ngの設定で注意すべき点
公式チュートリアルでは、転送用Linux VMに接続してLinux Syslogデーモンを構成する手順が示されています。例として、MicrosoftのGitHubリポジトリにあるForwarder_AMA_installer.pyを取得して実行するコマンドが紹介されており、このスクリプトはrsyslog.dとsyslog-ngの両方に変更を加える可能性があります。(Microsoft Learn)
ただし、本番環境ではスクリプトをそのまま流す前に、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| 既存のrsyslog/syslog-ng設定 | 既存転送やローカル保存ルールを上書き・競合させないため |
| 変更対象ファイル | 構成管理ツールや監査対象ファイルとの整合性を保つため |
| ロールバック手順 | 受信停止やログ重複が起きたときに戻せるようにするため |
| SELinuxの利用有無 | ソケットや転送方式が環境によって変わるため |
| ディスク使用量 | 不要なローカル保存でフルディスクを起こさないため |
公式ドキュメントでは、rsyslogまたはsyslog-ngで不要なログを保存しないようにしないと、フルディスクによってAzure Monitor Agentの動作に影響する可能性があると注意されています。ログ転送用VMは「受けて送る」役割に徹し、ローカル保存は要件がある場合だけ設計するべきです。(Microsoft Learn)
Log Analyticsワークスペースを複数指定するとコストが増える
Syslogデータの宛先は、Azure Monitor LogsのLog Analyticsワークスペースです。公式ドキュメントでは、複数のワークスペースを宛先に追加できる一方、各ワークスペースへ重複してデータが送信され、追加コストが発生すると説明されています。(Microsoft Learn)
複数ワークスペースへの送信が必要になるのは、たとえば次のようなケースです。
| ケース | 判断 |
|---|---|
| 本番SOC用と監査保管用を分けたい | 要件が明確なら検討可能 |
| 部門ごとに別ワークスペースで見たい | まずRBACやクエリ共有で代替できないか確認 |
| 検証のため一時的に二重送信したい | 期間を決めて終了後に削除 |
| なんとなく冗長化したい | コスト増になりやすく非推奨 |
実務では、まず主ワークスペースを1つ決め、保持期間、アクセス権、Sentinelの検出ルール、ブック、データ保持要件をそのワークスペース中心に設計します。二重送信は「運用上の安心」ではなく「コストと管理対象の増加」として評価する必要があります。
時刻ズレと文字欠落にも注意する
Syslog転送では、ログが届いているのに調査時に時系列がずれて見えることがあります。Azure MonitorのSyslog収集ドキュメントでは、Log forwarderを使う場合、TimeGeneratedとEventTimeに差が出る可能性があると説明されています。TimeGeneratedはフォワーダー側で処理されたUTC時刻、EventTimeはSyslogヘッダーから抽出された時刻に基づくため、送信元機器とフォワーダーのタイムゾーンが違うと差が出ます。(Microsoft Learn)
また、Syslogメッセージ内のセミコロン;はAzure Log Analyticsへの取り込み時に削除されると説明されています。セミコロンを含むログ形式を前提にパースしている場合は、送信元で別文字に置き換える、エンコードする、KQLの抽出条件を見直すなどの対策が必要です。(Microsoft Learn)
| 注意点 | 影響 | 対策 |
|---|---|---|
TimeGeneratedとEventTimeの差 | インシデントの時系列分析がずれる | フォワーダーと送信元のタイムゾーン、NTP設定を確認 |
| セミコロン削除 | KQLのパース条件が失敗する | 区切り文字を変更、送信元で変換、KQLを修正 |
| facility/重大度の絞り過ぎ | 重要ログが入らない | 検証時に広めに収集し、必要条件を確定 |
| 複数ワークスペース送信 | 取り込みコスト増 | 必要性と期間を明確化 |
| ローカル保存過多 | フルディスクでAMAに影響 | 不要なローカル保存を止める |
Microsoft SentinelのDefenderポータル移行も同時に考える
Syslog転送自体はAzure Monitor AgentとDCRの話ですが、運用先がMicrosoft Sentinelである場合、Defenderポータルへの移行計画も無視できません。Microsoft Learnでは、Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでサポートされず、Defenderポータルのみで利用可能になると説明されています。(Microsoft Learn)
これにより、Syslog収集そのものだけでなく、次の運用にも影響が出ます。
| 領域 | 見直すポイント |
|---|---|
| インシデント運用 | Defenderポータル側の統合インシデントキューでの確認手順 |
| 自動化 | Sentinelの自動化ルール、Logic Appsプレイブック、外部チケット連携 |
| KQL | Advanced HuntingとLog Analyticsで参照するテーブルや用途の違い |
| 権限 | Azure RBAC、Sentinelロール、Defender側の統合RBAC |
| SOC手順書 | アラート確認、調査、クローズ、エスカレーション手順 |
特に注意が必要なのは自動化です。Defenderポータルへの移行後は、インシデントやアラートの扱い、プロバイダー名、同期タイミング、APIの使い分けに差が出ます。既存のServiceNow連携、チケット作成、通知処理、KQLベースの検出ルールを使っている場合は、Syslogが届くことだけでなく、その後の運用フローまでテストする必要があります。(Microsoft Learn)
移行・展開時のおすすめ手順
既存環境をいきなり全面移行するのではなく、小さく検証してから広げるのが安全です。Log Analytics AgentからAzure Monitor Agentへの移行ドキュメントでも、現状把握、DCR構成、検証、旧エージェント削除の流れが示されています。(Microsoft Learn)
| フェーズ | 作業 | 成功条件 |
|---|---|---|
| 現状把握 | Syslog送信元、既存エージェント、ワークスペース、検出ルールを棚卸し | どのログがどこに入っているか分かる |
| パイロット | 少数のLinux VMと一部機器でAMA/DCRを構成 | HeartbeatとSyslogで受信確認できる |
| 比較検証 | 旧方式と新方式の件数、時刻、ホスト名、facilityを比較 | 重大な欠落や重複がない |
| 本番展開 | Azure Policyや構成管理で対象を拡大 | 新規サーバーにも自動適用できる |
| 旧方式整理 | Log Analytics Agent設定や重複収集を停止 | 二重課金や二重アラートがない |
| 運用更新 | 手順書、KQL、アラート、プレイブックを更新 | SOC担当者が新手順で対応できる |
移行時の失敗で多いのは、ログ収集だけを成功条件にしてしまうことです。実際には、検出ルールが期待通り発火するか、アラートからインシデントが作成されるか、プレイブックが動くか、担当者がDefenderポータル上で調査できるかまで確認して初めて移行完了と考えるべきです。
管理者向けチェックリスト
公開前、移行前、または月次レビューで使えるチェックリストをまとめます。
| チェック項目 | 確認内容 |
|---|---|
| AMA | 転送用Linux VMでAzure Monitor Agentが稼働している |
| DCR | Linux Syslogデータソースが設定され、対象VMに関連付けられている |
| facility | auth、authpriv、audit、local系など必要なfacilityが有効 |
| 重大度 | Warning以上、Info以上など、検知要件に合った最小レベルになっている |
| 宛先 | Log Analyticsワークスペースが正しく、不要な二重送信がない |
| ポート | TCP/UDP 514が送信元仕様に合わせて許可されている |
| Syslogデーモン | rsyslogまたはsyslog-ngがリモート受信できる |
| ディスク | 不要なローカル保存でフルディスクにならない |
| KQL | HeartbeatとSyslogで受信確認できる |
| コスト | 取り込み量、保持期間、複数ワークスペース送信を確認している |
| Defender移行 | Sentinelの運用場所、権限、自動化、SOC手順が更新されている |
次に取るべき行動
今回の公式更新を受けて最初にやるべきことは、Syslog転送構成の棚卸しです。既存環境でLog Analytics Agentを使っているサーバー、DCR未設定のLinux VM、514番ポートを広く開けている転送サーバー、不要に複数ワークスペースへ送っている設定がないかを確認してください。
そのうえで、1台の転送用Linux VMと1つのSyslog送信元を使ってパイロット構成を作り、HeartbeatとSyslogテーブルで受信を確認します。問題がなければ、facilityと重大度を本番要件に合わせて絞り、検出ルール、ブック、自動化、Defenderポータルでの調査手順まで検証します。
Syslogは「届いているか」だけでなく、「必要なログが、必要な粒度で、必要な運用先に届いているか」が重要です。Azure Monitor AgentとDCRを前提に構成を見直すことで、Microsoft DefenderとMicrosoft Sentinelを使った監視基盤を、移行後も安定して運用しやすくなります。
コメント