Microsoft Sentinel 用の AMA コネクタを介した Syslog と Common Event Format (CEF)
Microsoft Sentinel の AMA 経由の Syslog データ コネクタと AMA 経由の Common Event Format (CEF) データ コネクタでは、Linux マシンから、またネットワークとセキュリティ デバイスおよびアプライアンスから、Common Event Format (CEF) のメッセージを含む Syslog メッセージをフィルター処理して取り込みます。 これらのコネクタにより、Syslog や CEF メッセージを収集する Linux マシンに Azure Monitor エージェント (AMA) がインストールされます。 このマシンは、メッセージの送信元の場合もあれば、ネットワークまたはセキュリティ デバイスとアプライアンスなどの他のマシンからメッセージを収集するフォワーダーの場合もあります。 コネクタは、ユーザーが定義するデータ収集ルール (DCR) に基づいてエージェントに指示を送信します。 DCR では、監視するシステムと、収集するログまたはメッセージの種類を指定します。 パフォーマンスを向上させ、クエリと分析の効率を高めるために、メッセージを取り込む前に適用するフィルターが定義されます。
Syslog と CEF は、さまざまなデバイスとアプリケーションからデータをログするための 2 つの一般的な形式です。 それらは、システム管理者とセキュリティ アナリストが、ネットワークの監視とトラブルシューティングを行い、潜在的な脅威やインシデントを特定するのに役立ちます。
Syslog とは
Syslog は、ネットワークを経由して異なるデバイス間またはアプリケーション間でメッセージを送受信するための標準プロトコルです。 もともとは Unix システム用に開発されましたが、現在ではさまざまなプラットフォームやベンダーによって広くサポートされています。 Syslog メッセージには、優先順位、タイムスタンプ、ホスト名、アプリケーション名、プロセス ID、メッセージ テキストで構成される定義済みの構造があります。 Syslog メッセージは、構成とセキュリティの要件に応じて、UDP、TCP、または TLS 経由で送信できます。
Azure Monitor エージェントでは、Syslog の RFC 3164 と 5424 がサポートされています。
Common Event Format (CEF) の概要
CEF (Common Event Format) は、ファイアウォール、ルーター、検出と対応ソリューション、侵入検出システムなどのネットワークとセキュリティのデバイスとアプライアンスから、および Web サーバーなどの他の種類のシステムからのデータをログするための、ベンダーに依存しない形式です。 Syslog を拡張したものであり、特にセキュリティ情報イベント管理 (SIEM) ソリューション用に開発されました。 CEF メッセージには、デバイスのベンダー、デバイス製品、デバイスのバージョン、イベント クラス、イベントの重大度、イベント ID などの情報を含む標準ヘッダーがあります。 CEF メッセージには、送信元と送信先の IP アドレス、ユーザー名、ファイル名、実行されたアクションなど、イベントに関するより詳しい情報を提供する可変数の拡張部分もあります。
AMA を使用した Syslog および CEF メッセージの収集
次の図は、Microsoft Sentinel での Syslog と CEF のメッセージ収集のアーキテクチャを示したものであり、AMA 経由の Syslog コネクタと AMA 経由の Common Event Format (CEF) コネクタを使っています。
この図は、Azure Monitor エージェント (AMA) がインストールされている単一の個々の Linux 仮想マシンから収集される Syslog メッセージを示したものです。
Azure Monitor エージェントを使用するデータ インジェスト プロセスでは、次のコンポーネントとデータ フローが使用されます。
ログ ソースは、Syslog メッセージを生成する、環境内のさまざまな Linux VM です。 これらのメッセージは、ローカル Syslog デーモンによって TCP または UDP ポート 514 (またはユーザー設定の別のポート) で収集されます。
ローカル Syslog デーモン (
rsyslogまたはsyslog-ng) は、TCP または UDP ポート 514 (またはユーザー設定の別のポート) でログ メッセージを収集します。 次にデーモンは、AMA のバージョンに応じて、2 つの異なる方法でこれらのログを Azure Monitor エージェントに送信します。- AMA バージョン 1.28.11 以降では、TCP ポート 28330 でログを受信します。
- これより前のバージョンの AMA では、Unix ドメイン ソケット経由でログを受信します。
Syslog と CEF のメッセージを受信するために 514 以外のポートを使う場合は、Syslog デーモンでのポート構成が、メッセージを生成するアプリケーションのものと一致していることを確認してください。
データ コネクタを設定して、Syslog メッセージ収集元の各 Linux VM にインストールする Azure Monitor エージェント。 エージェントはログを解析し、Microsoft Sentinel (Log Analytics) ワークスペースに送信します。
Microsoft Sentinel (Log Analytics) ワークスペース: ここに送信された Syslog メッセージは、最終的に Syslog テーブルに格納されます。そこでは、ログのクエリを実行し、ログの分析を実行して、セキュリティ上の脅威を検出して対応できます。
ログ メッセージを収集するためのセットアップ プロセス
Microsoft Sentinel のコンテンツ ハブから、Syslog または Common Event Format のための適切なソリューションをインストールします。 この手順では、AMA 経由の Syslog 各データ コネクタ、または AMA 経由の Common Event Format (CEF) データ コネクタをインストールします。 詳細については、「Microsoft Sentinel のすぐに利用できるコンテンツを検出して管理する」を参照してください。
セットアップ プロセスの一環として、データ収集規則を作成し、ログ フォワーダーに Azure Monitor エージェント (AMA) をインストールします。 これらのタスクは、Azure または Microsoft Defender ポータルを使用するか、Azure Monitor ログ インジェスト API を使用して実行します。
Azure または Microsoft Defender ポータルで Microsoft Sentinel のデータ コネクタを構成すると、ワークスペースごとに DCR を作成、管理、削除できます。 AMA は、コネクタ構成で選択した VM に自動的にインストールされます。
あるいは、ログ インジェスト API に HTTP 要求を送信します。 このセットアップでは、DCR を作成、管理、削除できます。 このオプションは、ポータルよりも柔軟です。 たとえば、API を使用すると、特定のログ レベルでフィルター処理できます。 Azure または Defender ポータルでは、最小ログ レベルのみを選択できます。 この方法を使用する場合の欠点は、DCR を作成する前に、ログ フォワーダーに Azure Monitor エージェントを手動でインストールする必要があることです。
DCR を作成し、AMA がインストールされたら、ログ フォワーダーで "インストール" スクリプトを実行します。 このスクリプトは、他のマシンからのメッセージをリッスンし、必要なローカル ポートを開くように Syslog デーモンを構成します。 次に、必要に応じてセキュリティ デバイスまたはアプライアンスを構成します。
詳細については、次の記事をご覧ください。
- Azure Monitor エージェントを使用して Syslog と CEF のメッセージを Microsoft Sentinel に取り込む
- AMA データ コネクタ経由の CEF - Microsoft Sentinel データ インジェスト用に特定のアプライアンスまたはデバイスを構成する
- AMA データ コネクタ経由の Syslog - Microsoft Sentinel データ インジェスト用に特定のアプライアンスまたはデバイスを構成する
データ インジェストの重複回避
Syslog メッセージと CEF メッセージの両方に同じ機能を使用すると、CommonSecurityLog テーブルと Syslog テーブル間でデータ インジェストが重複する可能性があります。
このシナリオを回避するには、次のいずれかの方法を使用します。
ソース デバイスでターゲット ファシリティの構成を有効にする場合: CEF 形式でログ フォワーダーにログを送信する各ソース マシンで、Syslog 構成ファイルを編集し、CEF メッセージの送信に使用されているファシリティを削除します。 これで、CEF で送信されるファシリティは、Syslog では送信されません。 構成する各 DCR で、CEF または Syslog の該当するファシリティがそれぞれ使用されていることを確認してください。
同じエージェントから Syslog と CEF 両方のメッセージを取り込むように DCR を調整する方法の例については、「同じ DCR での Syslog と CEF のストリーム」をご覧ください。
ソース アプライアンスでファシリティを変更できない場合: DCR を作成した後、取り込み時の変換を追加して Syslog ストリームから CEF メッセージを除外し、重複を回避します。 「チュートリアル: データ収集ルール (DCR) を編集する」を参照してください。 次の例のような KQL 変換を追加します。
"transformKql": " source\n | where ProcessName !contains \"CEF\"\n"