【入門編】 SIEM(Security Information and Event Management)を用いたログ集約と自動相関 – インシデントレスポンス & フォレンジック(DFIR)防御ガイド

皆さん、こんにちは!インシデントレスポンスやデジタルフォレンジックの世界へようこそ。
日々の開発やインフラの管理、本当にお疲れ様です。「セキュリティ」という言葉を聞くと、何だか難しそうだな、専門家だけの特別な世界なのかな……と身構えてしまいますよね。でも、安心してください。セキュリティの基本は、私たちが普段暮らしている現実世界の防犯とまったく同じなんです。

今回は、分散しがちなセキュリティのログを集めて、まるで優秀な見張り番のように自動で危険を見つけ出してくれる「SIEM(シム)」と、そのログ集約・自動相関の仕組みについて、一緒に優しく紐解いていきましょう!

—

1. なぜログの集約が必要なの?(お家の防犯カメラに例えてみよう)

想像してみてください。あなたは一戸建ての大きなお家に住んでいます。
このお家には、玄関、勝手口、窓、そして裏庭の通用口と、出入り口がたくさんありますよね。それぞれの場所に「防犯カメラ」と「鍵の開け閉めを記録するノート」が置いてあるとします。

もし泥棒が入ろうとしたとき、次のようなことが起きたらどうでしょう?

  • 玄関のノートには「12:00 誰かがドアノブをガチャガチャした」と書いてある。
  • 勝手口のカメラには「12:01 窓ガラスをコンコンと叩く影が映った」と記録されている。
  • 裏庭のセンサーには「12:02 足音がした」と反応している。

これらがバラバラの場所に記録されていて、それぞれ別のノートに書かれていたらどうでしょうか? 「ただのイタズラかな?」「風の音かな?」と見過ごしてしまいますよね。

これをITの世界に置き換えてみましょう。
Webサーバー、データベース、ファイアウォール、クラウドの管理画面……。システムが大きくなればなるほど、ログ(記録)が出力される場所はバラバラになります。攻撃者はこの「バラバラさ」の隙をついて、あちこちで少しずつ怪しい動き(パスワード総当たりや、ちょっとした侵入テストなど)を仕掛けてきます。

だからこそ、「すべての場所の記録を一箇所に集めて、時系列でつき合わせる」ことが必要になります。これが、今回お話しするSIEM(Security Information and Event Management)の役割なんです!

—

2. SIEMによる「ログ集約」と「自動相関」の仕組み

SIEMは、いわば「お家のすべての防犯カメラとセンサーの映像を、リビングの巨大モニターにまとめて映し出し、さらに怪しい動きがあったら自動でパトランプを回してくれる超優秀な警備システム」です。

ログ集約(Collecting)

まずは、あちこちにあるログをSIEMというお山に集めます。
例えば、Linuxサーバーの認証ログや、Webアプリケーションのエラーログ、クラウド(AWSやGCPなど)のアクセスログを、専用のエージェントや転送ツールを使ってリアルタイムに集約します。

自動相関(Correlation)

ここがSIEMの最もすごいところです。集めたバラバラのログを「相関ルール」という基準で組み合わせて分析します。
「あれ? さっきから日本とは違う遠い国のIPアドレスから、このユーザー名でログイン失敗が5回続いて、その直後に管理者権限の変更が起きていないか?」といった、単体のログでは見えない『攻撃のストーリー』を自動で見つけ出してくれるのです。

—

3. 実践!SIEMに送るためのログ設定とルール例

では、実際に現場でどのように設定されているのか、少しだけコードを覗いてみましょう。難しく考えず、「こういう風にルールを書くんだな」という雰囲気だけ掴んでもらえればバッチリです!

例1:Linuxの認証ログを転送する設定(Fluentdの例)

まずは、サーバーのログイン失敗などの重要なログをSIEMに集めるための設定ファイル(一部抜粋)です。

# サーバーのセキュリティログ(auth.log)を読み込む設定
<source>
  @type tail
  path /var/log/auth.log
  tag linux.auth
  <parse>
    @type syslog
  </parse>
</source>

# 読み込んだログを中央のSIEMサーバー(例: Elasticsearchなど)に飛ばす設定
<match linux.auth>
  @type forward
  <server>
    name siem_server_01
    host 192.168.100.50  # SIEMのIPアドレス
    port 24224
  </server>
</match>

*ポイント:サーバーで何か怪しいログインエラー(Failed passwordなど)が起きると、この設定によって瞬時に中央のSIEMへとログが吸い上げられます。*

—

例2:SIEMでの「自動相関ルール」のイメージ(疑似コード)

SIEM側では、次のようなルールを設定して悪意あるアクセスを検知します。ここでは例として、よく使われるオープンソースのSIEM(SigmaやElastic SIEMなど)に近い概念で説明しますね。

title: 短時間での連続ログイン失敗と権限昇格の検知
id: rule-001-brute-force
status: experimental
description: 同一ユーザーに対して短時間に複数回のログイン失敗が発生し、その直後に成功した場合にアラートを飛ばす

# 1. 検出したい条件の定義
detection:
  selection_fail:
    event_type: "login_failed"
    timeframe: "5m"      # 5分間という時間枠
    count: 5             # 5回以上発生したら
  
  selection_success:
    event_type: "login_success"
    
  # 上記の失敗が起きたあとに成功が起きたストーリーを結合(相関)
  condition: selection_fail followed by selection_success

# 2. 検知したときの優先度
level: high

このように、「5分以内に5回以上パスワードを間違えたあとに、ログインに成功した」という一連の流れ(相関)をルールとして定義しておくことで、ただのパスワード忘れなのか、それとも総当たり攻撃(ブルートフォース攻撃)に成功してしまった不正アクセスなのかを自動で判断できるようになります。

—

4. 現場のシニアから一言:アラートの「嵐」に溺れないために

私たちがインシデントレスポンスの現場に入ると、よくお客様からこんな相談を受けます。
「SIEMを導入したはいいけれど、毎日何千件もアラートが出てきて、どれが本当の攻撃なのか分からないんです……!」

そうなんです。SIEMはとても優秀ですが、初期状態のままだと「普通の社員がちょっとパスワードを打ち間違えただけ」のログでも高感度に拾ってしまい、アラートの山に埋もれてしまいます。

だからこそ、一歩ずつ進めることが大切です。
1. まずは自社のシステムにとって「絶対に起きてはいけないこと(例:深夜の管理者権限変更、海外からの異常なアクセス)」を明確にする。
2. そのイベントに特化したシンプルな相関ルールから導入する。
3. 実際にアラートが出たら、それが「本物の攻撃(True Positive)」なのか「ただの誤検知(False Positive)」なのかをチューニングしていく。

この泥臭いチューニングの繰り返しこそが、強固なセキュリティ体制を作る最短の近道なんですよ。

—

5. おわりに

いかがでしたでしょうか?
SIEMによるログ集約と自動相関は、広大で複雑なITインフラというお家を守るための、なくてはならない「頼もしい警備システム」です。

最初から完璧な仕組みを作る必要はありません。「まずはサーバーのログを集めてみるか」「怪しい動きのルールを1つだけ書いてみようかな」そんな小さな一歩から、あなたのシステムの安全性を確実に高めていくことができます。

一歩ずつ、焦らず、一緒にセキュリティの引き出しを増やしていきましょう!次の記事でも、現場で役立つ実践的なテクニックをお届けしますので、ぜひ楽しみにしていてくださいね。

コメント

タイトルとURLをコピーしました