SIEMとは？ログ監視の仕組みと小さく始める方法（Wazuhの位置づけ）

SIEMとは、サーバー・ネットワーク機器・クラウドサービスなどのログを1か所に集めて形式をそろえ、複数のログを組み合わせたルールで不審な動きを検知し、警告と調査の材料を出す仕組みです。Security Information and Event Managementの略で、「シーム」と読みます。ログを保管して検索するだけの仕組みとの違いは、形式の統一（正規化）と、複数の出来事を関連付ける検知（相関分析）にあります。

この記事では、SIEMの中でログがどう処理されるかを、オープンソースのWazuhを検証用のコンテナで動かした結果で具体的に示します。そのうえで、SOC・XDR・SOARとの違い、導入が必要な組織とまだ早い組織の見分け方、ログ量と保管期間から規模を見積もる方法、Wazuhで小さく始めるときの位置づけと注意点を整理します。

SIEMとは：ログ管理との違い

ログ管理の仕組みは、ログを集めて保管し、後から検索できるようにします。SIEMはそこに2つの処理を足します。1つは正規化で、Linuxのsshd、WindowsのイベントログやVPN装置のログなど書式の違うログから、送信元IPアドレス・ユーザー名・結果といった共通の項目を取り出します。もう1つは相関分析で、「同じ送信元から短時間に何度も失敗し、その後に成功した」のように、1行だけでは判断できない出来事の並びを検知します。

この差が効くのは、1つ1つは正常に見えるログの組み合わせに意味があるときです。VPNへのログインが深夜の海外から成功し、その直後にファイルサーバーで大量のアクセスがあった、という流れは、VPN装置とファイルサーバーのログを別々に見ていては気づけません。複数の機器のログを同じ時計・同じ項目名で並べられることが、SIEMの価値の中心です。

仕組み：収集・正規化・相関・警告・保管

Wazuh 4.14.8のマネージャーを検証用のコンテナで起動し、付属の wazuh-logtest にsshdのログを1行与えると、処理が3段階で進むのが見えました。次はその出力の抜粋です。

**Phase 1: Completed pre-decoding.
	full event: 'Sep 23 23:25:01 web01 sshd[2211]: Failed password for invalid user admin from 203.0.113.50 port 51234 ssh2'
	timestamp: 'Sep 23 23:25:01'
	hostname: 'web01'
	program_name: 'sshd'
**Phase 2: Completed decoding.
	name: 'sshd'
	parent: 'sshd'
	srcip: '203.0.113.50'
	srcuser: 'admin'
**Phase 3: Completed filtering (rules).
	id: '5710'
	level: '5'
	description: 'sshd: Attempt to login using a non-existent user'
	groups: '['syslog', 'sshd', 'authentication_failed', 'invalid_login']'
	mitre.id: '['T1110.001', 'T1021.004']'
	pci_dss: '['10.2.4', '10.2.5', '10.6.1']'
**Alert to be generated.

Phase 1で日時・ホスト名・プログラム名を切り出し、Phase 2のデコーダーが送信元IPアドレス（srcip）とユーザー名（srcuser）を取り出しています。これが正規化です。Phase 3でルール5710（重要度を表すレベルは5）に一致し、MITRE ATT&CKの手法番号や、PCI DSSの要件番号といった分類も付きました。

相関は次の段階です。同じ送信元から存在しないユーザー名での失敗を10行続けて与えると、7行目まではルール5710のままで、8行目でルール5712（レベル10、総当たりの検知）に変わりました。5712は「5710が同じ送信元IPアドレスから120秒以内に8回」という条件のルールです。さらに、実在するユーザーへの失敗を9回与えた後に同じ送信元からの成功を与えると、ルール40112「複数回の認証失敗の後の成功」（レベル12）が出ました。1行ずつならレベル5と3の出来事が、並びとして見るとレベル12になる、というのが相関分析です。

