Microsoft SentinelでSyslogやCEFログを取り込んでいる組織が、2026年4月更新でまず確認すべき点は「AMA（Azure Monitor Agent）＋DCR（Data Collection Rule）を前提に、取り込み対象・ログレベル・重複・転送経路を見直すこと」です。特に、ファイアウォール、VPN、EDR、Linuxサーバー、ネットワーク機器のログをSentinelに集約しているsecurity admins、identity teams、compliance teamsは、コネクタ設定だけでなく、ログフォワーダー、ポート、RBAC、検証クエリまでセットで確認する必要があります。
2026年4月22日に更新されたMicrosoft Learnの「Ingest syslog and CEF messages to Microsoft Sentinel with the Azure Monitor Agent」は、Syslog via AMAとCommon Event Format（CEF）via AMAコネクタを使い、Linuxマシン、ネットワーク機器、セキュリティアプライアンスからMicrosoft Sentinelへログを取り込む手順を整理した公式ドキュメントです。この記事では、更新内容を実務目線で整理し、既存環境で何を確認すべきか、これから構成する場合にどこで失敗しやすいかを解説します。(Microsoft Learn)
Microsoft Sentinelの最新動向: Ingest syslog and CEF messages to Microsoft Sentinel – AMAで何が変わったか
今回の更新ポイントを一言でまとめると、Microsoft SentinelにおけるSyslog／CEF取り込みは、Azure Monitor Agentを中心にした設計へ明確に寄せられているということです。
公式ドキュメントでは、対象が「Microsoft Defender portalのMicrosoft Sentinel」と「Azure portalのMicrosoft Sentinel」の両方であることが示されています。つまり、Azure portalだけを前提にした運用ではなく、Defender portal側でSentinelを利用している組織も同じ観点で確認する必要があります。(Microsoft Learn)
特に重要なのは、単に「コネクタを有効化する」だけでは十分ではない点です。AMA、DCR、ログフォワーダー、facility、severity、Syslog／CEFの重複回避、取り込み後のKQL確認までを一連の運用として設計する必要があります。
| 確認項目 | 2026年4月更新で押さえるべき内容 | 実務での判断ポイント |
|---|---|---|
| 対象コネクタ | Syslog via AMA、Common Event Format（CEF）via AMA | 既存のレガシー構成ではなくAMAベースで設計する |
| 設定の中心 | DCR（Data Collection Rule） | どのログを、どのレベルで、どのワークスペースへ送るかをDCRで管理する |
| 構成方法 | Azure／Defender portal、またはLogs Ingestion API | 手作業中心ならポータル、自動化・細かな制御ならAPIを検討する |
| ログ転送 | Linuxのログフォワーダーを利用可能 | ネットワーク機器やセキュリティ製品はフォワーダー経由が現実的 |
| 重複対策 | SyslogとCEFで同じfacilityを使うと重複の可能性 | CommonSecurityLogとSyslogの二重取り込みを事前に防ぐ |
| 検証 | tcpdump、netstat、KQLで確認 | 「設定した」ではなく「Sentinelで検索できる」まで確認する |
今回の更新で最も重要なのは「AMA前提の取り込み設計」
Microsoft SentinelでSyslogやCEFを取り込む場合、現在の公式手順ではAzure Monitor Agentが前提になります。Syslog via AMAとCEF via AMAのコネクタは、LinuxマシンやログフォワーダーにAMAを導入し、DCRで収集条件を定義してMicrosoft SentinelのLog Analyticsワークスペースへ送信する構成です。(Microsoft Learn)
ここで重要なのは、AMAが単なるエージェント置き換えではないことです。従来の「マシンにエージェントを入れて、ワークスペースに送る」という考え方から、「DCRで収集対象と条件を明示し、必要なログだけを送る」設計に変わります。
セキュリティ運用では、ログの取りこぼしも問題ですが、不要なログの取り込みすぎも問題です。特にグローバル環境では、ファイアウォール、プロキシ、VPN、Linuxサーバー、ID関連システムから大量のSyslog／CEFが送られるため、facilityとseverityの設計がコスト、検索性能、インシデント対応速度に直結します。
Syslog via AMAとCEF via AMAの使い分け
Syslog via AMAとCEF via AMAは似ていますが、取り込まれるデータの扱いが異なります。実務では「どちらのコネクタを使うか」よりも、「どのログ形式で、どのテーブルに入るか」を先に確認するのが安全です。
| 項目 | Syslog via AMA | CEF via AMA |
|---|---|---|
| 主な用途 | Linuxサーバー、ネットワーク機器、一般的なSyslogログ | セキュリティ製品、SIEM向け形式のログ |
| 主なデータ形式 | Syslog | Common Event Format（CEF） |
| 代表的な格納先 | Syslogテーブル | CommonSecurityLogテーブル |
| 向いている例 | Linux認証ログ、システムログ、ネットワーク機器ログ | Firewall、IDS/IPS、EDR、VPN、セキュリティアプライアンス |
| 注意点 | facilityとseverityの選定が重要 | CEF形式の崩れ、フィールドマッピング、重複に注意 |
CEFはSyslogを転送手段として使うことがあります。そのため、同じログが「CEFとしてCommonSecurityLogに入る」と同時に「SyslogとしてSyslogテーブルに入る」可能性があります。Microsoft Learnでも、SyslogとCEFで同じfacilityを使うとデータ取り込みの重複が起きる可能性があると説明されています。(Microsoft Learn)
実務では、次のように切り分けると判断しやすくなります。
- セキュリティ製品がCEF形式に対応しているなら、原則としてCEF via AMAを優先する
- Linux OSや一般的なシステムログはSyslog via AMAで扱う
- 同じ機器からCEFと通常Syslogの両方を送る場合は、facilityを分ける
- facilityを分けられない製品では、DCRの変換やフィルターで重複排除を検討する
DCRでfacilityとseverityを設計する
Microsoft SentinelのSyslog／CEF取り込みで失敗しやすいのが、facilityとseverityを深く考えずに有効化することです。
公式手順では、DCR作成時にfacilityごとの最小ログレベルを選択します。たとえば、LOG_ERRを選ぶと、LOG_ERRだけでなく、より重大度の高いLOG_CRIT、LOG_ALERT、LOG_EMERGも収集対象になります。(Microsoft Learn)
これは一見便利ですが、選び方を誤ると次の問題が起きます。
| よくある設定ミス | 起きる問題 | 対策 |
|---|---|---|
| すべてのfacilityを有効にする | 取り込み量が増え、コストとノイズが増える | 本番では必要なfacilityに絞る |
| severityを低くしすぎる | InfoやNoticeが大量に入り、重要アラートが埋もれる | 初期検証後にWarning以上などへ調整する |
| CEFとSyslogで同じfacilityを使う | CommonSecurityLogとSyslogに重複する可能性 | CEF用とSyslog用でfacilityを分ける |
| 機器側のfacilityを確認しない | Sentinel側で待ち受けてもログが入らない | 機器設定、フォワーダー設定、DCRを突き合わせる |
最初の検証段階では広めに収集しても構いません。ただし、本番運用に入る前に「どのログが検知ルール、調査、監査に必要か」を基準に絞り込むべきです。
たとえば、セキュリティ管理者は脅威検知に必要なFirewall deny、VPN login、IDS alertを優先します。IDチームは認証失敗、権限昇格、管理者操作に関係するログを重視します。コンプライアンスチームは、監査証跡として保存すべきログと、日次調査には不要なログを分けて考える必要があります。
ログフォワーダーを使う場合の前提条件
ネットワーク機器やセキュリティアプライアンスのログをMicrosoft Sentinelへ送る場合、多くの環境ではログフォワーダーを使います。公式ドキュメントでは、ログフォワーダーとしてLinux VMを用意し、Azure外のマシンであればAzure Arc Connected Machine agentが必要になると説明されています。また、Python 2.7または3、rsyslogまたはsyslog-ngも前提条件として挙げられています。(Microsoft Learn)
ログフォワーダーを設計するときは、次の観点を事前に決めておくとトラブルを減らせます。
| 設計項目 | 推奨される確認内容 |
|---|---|
| 配置場所 | オンプレミス、Azure、他クラウドのどこに置くか |
| 可用性 | 単一VMでよいか、複数台構成にするか |
| 通信経路 | ログ送信元からフォワーダー、フォワーダーからAzureへの疎通 |
| プロトコル | UDP、TCP、TLSのどれを使うか |
| 容量 | ピーク時のEPS、ディスク、CPU、メモリ |
| 運用 | パッチ適用、監視、ログローテーション、ディスク枯渇対策 |
特に注意したいのがディスクです。公式ドキュメントでは、不要なログを保存しないようsyslog-ngやrsyslogの設定を行うことが推奨されています。ディスクフルになると、インストール済みのAMAが正常に機能しなくなる可能性があります。(Microsoft Learn)
ポート514と28330を理解しておく
Syslog／CEF取り込みのトラブルでは、ポートの理解不足がよく原因になります。
ログソースからログフォワーダーへは、一般的にTCPまたはUDPの514番ポートで送信します。一方、AMA 1.28.11以降では、SyslogデーモンからAMA側へTCP 28330番ポートでログが渡されます。以前のAMAバージョンではUnix domain socketが使われるため、バージョン差も確認が必要です。(Microsoft Learn)
構成を確認するときは、次の流れで見ると切り分けしやすくなります。
| 区間 | 主な確認ポイント |
|---|---|
| ログソース → ログフォワーダー | 機器の送信先IP、514番ポート、UDP/TCP、Firewall、NSG |
| ログフォワーダー内 | rsyslogまたはsyslog-ngが514番で待ち受けているか |
| Syslogデーモン → AMA | AMAが28330番で受け取れる構成か |
| AMA → Azure | Azure Monitor／Log Analyticsへのアウトバウンド通信が可能か |
| Sentinel側 | SyslogまたはCommonSecurityLogテーブルに到達しているか |
公式のテスト手順では、netstatで待ち受けを確認し、tcpdumpで514番または28330番の通信を確認する方法が示されています。テストメッセージ送信後、Log Analyticsワークスペースに表示されるまで最大20分程度かかる場合がある点も押さえておきましょう。(Microsoft Learn)
Azure／Defender portalとLogs Ingestion APIの選び方
DCRの作成方法には、ポータルを使う方法とLogs Ingestion APIを使う方法があります。公式ドキュメントでは、Azure portalまたはMicrosoft Defender portalからDCRを作成する手順に加え、Azure Monitor Logs Ingestion APIを使ってDCRを作成・関連付ける手順も示されています。(Microsoft Learn)
どちらを選ぶべきかは、運用規模と自動化要件で判断します。
| 方法 | 向いている環境 | メリット | 注意点 |
|---|---|---|---|
| Azure／Defender portal | 小規模、初回構築、単一ワークスペース | 画面操作で分かりやすい。AMAの導入も流れで進めやすい | 大規模展開や細かな標準化には向きにくい |
| Logs Ingestion API | 大規模、複数リージョン、IaC運用 | DCRをJSONで管理でき、標準化しやすい | AMA導入やDCR関連付けを正確に管理する必要がある |
グローバル環境では、APIやInfrastructure as Codeに寄せたほうが運用しやすいケースが多くなります。たとえば、日本、米国、欧州で同じ種類のファイアウォールを使っている場合、DCRの命名規則、facility、severity、送信先ワークスペースをコードで標準化できます。
一方、初回検証ではポータルを使ったほうが構成の流れを理解しやすく、トラブル時の切り分けもしやすくなります。おすすめは、検証環境でポータル構成を理解し、本番展開ではAPIやテンプレートに落とし込む進め方です。
security adminsが確認すべきポイント
security adminsにとって最も重要なのは、検知に必要なログが正しいテーブルに入り、分析ルールやハンティングで使える状態になっているかです。
CEFログは多くの場合、CommonSecurityLogテーブルに入ります。Firewall、IDS/IPS、VPN、プロキシなどのセキュリティ製品ログを扱う場合、DeviceVendor、DeviceProduct、DeviceAction、送信元／宛先IP、ユーザー名などが期待通りにマッピングされているか確認しましょう。
検証用のKQL例は次のとおりです。
CommonSecurityLog
| where TimeGenerated > ago(24h)
| summarize Count = count() by DeviceVendor, DeviceProduct
| order by Count desc特定製品のログが入っているか確認する場合は、次のように絞り込みます。
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor has "Cisco" or DeviceProduct has "ASA"
| take 50Syslogログの場合は、Syslogテーブルを確認します。
Syslog
| where TimeGenerated > ago(24h)
| summarize Count = count() by Computer, Facility, SeverityLevel
| order by Count descここで重要なのは、件数が多いことを成功と見なさないことです。検知に使えないInfoログが大量に入っている場合、コストが増えるだけでなく、調査時のノイズも増えます。
identity teamsが見るべきポイント
identity teamsは、認証・認可・管理者操作に関連するログが欠けていないかを確認する必要があります。
Microsoft Entra IDのログだけでは、ネットワーク機器やVPN装置、Linuxサーバー上の認証イベントまで完全には見えない場合があります。たとえば、VPN装置がCEFでログを出力している場合、ユーザー名、送信元IP、認証結果、接続先、セッションIDがCommonSecurityLog上で確認できるかが重要です。
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| ユーザー識別 | UPN、samAccountName、装置独自のユーザー名が取得できているか |
| 送信元情報 | グローバルIP、端末IP、国・地域判定に使える情報があるか |
| 認証結果 | 成功、失敗、拒否、MFA関連のイベントが区別できるか |
| 管理者操作 | 管理コンソールへのログインや設定変更が記録されるか |
| 相関分析 | Entra ID、Defender、Sentinel上の他ログと結合できるか |
実務では、ID侵害の調査時に「クラウドIDのログ」と「ネットワーク境界のログ」を突き合わせます。したがって、ログ取り込み設計の段階で、ユーザー名やIPアドレスが検索可能な形式で入るかを確認しておくことが重要です。
compliance teamsが確認すべきポイント
compliance teamsにとっては、ログが入ることだけでなく、監査で説明できる状態になっていることが重要です。
Microsoft SentinelにSyslog／CEFを取り込む場合、次のような観点で確認すると監査対応がしやすくなります。
| 監査観点 | 確認すべき内容 |
|---|---|
| 収集範囲 | どの機器、どのログ種別、どのseverityを収集しているか |
| 保存先 | どのLog Analyticsワークスペースに保存しているか |
| 変更管理 | DCRの変更履歴、承認フロー、設定変更者 |
| 証跡確認 | 実際にクエリで対象ログを抽出できるか |
| 重複・欠損 | 二重取り込みや未取り込みがないか |
| タイムゾーン | EventTimeとTimeGeneratedの差異を説明できるか |
特にグローバル企業では、ログの時刻が問題になりやすいです。公式の概要ドキュメントでは、ログフォワーダーを使う場合、TimeGeneratedとEventTimeの間に差異が出る可能性があると説明されています。TimeGeneratedはログフォワーダーまたはコレクターで処理されたUTC時刻、EventTimeはSyslogヘッダーから抽出された時刻を基に扱われます。(Microsoft Learn)
監査レポートやインシデント報告では、「いつ発生したか」と「いつSentinelに取り込まれたか」を混同しないようにしましょう。
既存環境で今すぐ確認したいチェックリスト
すでにMicrosoft SentinelでSyslog／CEFを取り込んでいる場合は、次のチェックリストで現状を確認してください。
| チェック | 確認内容 |
|---|---|
| コネクタ | Syslog via AMAまたはCEF via AMAを使っているか |
| エージェント | ログフォワーダーにAzure Monitor Agentが導入されているか |
| DCR | DCRが正しいマシンに関連付けられているか |
| facility | CEF用とSyslog用で重複しない設計になっているか |
| severity | 本番運用に必要なログレベルだけを収集しているか |
| ポート | 514番、28330番、Azure向け通信が通っているか |
| テーブル | CEFはCommonSecurityLog、SyslogはSyslogに入っているか |
| 検知ルール | 既存の分析ルールが新しい取り込みログで動作するか |
| コスト | 不要なInfoログや重複ログで取り込み量が増えていないか |
| 監査 | DCRの設定内容を証跡として説明できるか |
この中で特に優先度が高いのは、DCR、facility、重複、KQL確認です。見た目上コネクタが有効でも、DCRの関連付けが誤っていればログは入りません。また、ログが入っていても重複していればコストと調査ノイズが増えます。
新規構築時のおすすめ手順
これからMicrosoft SentinelにSyslog／CEFを取り込む場合は、いきなり本番機器を大量接続するのではなく、小さく検証してから広げるのが安全です。
| 手順 | 作業内容 | 成功条件 |
|---|---|---|
| 事前整理 | 対象機器、ログ形式、facility、severityを一覧化 | 収集対象と不要ログが分かれている |
| コネクタ確認 | Content hubで必要なソリューションとコネクタを確認 | Syslog via AMAまたはCEF via AMAが利用できる |
| フォワーダー準備 | Linux VM、Arc、Python、rsyslog／syslog-ngを準備 | AMAを導入できる状態になっている |
| DCR作成 | ポータルまたはAPIでDCRを作成 | 対象VMにDCRが関連付いている |
| 機器設定 | ログ送信先をフォワーダーに設定 | 514番でログが到達する |
| 疎通確認 | tcpdumpやnetstatで確認 | フォワーダーでログ受信を確認できる |
| Sentinel確認 | KQLでCommonSecurityLog／Syslogを確認 | 期待したログが検索できる |
| チューニング | facility、severity、重複を調整 | コストとノイズを抑えた状態になる |
| 本番展開 | 対象機器を段階的に追加 | 検知ルールと監査要件を満たす |
最初の1台では、あえてログレベルを広めにして流入を確認しても構いません。ただし、その設定を本番標準にしないことが重要です。検証後は、検知・調査・監査に必要なログへ絞り込みましょう。
失敗しやすいポイントと対策
Microsoft SentinelのSyslog／CEF取り込みでは、設定箇所が複数あるため、問題が起きたときに原因を見誤りやすくなります。
| 症状 | よくある原因 | 対策 |
|---|---|---|
| Sentinelにログが出ない | 機器が別IPへ送信している | 機器側の送信先とフォワーダーIPを確認 |
| 514番に通信が来ない | Firewall、NSG、ACLで遮断 | tcpdumpで到達有無を確認 |
| フォワーダーには来るがSentinelに出ない | AMA、DCR、Azure向け通信の問題 | AMAサービス、DCR関連付け、アウトバウンド通信を確認 |
| CEFの列が期待通りに入らない | CEFフォーマット不備 | CEFヘッダー、区切り文字、エスケープを確認 |
| ログが重複する | SyslogとCEFで同じfacilityを収集 | facility分離またはDCR変換で除外 |
| コストが急増する | Infoログや不要facilityを取り込みすぎ | severityとfacilityを見直す |
| 時刻がずれる | 送信元、フォワーダー、UTC変換の差異 | TimeGeneratedとEventTimeを区別する |
トラブル対応では、いきなりSentinel側だけを見るのではなく、ログソース、ネットワーク、ログフォワーダー、AMA、DCR、Log Analyticsの順に確認するのが近道です。
2026年4月更新を受けた実務上のアクション
今回のMicrosoft Learn更新を受けて、既存環境の管理者が取るべき行動は明確です。
まず、Microsoft SentinelのSyslog／CEF取り込みがAMAベースになっているか確認してください。次に、DCRの設定を見直し、facilityとseverityが現在の検知・監査要件に合っているか確認します。さらに、SyslogとCEFの重複取り込みがないか、CommonSecurityLogとSyslogの両方をKQLで確認しましょう。
新規構築の場合は、ポータルで小さく検証し、その後DCRを標準化してAPIやテンプレートによる展開へ進めるのが現実的です。security adminsは検知精度、identity teamsは認証ログの相関、compliance teamsは収集範囲と証跡説明を重視して設計すると、運用後の手戻りを減らせます。
Microsoft SentinelのSyslog／CEF取り込みは、コネクタを有効化した時点で完了ではありません。ログが正しい形式で入り、必要なテーブルに格納され、検索・検知・監査に使える状態になって初めて完了です。2026年4月更新を機に、AMA、DCR、ログフォワーダー、重複対策、検証クエリをまとめて棚卸ししておきましょう。
コメント