「Syslog and CEF AMA connectors – Microsoft Sentinel」は、SyslogやCEF形式のログをAzure Monitor Agent（AMA）でMicrosoft Sentinelへ取り込むためのコネクタです。2026年5月14日に更新された公式情報で特に確認すべき点は、ログ収集の中心がDCR（Data Collection Rule）とAMAになること、Microsoft Defenderポータルでの運用を前提に準備すべきこと、そしてSyslog/CEFの重複取り込みや時刻ずれを防ぐ設定確認です。
Microsoft Defenderを使う管理者にとっては、単に「コネクタを有効化する」だけでは不十分です。ログフォワーダー、rsyslog/syslog-ng、ポート、DCR、Log Analyticsテーブル、移行計画までまとめて点検する必要があります。(Microsoft Learn)
Microsoft Defenderの「Syslog and CEF AMA connectors – Microsoft Sentinel」は何が変わるのか
「Syslog and CEF AMA connectors – Microsoft Sentinel」は、Microsoft SentinelがLinuxマシン、ネットワーク機器、セキュリティアプライアンスからSyslogおよびCEFログを収集するための仕組みです。
ここでいうMicrosoft Defenderは、Microsoft Defender for Endpoint単体の話ではなく、Microsoft SentinelをMicrosoft Defenderポータル上で運用する統合セキュリティ運用の文脈で理解するのが正確です。Microsoft SentinelはDefenderポータルで一般提供されており、Defender XDRやE5ライセンスを持たない環境でも利用できます。また、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルでのみ利用される予定です。(Microsoft Learn)
今回の公式情報で押さえるべき変更点は、次の3つです。
| 確認ポイント | 内容 | 管理者への影響 |
|---|---|---|
| 収集方式 | Syslog via AMA / Common Event Format（CEF）via AMAでログを収集 | MMAや従来型の構成を前提にした運用を見直す必要がある |
| 設定単位 | DCRで収集対象、Facility、Severity、フィルターを定義 | ワークスペース単位の感覚ではなく、DCR単位で設計・管理する必要がある |
| 運用ポータル | AzureポータルとDefenderポータルの両方で設定可能だが、将来的にはDefenderポータル中心 | Sentinel管理者はDefenderポータルの操作導線に慣れておく必要がある |
特に重要なのは、Syslog/CEFの取り込みが「ログフォワーダーにAMAを入れれば終わり」ではないことです。DCR、Facility、Severity、ポート、ログテーブル、重複排除まで含めて設計しなければ、不要なログ増加、検知漏れ、コスト増、調査時の時刻混乱につながります。
Syslog via AMAとCEF via AMAの基本的な役割
Syslogは、Linuxサーバーやネットワーク機器、アプリケーションがログを送信するための標準的なプロトコルです。Microsoftの公式情報では、AMAはRFC 3164（BSD Syslog）とRFC 5424（IETF Syslog）形式のSyslogメッセージをサポートすると説明されています。(Microsoft Learn)
一方、CEF（Common Event Format）は、SIEM向けに使われるベンダー中立のイベント形式です。ファイアウォール、ルーター、侵入検知システム、検知・応答製品などのセキュリティ機器からのログを、Microsoft Sentinelで扱いやすい形式に整えるために使われます。
取り込み後の主な格納先は次の通りです。
| ログ形式 | 主な送信元 | Microsoft Sentinel上の格納テーブル |
|---|---|---|
| Syslog | Linux VM、サーバー、ネットワーク機器、ログフォワーダー | Syslog |
| CEF | ファイアウォール、EDR/NDR、IDS/IPS、セキュリティアプライアンス | CommonSecurityLog |
SOC運用では、CEFログは検知ルールやインシデント調査に直結することが多く、Syslogは機器の状態確認や補助的な調査ログとして使われることが多いです。ただし、製品によっては同じイベントがCEFとSyslogの両方で送られる場合があるため、取り込み設計が重要になります。
影響を受ける対象者
今回の更新は、Microsoft Defenderを利用するすべてのユーザーに直接影響するものではありません。主に影響を受けるのは、Microsoft SentinelでSyslogまたはCEFログを取り込んでいる、またはこれから取り込む組織です。
| 対象者 | 確認すべきこと |
|---|---|
| Sentinel管理者 | データコネクタ、DCR、ワークスペース、Log Analyticsテーブルの設計 |
| SOC運用担当者 | 取り込まれるログ量、Severity、検知ルールへの影響 |
| インフラ管理者 | ログフォワーダー、rsyslog/syslog-ng、ポート、TLS、ディスク容量 |
| ネットワーク管理者 | セキュリティ機器からログフォワーダーへの送信設定 |
| 開発者・自動化担当者 | Logs Ingestion API、DCR JSON、DCR Association、IaC化 |
| 移行担当者 | MMA/Log Analytics AgentからAMAへの移行状況 |
特に、オンプレミス機器、Azure外のクラウド、ハイブリッド環境からログを取り込んでいる場合は注意が必要です。Azure VM以外のログフォワーダーを使う場合、Azure Arc Connected Machine Agentの導入が必要になるケースがあります。(Microsoft Learn)
収集アーキテクチャの確認ポイント
Syslog/CEF AMAコネクタでは、主に2つの構成があります。
1つ目は、Linux VM自身がSyslogを生成し、その同じマシン上のAMAがログをMicrosoft Sentinelへ送る構成です。
2つ目は、ログフォワーダー用のLinux VMを用意し、複数のネットワーク機器やセキュリティ機器からSyslog/CEFログを集約してから、AMAでMicrosoft Sentinelへ送る構成です。
実務では、後者のログフォワーダー構成が多く使われます。ファイアウォールやIDS、NDR、プロキシ、VPN装置などが直接Microsoft Sentinelへ送信するのではなく、まずLinuxベースのログフォワーダーへ送信し、そこからAMAがLog Analyticsワークスペースへ転送します。
ポート設定で特に注意すべき点
公式情報では、ログソースからSyslogデーモンへの送信には一般的にTCPまたはUDPの514番ポートが使われます。一方、AMAのバージョンによって、SyslogデーモンからAMAへの受け渡し方式が異なります。
| 箇所 | 既定または代表的な設定 | 注意点 |
|---|---|---|
| ログソース → rsyslog/syslog-ng | TCP/UDP 514番 | 独自ポートを使う場合、送信元機器とデーモン側の設定を一致させる |
| rsyslog/syslog-ng → AMA | AMA 1.28.11以降はTCP 28330番 | 古いAMAではUnix domain socketを使用 |
| AMA → Microsoft Sentinel | アウトバウンド443番 | プロキシ、FW、Private Link設計を確認 |
AMAベースのデータコネクタでは、エージェントがインストールされたシステムからMicrosoft Sentinelへ接続できる必要があり、アウトバウンド443番の許可が必要です。(Microsoft Learn)
現場でよくある失敗は、ログソース側は514番に送っているのに、ログフォワーダー側のrsyslog/syslog-ngが別ポートを待ち受けているケースです。また、オンプレミスからクラウド上のログフォワーダーへ送る場合、TLS設定やファイアウォールの許可もあわせて確認してください。
DCRで確認すべき設定
Syslog via AMAとCEF via AMAでは、DCRがログ収集の中心になります。DCRでは、どのマシンから、どのFacilityの、どのSeverity以上のログを収集するかを定義します。
DefenderポータルまたはAzureポータルで設定する場合は、Microsoft Sentinelのデータコネクタ画面からDCRを作成できます。この方法では、選択したVMにAMAが自動的にインストールされます。一方、Logs Ingestion APIを使う場合は、より柔軟なフィルター設定が可能ですが、AMAのインストールを手動で行う必要があります。(Microsoft Learn)
ポータル設定とAPI設定の使い分け
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| Defenderポータル / Azureポータル | 少数のログフォワーダー、初回導入、GUIで確認したい環境 | 最小ログレベルの選択が中心で、細かな自動化には不向き |
| Logs Ingestion API | 大規模展開、複数環境への標準化、IaC管理 | AMAを事前にインストールし、DCR Associationも設計する必要がある |
開発者や自動化担当者は、DCR JSON内のstreamsに注意してください。SyslogはMicrosoft-Syslog、CEFはMicrosoft-CommonSecurityLogを使います。FacilityやログレベルはfacilityNames、logLevelsで定義します。
設定後は、DCRがログフォワーダーのVMに関連付けられているかを確認します。DCRを作っただけでは不十分で、対象VMとのDCR Associationが正しく構成されていなければログは流れません。
SyslogとCEFの重複取り込みを防ぐ
今回の公式情報で特に実務上重要なのが、同じFacilityをSyslogとCEFの両方で使うと、SyslogテーブルとCommonSecurityLogテーブルに重複して取り込まれる可能性があるという点です。(Microsoft Learn)
たとえば、あるファイアウォールがCEF形式でlocal4にイベントを送信し、同時にSyslog側のDCRでもlocal4を収集している場合、同じイベントがCEFとしてもSyslogとしても取り込まれる可能性があります。
重複を防ぐには、次のどちらかを選びます。
| 対策 | 内容 | 向いているケース |
|---|---|---|
| Facilityを分ける | CEFで使うFacilityをSyslog収集対象から外す | 送信元機器でFacilityを変更できる場合 |
| 取り込み時変換で除外する | DCRのingestion-time transformationでCEF相当のSyslogを除外 | 送信元機器側のFacilityを変えられない場合 |
実務では、まず送信元機器の設定でFacilityを分離する方法を優先します。機器側で変更できない場合に、DCRの変換でProcessNameなどを条件に除外します。
重複取り込みは、セキュリティ検知の精度だけでなく、ログ保存コストにも影響します。特にCEFログは大量に流れることがあるため、導入直後の数日間はテーブル別の件数を必ず確認してください。
CommonSecurityLog
| where TimeGenerated > ago(24h)
| summarize Count=count() by DeviceVendor, DeviceProduct
| order by Count descSyslog
| where TimeGenerated > ago(24h)
| summarize Count=count() by Computer, Facility, SeverityLevel
| order by Count desc同じ機器名や同じ時間帯で件数が不自然に増えている場合は、CEFとSyslogの両方に同じイベントが入っていないかを確認しましょう。
TimeGeneratedとEventTimeのずれに注意する
Syslog/CEFログをログフォワーダー経由で取り込む場合、TimeGeneratedとEventTimeが一致しないことがあります。
公式情報では、TimeGeneratedはログフォワーダーまたはコレクターがSyslogメッセージを処理したUTC時刻、EventTimeはSyslogヘッダーから抽出された時刻と説明されています。Syslogヘッダーにはタイムゾーン情報が含まれないため、ログフォワーダーとログ生成元のタイムゾーンが異なると、時刻差が発生する可能性があります。(Microsoft Learn)
これはインシデント調査で大きな問題になります。たとえば、日本時間で発生したイベントをUTCや別リージョンのログフォワーダーで処理していると、調査タイムライン上でイベントが前後して見えることがあります。
対策として、次の3点を確認してください。
| 確認項目 | 推奨対応 |
|---|---|
| ログフォワーダーのタイムゾーン | 可能であればUTCに統一し、運用ルールとして明記する |
| 送信元機器の時刻同期 | NTP設定を確認し、時刻ずれを防ぐ |
| 分析ルールの時刻条件 | TimeGeneratedだけでなく、必要に応じてイベント側の時刻項目も確認する |
SOCの運用手順書には、「Sentinel上の検知時刻」と「機器上のイベント発生時刻」が異なる可能性があることを明記しておくと、調査時の混乱を防げます。
移行で確認すべきこと：MMAからAMAへ
まだLog Analytics Agent、いわゆるMMA（Microsoft Monitoring Agent）やOMS Agentを前提にしている環境では、AMAへの移行を優先すべきです。Microsoftの公式情報では、Log Analytics Agentは2024年8月31日に廃止済みであり、2026年3月2日以降、クラウド取り込みサービスへのデータアップロードが予告なく停止する可能性があるとされています。(Microsoft Learn)
移行時に重要なのは、単純にエージェントを入れ替えることではありません。既存のログ収集設定を棚卸しし、DCRに置き換え、重複取り込みを避けながら段階的に展開することです。
移行時の基本ステップ
| ステップ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | 既存のMMA、ワークスペース、データソースを棚卸し | 使っていないと思っていたコネクタが検知ルールで使われている |
| パイロット | 少数のログフォワーダーでAMAとDCRを検証 | 本番と異なるログ量でテストし、負荷を見誤る |
| 重複回避 | MMA側の収集設定を止めてから本格展開 | MMAとAMAの同時収集でコストが増える |
| 検証 | Syslog、CommonSecurityLog、検知ルールを確認 | ログ件数だけ見て、SeverityやFacilityの欠落に気づかない |
| 本番展開 | Azure PolicyやIaCで標準化 | 手作業でDCR差分が増え、環境ごとに設定がばらつく |
移行中は、一時的にMMAとAMAが同じログを収集してしまうことがあります。テスト目的で並行稼働する場合でも、対象サーバー、期間、比較方法、終了条件を明確に決めておくべきです。
ログフォワーダーの前提条件
ログフォワーダーを使う場合、Linux VMに次の条件が必要です。
| 項目 | 確認内容 |
|---|---|
| OS | AMAがサポートするLinuxディストリビューションか |
| Azure Arc | Azure VM以外の場合、Azure Arc Connected Machine Agentが導入されているか |
| Python | Python 2.7またはPython 3が使えるか |
| Syslogデーモン | rsyslogまたはsyslog-ngが有効か |
| ネットワーク | ログソースから514番などへ到達できるか |
| ディスク | 不要ログのローカル保存でフルディスクにならないか |
| 負荷分散 | VMSS展開ではラウンドロビン対応のロードバランサーを検討しているか |
公式手順では、ログフォワーダー上でインストールスクリプトを実行し、rsyslogまたはsyslog-ngを構成して、必要なローカルポートを開く流れになります。また、フルディスク状態になるとAMAの動作に影響するため、不要なログを保存しないようにsyslogデーモン側の設定を見直すことが推奨されています。(Microsoft Learn)
見落としやすいのはPythonです。Python 3が入っていてもpythonコマンドとして呼び出せない場合、スクリプト実行時に失敗することがあります。その場合はpython3で実行するか、環境側のコマンド設定を見直してください。
管理者が展開前に確認すべきチェックリスト
Syslog/CEF AMAコネクタを導入または見直す前に、次の項目を確認してください。
| 分類 | チェック項目 |
|---|---|
| コネクタ | Syslog via AMAとCEF via AMAのどちらを使うか明確になっている |
| ソリューション | Content hubから対象製品・機器に対応するソリューションを導入している |
| ワークスペース | 取り込み先のLog Analyticsワークスペースが決まっている |
| DCR | Facility、Severity、対象VMが正しく定義されている |
| エージェント | AMAが対象Linux VMまたはログフォワーダーに導入されている |
| ポート | 514番、28330番、443番など必要な通信が許可されている |
| 重複対策 | CEFとSyslogで同じFacilityを収集していない |
| 時刻 | ログソース、ログフォワーダー、Sentinel上の時刻差を理解している |
| 検証 | テストメッセージ送信とKQL確認の手順がある |
| 移行 | MMAや古いコネクタ設定が残っていないか確認している |
このチェックリストは、初回導入だけでなく、機器追加やログフォワーダー増設時にも使えます。特にDCRは後から増えやすいため、命名規則を決めておくと運用が楽になります。
例として、DCR名には次のような情報を含めると管理しやすくなります。
dcr-sentinel-cef-prod-jpeast-fw01
dcr-sentinel-syslog-prod-onprem-network
dcr-sentinel-cef-dev-validation環境名、ログ種別、リージョン、用途を入れておくと、障害対応時に「どのDCRがどのログを収集しているか」をすぐに判断できます。
開発者・自動化担当者が確認すべきAPIとIaCの注意点
大規模環境では、Defenderポータルから手作業でDCRを作るだけでは管理が難しくなります。複数のログフォワーダー、複数ワークスペース、複数テナントを扱う場合は、APIやIaCでDCRを管理する方が現実的です。
開発者が特に確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| DCR JSON | streams、facilityNames、logLevelsが意図通りか |
| DCRA | DCR Associationで対象VMにDCRが関連付けられているか |
| APIバージョン | 管理APIのバージョンを固定し、変更時に検証する |
| 差分管理 | 本番・検証・開発環境でDCRの差分を可視化する |
| 変換処理 | ingestion-time transformationで除外条件を入れすぎていないか |
| ロール | DCR作成、VM拡張、Arcサーバー操作に必要なRBACがあるか |
ポータルでは「最小ログレベル」を選択する形が中心ですが、APIではより細かいログレベルの指定が可能です。たとえば、特定FacilityのWarning以上だけを取り込む、本番環境のみInfoを許可する、といった制御をコードで標準化できます。
ただし、過度に細かいフィルターを入れると、後からインシデント調査で必要なログが残っていない事態が起きます。コスト最適化と調査可能性のバランスを取り、最低でも初期導入期間は広めに取り込んで実績を見てから絞り込むのが安全です。
導入後の動作確認手順
Syslog/CEF AMAコネクタを設定した後は、ポータル上で「接続済み」に見えるだけで満足してはいけません。実際にログが届き、正しいテーブルに入り、検知ルールで使える状態になっているかを確認します。
基本的な確認の流れ
| 手順 | 確認内容 |
|---|---|
| サービス確認 | azuremonitoragent.service、rsyslog.serviceまたはsyslog-ng.serviceが動作している |
| 待ち受け確認 | ログフォワーダーが514番で待ち受けている |
| パケット確認 | 514番または28330番にログが流れている |
| テスト送信 | loggerやncでテストメッセージを送る |
| KQL確認 | SyslogまたはCommonSecurityLogで受信を確認する |
公式手順では、netstatやtcpdumpを使った確認、loggerやncによるテストメッセージ送信、Log AnalyticsでのKQL確認が案内されています。また、ログがワークスペースに表示されるまで最大20分程度かかる場合があります。(Microsoft Learn)
導入直後にログが表示されない場合、すぐに設定ミスと判断せず、次の順で切り分けると効率的です。
- ログソースからログフォワーダーにパケットが届いているか
- rsyslog/syslog-ngが受信しているか
- AMAが動作しているか
- DCRが対象VMに関連付けられているか
- FacilityとSeverityの条件で除外されていないか
- Log Analyticsワークスペースに遅延して表示されていないか
KQLでは、最初に広めの条件で確認します。
Syslog
| where TimeGenerated > ago(2h)
| summarize Count=count() by Computer, Facility, SeverityLevel
| order by Count descCEFの場合は、ベンダー名や製品名で確認します。
CommonSecurityLog
| where TimeGenerated > ago(2h)
| summarize Count=count() by DeviceVendor, DeviceProduct
| order by Count desc件数が出ているのに検知ルールが動かない場合は、ログの有無ではなく、フィールドの値、Severity、正規化、ルール側のKQL条件を確認してください。
Defenderポータル移行も同時に進めるべき理由
Syslog/CEF AMAコネクタの設定は、Microsoft Sentinelのデータコネクタ管理と密接に関係します。そのため、Azureポータルだけで作業手順を固めてしまうと、将来的な運用移行時に混乱します。
Microsoft SentinelはDefenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでサポートされなくなる予定です。現在AzureポータルでSentinelを運用している組織は、Syslog/CEF AMAの見直しと同時に、Defenderポータルでの操作導線も確認しておくべきです。(Microsoft Learn)
特に確認したい導線は次の通りです。
| Azureポータルでの機能 | Defenderポータルでの主な場所 |
|---|---|
| Data connectors | Microsoft Sentinel > Configuration > Data connectors |
| Analytics | Microsoft Sentinel > Configuration > Analytics |
| Incidents | Investigation & response > Incidents & alerts > Incidents |
| Hunting | Microsoft Sentinel > Threat management > Hunting |
| Workbooks | Microsoft Sentinel > Threat management > Workbooks |
| Watchlists | Microsoft Sentinel > Configuration > Watchlists |
ログ取り込みの設定担当者だけでなく、SOCの一次対応者、インシデント管理者、検知ルール作成者もDefenderポータルでの画面遷移を確認しておくと、移行後の運用停止リスクを下げられます。
よくある失敗と対策
Syslog/CEF AMAコネクタの導入では、細かな設定ミスが大きな運用トラブルにつながります。特に次の点は事前に潰しておきましょう。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| ログが入らない | DCRを作成したがVMに関連付けていない | DCR Associationを確認する |
| 一部のログだけ欠落する | FacilityまたはSeverityの条件で除外されている | 送信元機器のFacilityとDCR設定を突き合わせる |
| コストが急増する | SyslogとCEFで同じFacilityを取り込んでいる | Facility分離または取り込み時変換で重複排除する |
| 時系列調査がずれる | ログソースとフォワーダーのタイムゾーンが違う | NTP、UTC運用、調査手順を整備する |
| スクリプトが失敗する | Python 3はあるがpythonコマンドで呼べない | python3で実行する、または環境設定を修正する |
| AMAが不安定になる | rsyslog/syslog-ngが不要ログをローカル保存し続けている | 不要なローカル保存を止め、ディスク監視を入れる |
| Defenderポータル移行後に迷う | Azureポータル前提の手順書しかない | Defenderポータル版の運用手順書を作る |
導入直後は「ログが入ったか」だけを見がちですが、本当に見るべきなのは「必要なログだけが、正しいテーブルに、期待した粒度で、調査可能な形で入っているか」です。
まず管理者が取るべき次のアクション
Syslog and CEF AMA connectors – Microsoft Sentinelの更新内容を踏まえると、管理者が最初にやるべきことは明確です。
まず、現在のSyslog/CEF取り込み経路を棚卸ししてください。どの機器が、どのログフォワーダーへ、どのFacilityで、SyslogまたはCEFを送っているかを一覧化します。次に、DCRの設定を確認し、SyslogとCommonSecurityLogへの重複取り込みがないかをKQLで確認します。
そのうえで、MMAや古いコネクタ構成が残っている場合は、AMAとDCRを前提にした移行計画を立てます。あわせて、AzureポータルではなくMicrosoft Defenderポータル上で同じ操作ができるよう、管理者とSOC担当者の手順書を更新しておきましょう。
Syslog/CEFログは、インシデント対応の初動を左右する重要なデータです。今回の更新は、単なるコネクタ仕様の確認ではなく、Microsoft Defenderポータル時代のSentinel運用に向けて、ログ収集基盤を整理するタイミングと捉えるべきです。
コメント