警告と保管の段階では、どのレベル以上を記録し、どのレベル以上を通知するかが設定で決まります。Wazuh 4.14.8の既定の設定ファイル（ossec.conf）では、警告として記録するのがレベル3以上（log_alert_level）、メールで通知するのがレベル12以上（email_alert_level）でした。付属のルールファイルは168個あり、その中のルール定義（<rule id= の行）を数えると4,515個でした。

Wazuhの既定の設定では、ルールに一致した警告だけが保存され、ログの全行は保存されません（logall が no）。インシデントの調査では、警告にならなかったログの前後関係が必要になることが多いので、「全ログを何日分残すか」は導入時に決めてください。全行の保存を有効にすると、保存容量は警告だけの場合より大きく増えます。

SIEMとSOC・XDR・SOARの違い

よく混同されるのはSOCとSIEMです。SIEMは警告を出すところまでで、その警告を見て「本物か」「どう動くか」を決めるのは人です。警告を見る人がいないまま導入したSIEMは、ディスクを埋めるだけの仕組みになります。EDRを軸にしたXDRとの関係は、EDRとは？の記事で扱っています。

SIEMが必要になる場面、まだ要らない場面

判断の軸は「調べたいときにログが残っているか」と「警告に反応する人がいるか」の2つです。前者だけが問題なら、まずはログを安く長く保管する仕組み（ログ管理）で足ります。両方がそろって初めて、相関分析を含むSIEMの投資が回収できます。インシデント対応の体制から整える場合は、CSIRTの作り方を先に読むと、SIEMの警告を誰が受けるかを決めやすくなります。

費用と規模の見積もり方

SIEMの費用は、取り込むログの量（1日あたりのGB数や、1秒あたりのイベント数＝EPS）と、保管期間でほぼ決まります。商用のSIEMは取り込み量やノード数に応じた課金が多く、オープンソースでもストレージとサーバーの費用は同じ考え方で増えます。見積もりの前に、今のログ量を実際に測ります。

# Linux：ローテーションされたログを含めた、1日分の大きさの目安
sudo ls -lh /var/log/nginx/access.log* /var/log/auth.log*

# Windows（PowerShell）：セキュリティログの現在のサイズと件数
Get-WinEvent -ListLog Security | Select-Object LogName, RecordCount, FileSize, MaximumSizeInBytes

計算は単純です。例として、取り込むログが1日5GBなら、直近90日分をすぐ検索できる状態に置くのに450GB、1年分を保管するなら約1.8TB（いずれも圧縮前）が必要です。保管の多くは圧縮できますが、検索用の索引で容量が増える製品もあるので、候補の製品で1週間分を実際に取り込み、1日あたりの消費量を測ってから見積もるのが確実です。取り込み課金の製品では、デバッグログや、監視ツールの死活確認のように量が多くて価値の低いログを、取り込む前に除外するだけで費用が大きく変わります。

Wazuhの位置づけ

Wazuhは、SIEMとXDRの機能をまとめたオープンソースのセキュリティ基盤で、ライセンスはGPLv2です。端末に入れるエージェント、ログを解析するマネージャー（サーバー）、警告を保存・検索するインデクサー、画面を提供するダッシュボードの4つで構成されます。執筆時点のDocker Hubでは4.14系が最新の安定版で、5.0はベータ版として公開されていました。

ログの相関だけでなく、ファイル改ざんの検知、CISベンチマークに沿った設定の点検、端末のソフトウェアからの脆弱性の検出まで1つの仕組みで扱えるのが、小さな組織にとっての利点です。検証ではマネージャー単体のメモリ使用量が約350MBでしたが、インデクサーはJavaで動くOpenSearch系のサービスで、これより桁違いに多くのメモリとディスクを使います。公式のクイックスタートには、エージェント数ごとのCPU・メモリ・ディスクの目安が載っているので、構成はそれに沿って決めます。

インデクサーとダッシュボードには、社内のログと警告のすべてが集まります。インターネットから直接アクセスできる場所に置かず、ダッシュボードはVPNや社内ネットワークの内側からだけ開けるようにしてください。インストール時に作られる管理者のパスワードは、作業用のファイルに残ったままにせず、パスワードマネージャーに移してファイルは削除します。

