Microsoft SentinelでSyslogやCEFログを取り込んでいる環境では、確認すべきポイントが「コネクタ名」ではなく、Azure Monitor Agent（AMA）とData Collection Rule（DCR）でログ収集を制御できているかに移っています。2026年5月14日に更新された公式情報では、Syslog via AMA／Common Event Format（CEF）via AMAコネクタを使い、Linuxマシン、ネットワーク機器、セキュリティアプライアンスからMicrosoft Sentinelへログを取り込む手順が整理されています。(Microsoft Learn)
結論として、管理者が最初に見るべきなのは、AMAが対象Linuxマシンまたはログフォワーダーに入っているか、DCRでfacilityとseverityを適切に絞っているか、CEFとSyslogの二重取り込みが起きていないかです。旧Log Analytics Agent（MMA/OMS）からの移行が残っている場合は、重複課金や検知ルールの不整合を避けるため、移行計画と検証手順を明確にしてから展開する必要があります。(Microsoft Learn)
Microsoft Defender／Microsoft Sentinelで確認すべき今回のポイント
「Ingest syslog and CEF messages to Microsoft Sentinel – AMA」は、Microsoft SentinelでSyslogおよびCEFメッセージを取り込むための公式手順です。対象は、Microsoft Defenderポータル内のMicrosoft Sentinelと、Azureポータル内のMicrosoft Sentinelの両方です。(Microsoft Learn)
今回の更新で実務上重要なのは、単に「Syslogを取り込む」説明ではなく、次の運用観点が明確になっている点です。
| 確認ポイント | 実務での意味 |
|---|---|
| AMAを使う | ログ収集エージェントはAzure Monitor Agentを前提に設計する |
| DCRを使う | どのマシンから、どのfacility・severityのログを収集するかをルール化する |
| Defenderポータル対応 | Microsoft SentinelのデータコネクタをDefenderポータルからも管理する |
| Logs Ingestion API対応 | ポータル操作だけでなく、APIやIaCに近い形でDCRを作成できる |
| 重複取り込み対策 | CEFとSyslogで同じfacilityを使うと、CommonSecurityLogとSyslogの両方に入る可能性がある |
特にMicrosoft SentinelをMicrosoft Defenderポータルで運用している組織では、データコネクタの場所も押さえておく必要があります。Defenderポータルでは、Microsoft Sentinel > Configuration > Data connectors からSyslog via AMAまたはCommon Event Format（CEF）via AMAコネクタを開きます。(Microsoft Learn)
Syslog via AMAとCEF via AMAの違い
Syslog via AMAとCEF via AMAは似ていますが、取り込まれるログの用途と格納先が異なります。混同すると、分析ルールやハンティングクエリが期待通りに動かない原因になります。
| コネクタ | 主な対象 | 代表的なログ送信元 | 格納先テーブル |
|---|---|---|---|
| Syslog via AMA | 一般的なSyslogメッセージ | Linuxサーバー、ネットワーク機器、アプリケーション基盤 | Syslog |
| Common Event Format（CEF）via AMA | セキュリティ製品のCEF形式ログ | ファイアウォール、IDS/IPS、EDR、プロキシ、UTMなど | CommonSecurityLog |
公式情報では、SyslogメッセージはMicrosoft SentinelのLog Analyticsワークスペース内のSyslogテーブルに、CEFログはCommonSecurityLogテーブルに格納されると説明されています。(Microsoft Learn)
判断基準はシンプルです。OSや汎用機器のイベントをそのまま集めたい場合はSyslog via AMA、セキュリティ製品がCEF形式で出力するイベントをSIEM分析に使いたい場合はCEF via AMAを選びます。ファイアウォール製品がCEF形式と通常Syslogの両方を送れる場合は、どちらの形式を正式な監視対象にするかを先に決めてください。
影響を受ける対象者
今回の内容は、Microsoft SentinelやMicrosoft Defenderを触る担当者だけでなく、ログ送信元を管理するネットワーク・インフラ担当にも影響します。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Sentinelで必要なログがSyslogまたはCommonSecurityLogに入っているか |
| Azure管理者 | AMA、DCR、DCR Association、Azure Arc、RBAC権限が正しく構成されているか |
| ネットワーク機器管理者 | ファイアウォールやアプライアンスの送信先がログフォワーダーになっているか |
| SOC担当者 | 既存の分析ルール、ブック、ハンティングクエリが新しい取り込み経路でも動くか |
| 開発者／IaC担当 | DCR作成や関連付けをAPI、ARMテンプレート、CI/CDで管理できるか |
特に注意したいのは、オンプレミスや他クラウド上のログフォワーダーです。Azure VMでないLinuxマシンをログフォワーダーにする場合は、Azure Arc Connected Machine agentを入れてAzure上の管理対象リソースとして見えるようにする必要があります。(Microsoft Learn)
管理者が最初に確認すべき前提条件
Syslog／CEF取り込みで失敗しやすいのは、Sentinel側のコネクタ設定よりも、前提条件の不足です。構成作業に入る前に、次の項目を確認してください。
| 分類 | 確認項目 | 不備がある場合の影響 |
|---|---|---|
| Sentinel | Content hubから必要なソリューションをインストールしている | コネクタが表示されない、または構成できない |
| 権限 | VMへのエージェント展開、DCR作成、ARMテンプレート展開に必要なRBAC権限がある | AMAの展開やDCR作成に失敗する |
| ログフォワーダー | Linux VMを用意し、rsyslogまたはsyslog-ngを有効化している | ログを受信・転送できない |
| Azure Arc | Azure外のフォワーダーにConnected Machine agentが入っている | DCRの関連付け対象として扱えない |
| Python | Python 2.7または3が利用できる | インストールスクリプト実行時に失敗する |
| ネットワーク | 送信元からフォワーダー、フォワーダーからAMA、AMAからAzureへの通信が通る | ログがSentinelまで届かない |
公式手順では、ログフォワーダーにsyslog-ngまたはrsyslogが必要であり、ログ送信元の機器はローカルのsyslog daemonではなく、ログフォワーダーのsyslog daemonへメッセージを送るよう構成する必要があるとされています。(Microsoft Learn)
構成の基本は「AMA＋DCR＋ログフォワーダー」
Syslog／CEF via AMAの構成は、大きく次の流れで考えると理解しやすくなります。
| 手順 | 作業内容 | 実務上の注意点 |
|---|---|---|
| 事前準備 | Content hubで必要なソリューションを入れる | 対象機器がSyslogなのかCEFなのかを確認する |
| エージェント準備 | ログフォワーダーまたは対象Linux VMにAMAを展開する | Azure外のサーバーはAzure Arcも確認する |
| DCR作成 | 収集対象のfacilityとseverityを設定する | 最初から全ログを入れない。必要最小限から始める |
| フォワーダー設定 | rsyslogまたはsyslog-ngで受信・転送を設定する | 514番ポートとプロトコルを機器側設定と合わせる |
| 機器設定 | セキュリティ機器やネットワーク機器の送信先を指定する | 送信先IP、ポート、TCP/UDP、TLS有無を統一する |
| 検証 | tcpdump、サービス状態、KQLで確認する | Sentinelへの反映に時間差があるため即断しない |
DCRは、どのシステムを監視し、どの種類のログを収集し、取り込み前にどのフィルターを適用するかを定義します。Microsoftの概要ページでも、DCRによるフィルターはパフォーマンスやクエリ効率の改善に役立つと説明されています。(Microsoft Learn)
ポータルでDCRを作る場合の確認ポイント
ポータル操作で構成する場合は、Syslog via AMAまたはCommon Event Format（CEF）via AMAコネクタを開き、Configuration領域からDCRを作成します。Microsoft Sentinel in Azure portalではConfiguration > Data connectors、DefenderポータルではMicrosoft Sentinel > Configuration > Data connectorsから進みます。(Microsoft Learn)
DCR作成時に特に重要なのは、ResourcesとCollectの設定です。ResourcesではAMAを入れる対象マシン、つまりログフォワーダーを選びます。Collectではfacilityごとに最小ログレベルを選びます。たとえばLOG_ERRを選ぶと、LOG_ERRに加えて、より重大度の高いLOG_CRIT、LOG_ALERT、LOG_EMERGも収集されます。(Microsoft Learn)
実務では、最初からInfo相当を広く集めるのは避けた方が安全です。ログ量が急増し、コストやノイズが増えます。まずは検知・調査に必要なfacilityを洗い出し、Warning以上やError以上など、目的に合う最小レベルから始めるのが現実的です。
APIや自動化でDCRを作る場合の注意点
開発者やIaC担当者は、Azure Monitor Logs Ingestion APIを使ったDCR作成も確認しておきましょう。公式手順では、DCRのJSONを用意し、dataCollectionRulesリソースに対してPUTリクエストを送る流れが示されています。(Microsoft Learn)
DCR JSONでは、SyslogとCEFでstreamsの値が異なります。
"streams": [
"Microsoft-Syslog"
]Syslogの場合はMicrosoft-Syslog、CEFの場合はMicrosoft-CommonSecurityLogを指定します。facilityとログレベルは、facilityNamesとlogLevelsで定義します。(Microsoft Learn)
APIで構成するメリットは、環境ごとの差分をコードとして管理できることです。たとえば、本番環境ではError以上、検証環境ではWarning以上、特定の機器だけInfoも収集する、といった設計をテンプレート化できます。一方で、ポータル構成と違い、AMAの手動インストールやDCR Associationの作成漏れが起きやすいため、デプロイ後の検証を自動化しておくべきです。
ログフォワーダー展開時の注意点
ログフォワーダーは、複数の機器からSyslog／CEFを受け取り、AMA経由でMicrosoft Sentinelへ送る中継点です。ここが止まるとログ収集全体に影響します。
公式手順では、コネクタページからインストールコマンドをコピーし、ログフォワーダー上でスクリプトを実行する流れが示されています。このスクリプトはrsyslogまたはsyslog-ngを必要なプロトコルで構成し、UDP／TCPの514番ポートを開いて受信できるようにします。Python 3が既定のpythonコマンドに設定されていない場合は、コマンド内のpythonをpython3に置き換える必要があります。(Microsoft Learn)
sudo systemctl status azuremonitoragent.service
sudo systemctl status rsyslog.service
sudo systemctl status syslog-ng.service展開後は、AMA、rsyslog、syslog-ngのサービス状態を確認します。Syslog-ngを使っていない環境でsyslog-ng.serviceが存在しないのは問題ではありません。実際に使っているdaemonの状態を確認してください。
ログフォワーダーの設計では、ディスク容量も軽視できません。Microsoftの手順では、不要なログをローカル保存しないようsyslog-ngまたはrsyslogを構成することが推奨されています。ディスクフルになると、インストール済みAMAの動作に影響する可能性があります。(Microsoft Learn)
ポートと通信経路で見るべきポイント
Syslog／CEFの取り込み障害は、ポートや通信経路の問題で起きることが多くあります。特にネットワークセキュリティグループ、OSファイアウォール、ロードバランサー、オンプレミス側ファイアウォールをまたぐ構成では、どこで止まっているかを切り分ける必要があります。
| 通信区間 | 主な確認項目 |
|---|---|
| ログ送信元 → ログフォワーダー | 送信先IP、ポート514、TCP/UDP、TLS設定 |
| ログフォワーダー上のdaemon | rsyslogまたはsyslog-ngが514番を待ち受けているか |
| daemon → AMA | AMA 1.28.11以降ではTCP 28330への転送を確認 |
| AMA → Azure | Azure Monitor／Log Analyticsへのアウトバウンド通信が許可されているか |
Microsoftの概要では、AMA 1.28.11以降はTCP 28330でログを受け取り、それ以前のバージョンではUnix domain socketを使うと説明されています。514番以外のポートを使う場合は、送信元アプリケーションとsyslog daemon側のポート設定を一致させる必要があります。(Microsoft Learn)
確認コマンドの例は次の通りです。
sudo ss -lnp | grep -E "28330|514"トラブルシューティング手順では、514番でRSyslogが待ち受け、28330番でAMAコンポーネントが待ち受けていることを確認する例が示されています。(Microsoft Learn)
CEFとSyslogの二重取り込みを防ぐ
もっとも見落としやすいのが、CEFとSyslogの二重取り込みです。Microsoftの概要では、同じfacilityをSyslogメッセージとCEFメッセージの両方に使うと、CommonSecurityLogとSyslogの間でデータ取り込みの重複が起きる可能性があると説明されています。(Microsoft Learn)
防止策は大きく2つです。
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| CEF用とSyslog用でfacilityを分ける | 機器側でfacilityを変更できる | 機器ごとの設定台帳を作る |
| DCRの変換でCEFをSyslogストリームから除外する | 機器側のfacility変更が難しい | 変換ルールのテストが必要 |
たとえば、CEF形式で送るログをlocal0、通常Syslogをlocal5に分けると、DCR側でも収集対象を整理しやすくなります。機器側で分けられない場合は、DCRのingestion-time transformationでCEFメッセージをSyslog側から除外する設計を検討します。
移行時に注意すべきMMA／OMSとの関係
旧Log Analytics Agent、つまりMMA／OMSを使っている環境では、AMAへの移行を前提に考える必要があります。Microsoftの移行ガイドでは、Log Analytics Agentは2024年8月31日に廃止され、2026年3月2日以降はLog Analytics Agentからのデータアップロードが予告なく停止する可能性があると説明されています。(Microsoft Learn)
移行で避けるべき失敗は、AMAと旧エージェントを並行稼働させたまま、同じログを二重に送ることです。検証期間中に一時的な並行稼働が必要な場合でも、どちらの経路でどのログを送っているかを明確にしてください。
移行の進め方は、次の順序が安全です。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 現状把握 | 既存のMMA、ワークスペース、Syslog設定、接続機器を棚卸しする | どのログがどこから来ているか説明できる |
| パイロット | 少数のフォワーダーまたは機器でAMA＋DCRを構成する | Syslog／CommonSecurityLogに期待通り入る |
| 並行検証 | 既存クエリ、分析ルール、ブックの結果を比較する | 件数、時刻、主要フィールドに大きな差がない |
| 切り替え | 機器の送信先やDCRを本番展開する | 監視対象ログに欠損がない |
| 旧構成撤去 | MMA側の収集設定や不要なエージェントを削除する | 重複取り込みが止まり、コストが安定する |
Microsoftの移行ガイドでも、移行時は小さなサーバー群で検証し、データ収集が正しく動くことを確認してから展開を広げ、最後に旧Log Analytics Agentを削除する流れが示されています。(Microsoft Learn)
SentinelをDefenderポータルで使う場合の展開上の注意
Microsoft SentinelはMicrosoft Defenderポータルでも一般提供されています。Microsoftの公式情報では、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされなくなり、Microsoft Defenderポータルでのみ利用可能になるとされています。(Microsoft Learn)
そのため、今回のSyslog／CEF via AMAの設定も、将来的にはDefenderポータルで運用できる体制を前提にした方が安全です。既にAzureポータルでSentinelを運用している組織は、次の点を確認しておきましょう。
| 確認項目 | 理由 |
|---|---|
| Defenderポータル上で対象ワークスペースを開けるか | 運用担当者が同じ作業を継続できるか確認するため |
| Data connectorsの場所を把握しているか | コネクタ設定の変更時に迷わないため |
| 権限設計がAzureポータル依存になっていないか | SOC担当者が必要な操作をDefenderポータルで実行できるようにするため |
| 既存手順書の画面遷移を更新しているか | 障害対応時の手戻りを減らすため |
特に運用手順書では、「AzureポータルでData connectorsを開く」だけでなく、「Defenderポータルではどのメニューにあるか」も併記しておくと、移行期の混乱を抑えられます。
検証はKQLだけでなくフォワーダー上でも行う
Sentinelにログが見えない場合、いきなりKQLだけで調べると原因を見誤ります。ログ送信元、フォワーダー、AMA、ワークスペースの順に切り分けてください。
| 確認場所 | コマンド／確認方法 | 見るべきポイント | ||
|---|---|---|---|---|
| ログフォワーダー | sudo tcpdump -i any port 514 -A -vv | 送信元からログが届いているか | ||
| サービス状態 | systemctl status azuremonitoragent、systemctl status rsyslog | AMAとdaemonが起動しているか | ||
| ポート状態 | sudo ss -lnp | grep -E "28330 | 514" | 514番と28330番が待ち受けているか | ||
| DCR構成 | AMAのconfig-cacheを確認 | 対象のDCR設定が反映されているか | ||
| Sentinel | KQLでSyslogまたはCommonSecurityLogを検索 | テーブルにレコードが入っているか |
Microsoftのトラブルシューティング手順では、構成後にログがMicrosoft Sentinelへ表示されるまで最大20分かかる場合があると説明されています。すぐに表示されないだけで失敗と判断せず、まずフォワーダーにログが届いているかを確認しましょう。(Microsoft Learn)
CEFログの確認例は次の通りです。
CommonSecurityLog
| where TimeGenerated > ago(1d)
| where DeviceProduct == "MOCK"Cisco ASAログの確認例は次の通りです。
CommonSecurityLog
| where TimeGenerated > ago(1d)
| where DeviceVendor == "Cisco"
| where DeviceProduct == "ASA"公式手順でも、テストメッセージ送信後にLog Analyticsワークスペースへクエリを実行して確認する流れが示されています。(Microsoft Learn)
時刻ずれにも注意する
ログフォワーダーを使う場合、TimeGeneratedとEventTimeの差にも注意が必要です。Microsoftの概要では、TimeGeneratedはフォワーダーまたはコレクターがSyslogメッセージを処理したUTC時刻、EventTimeはSyslogヘッダーから抽出され、フォワーダー側のローカルタイムゾーンオフセットでUTCに変換される時刻と説明されています。(Microsoft Learn)
送信元機器とログフォワーダーのタイムゾーンが異なる場合、両者に差が出ることがあります。これは単なる遅延とは限りません。インシデント調査でタイムラインを作る場合は、送信元機器、フォワーダー、Sentinelの時刻設定をそろえ、どの時刻を基準に分析するかを決めておくことが重要です。
失敗しやすい設定と対策
| 失敗しやすいポイント | 起きる現象 | 対策 |
|---|---|---|
| Content hubのソリューション未導入 | コネクタが見つからない | 対象機器に必要なSyslogまたはCEFソリューションを確認する |
| Azure Arc未導入 | Azure外フォワーダーをDCR対象にできない | Connected Machine agentを先に導入する |
| facilityを広く取りすぎる | ログ量とコストが増える | 監視目的に必要なfacilityとseverityに絞る |
| CEFとSyslogで同じfacilityを使う | 重複取り込みが発生する | facilityを分けるかDCR変換で除外する |
| 514番だけ確認している | フォワーダーには届くがSentinelに出ない | 28330番、AMAサービス、Azure向け通信も確認する |
| Pythonコマンドの違いを見落とす | インストールスクリプトが失敗する | Python 3環境ではpython3指定を確認する |
| ローカル保存を放置する | ディスクフルでAMAに影響する | 不要なログを保存しないようdaemonを構成する |
| KQLだけで検証する | ネットワーク問題とSentinel側問題を切り分けられない | tcpdump、ss、サービス状態から順に確認する |
現場では、「Sentinelに出ない＝DCRが悪い」と考えがちですが、実際には送信元機器の送信先IPミス、UDP/TCPの不一致、オンプレミス側ファイアウォール、ログフォワーダーのdaemon停止など、Sentinelに届く前の問題も多くあります。
本番展開前のチェックリスト
本番展開前には、次のチェックリストを使って確認すると抜け漏れを減らせます。
| チェック | 確認内容 |
|---|---|
| コネクタ | Syslog via AMAまたはCEF via AMAのどちらを使うか決めた |
| ソリューション | Content hubで必要なソリューションを入れた |
| 権限 | AMA展開、DCR作成、DCR関連付けに必要なRBAC権限がある |
| フォワーダー | Linux VM、Azure Arc、Python、rsyslog／syslog-ngを確認した |
| ネットワーク | 514番、28330番、Azure向けアウトバウンドを確認した |
| DCR | facility、severity、stream名を確認した |
| 重複対策 | CEFとSyslogのfacility重複を確認した |
| KQL | SyslogまたはCommonSecurityLogでテストログを確認した |
| 既存運用 | 分析ルール、ブック、ハンティングクエリを検証した |
| 移行 | MMA／OMSの旧収集設定を残すか削除するか決めた |
| 手順書 | Defenderポータルでの操作手順も記載した |
このチェックリストで特に重要なのは、DCRとKQLの両方を見ることです。DCRで期待したログを集める設計にしていても、既存の分析ルールがCommonSecurityLogではなく別テーブルや古いフィールドを前提にしていると、検知に穴ができます。
まず取るべき次のアクション
Syslog／CEF via AMAへの対応で最初に行うべきことは、既存のログ取り込み経路を棚卸しすることです。どの機器が、どの形式で、どのフォワーダーへ、どのテーブルにログを送っているかを一覧化してください。
そのうえで、次の順に進めるのが実務的です。
- 既存のMMA／OMS利用有無を確認する
- SyslogとCEFの対象機器を分ける
- ログフォワーダーのOS、Arc、Python、daemonを確認する
- DCRでfacilityとseverityを最小限に設計する
- 少数機器でテスト取り込みを行う
- KQL、分析ルール、ブックで期待通りに使えるか確認する
- 本番展開後、旧収集経路と重複取り込みを整理する
「Ingest syslog and CEF messages to Microsoft Sentinel – AMA」は、単なる設定手順ではなく、Microsoft Sentinelのログ収集をAMAとDCR中心に再設計するための実務ガイドとして読むべき内容です。特にMicrosoft Defenderポータルへの運用移行、旧Log Analytics Agentからの移行、重複取り込みの防止、ログ量の最適化は、早めに確認しておくほど後のトラブルを減らせます。
コメント