Wazuhを選ばないほうがよい場合もあります。すでにMicrosoft 365 E5のような統合製品を使っていて検知が足りているなら、別のSIEMを増やすより、その製品の警告を見る体制づくりが先です。ルールの調整やインデクサーの容量管理を自分たちで回せない場合も、運用込みで提供される商用のサービスのほうが結果的に安く済むことがあります。

小さく始める手順

1. 検知したいことを3つに絞る：たとえば「管理者アカウントの不審なログイン」「リモートアクセスの総当たりと成功」「管理者権限の追加」。目的が決まらないと、取り込むログも決まりません。
2. 取り込むログを決める：Entra IDのサインインログ、ドメインコントローラーのセキュリティログ、VPN装置やファイアウォールのログ、公開サーバーの認証ログから始めます。
3. 最初のルールを少数に：Windowsならイベント4625（ログオン失敗）の連続と4624（成功）の組み合わせ、4740（アカウントのロックアウト）、4720（アカウントの作成）、4732（ローカルのセキュリティグループへの追加）、1102（監査ログの消去）を起点にします。
4. 保管期間と全ログの扱いを決める：すぐ検索できる期間と、圧縮して残す期間を分けて決め、容量を見積もります。
5. 週1回のレビュー：出た警告を「本物」「誤検知」「情報のみ」に分け、誤検知はルールの除外で、情報のみは通知レベルの見直しで減らします。

導入直後に警告が多すぎて誰も見なくなるのが、SIEMで最も多い失敗の形です。通知は総当たりの成功や管理者権限の追加のような、見たら必ず手を動かすものだけに絞り、それ以外はダッシュボードで週1回まとめて見る、という分け方から始めてください。Linuxサーバーの攻撃元を自動で遮断したい場合は、SIEMで検知してから人が判断するより、CrowdSecのように遮断まで行う仕組みを並べて使うほうが速く効きます。

よくある質問

SIEMとは何ですか？

サーバーやネットワーク機器、クラウドサービスのログを1か所に集め、形式をそろえたうえで、複数のログを関連付けるルールで不審な動きを検知して警告する仕組みです。Security Information and Event Managementの略で「シーム」と読みます。調査のためのログの保管と検索も担います。

SOCとSIEMの違いは何ですか？

SIEMはログを集めて警告を出す仕組み（製品やサービス）で、SOCはその警告を監視・分析して本物かどうかを判断する人と体制です。SIEMはSOCが使う道具の1つで、警告を見る人がいなければSIEMは機能しません。SOCを自社で持てない組織は、外部の監視サービスに委託します。

SIEMはなぜ必要なのか？

1つの機器のログだけでは判断できない攻撃の流れを、複数のログを並べて見つけるためと、調査や監査に必要な期間のログを確実に残すためです。クラウドサービスのログは保存期間が短いことが多く、インシデントに気づいたときには消えている、という事態を防ぐ役割もあります。

SIEMのOSSには何がありますか？

代表的なのはWazuhで、ログの相関に加えてファイル改ざんの検知や脆弱性の検出まで扱えます。ほかに、Graylogのようなログ管理から出発したものや、OpenSearchのセキュリティ分析機能などがあります。ライセンスと、無償版で使える機能の範囲はプロジェクトごとに違うので、導入前に確認してください。

まとめ

SIEMの中身は、正規化で共通の項目を取り出し、相関分析で出来事の並びを検知することです。Wazuhの検証でも、レベル5の失敗が8回そろってレベル10になり、失敗の後の成功がレベル12になりました。導入は「ログが残っているか」と「警告を見る人がいるか」で判断し、規模はログ量と保管期間から見積もります。Wazuhで始めるなら、既定では警告しか残らないこと、インデクサーの容量と公開範囲の管理が要ることを前提に、検知したいこと3つから小さく始めてください。

次に読む

• CSIRTとは？小さな組織で作るインシデント対応チームの現実解
• CrowdSecで不正アクセスを自動ブロックする：fail2banとの違いと導入手順