こんにちは！SOC（セキュリティ・オペレーション・センター）で日夜、サイバー攻撃の痕跡を追いかけているアナリストです。
新しいシステムを作ったり、会社のセキュリティを守る立場になったりすると、いろいろな機器やアプリから「ログ」という名の記録が集まってきますよね。「誰が、いつ、どこから、何をしたのか」を記した大切なメモですが、いざ中身を見てみると……あれ？
Windowsのログは英語の独特な文章、Linuxは別の形式、ファイアウォール（ネットワークの番人）は数字の暗号みたいなデータ、そして自社で作ったアプリのログはバラバラの形式。これでは、まるで「世界中から言葉の通じないスパイが集まってきて、それぞれ母国語で勝手にメモを残している状態」です。これじゃあ、全体をつなぎ合わせて怪しい動きを見つけるなんて、至りませんよね。
今回は、このバラバラなログを綺麗に整理整頓して、セキュリティ分析の強力な武器に変える「ログの正規化とタクソノミ（分類体系）の設計」について、身近な例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょう！
—
1. 家の鍵と防犯カメラに例える「ログの正規化」
想像してみてください。あなたは大きなお屋敷の管理人を任されています。
門には防犯カメラがあり、玄関には電子錠（スマートロック）があり、庭にはセンサーライトがついています。そして、それぞれの機器が次のようにメモを残します。
- 門のカメラ：「
CAM01: 2023-10-25 22:00:15 - [Person Detected]（人が見つかりました）」 - 玄関の電子錠：「
Lock_System: User ID 'suzuki' opened the door at 10/25/2023 10:00PM.（鈴木さんがドアを開けました）」 - 庭のセンサーライト：「
Light_Sensor_03 - ON - 22:00:15（22時00分15秒に点灯）」
さて、このバラバラの記録を見て、「夜中に泥棒が侵入しようとして、玄関から入ってきたかどうか」を瞬時に見抜けますか？人間が頭の中で「ええと、カメラの22時00分15秒と、ライトの22時00分15秒は同じ時間だな……」とパズルを解かなければなりません。
泥棒は、あなたがパズルを解いている隙に忍び込んでしまいます。
だからこそ、これらを「誰が」「何を」「どこで」「いつ」という共通の引き出し（フォーマット）に綺麗にファイリングし直す必要があります。これが「ログの正規化」です。
—
2. タクソノミ（共通の分類辞書）ってなに？
正規化を行うためには、社内やシステム全体で使う「共通の共通語（タクソノミ）」を決める必要があります。
例えば、攻撃者が社内のパソコンに侵入したとき、ログの名前は次のようにバラバラにつけられています。
- Windows：「イベントID 4624（ログオン成功）」
- Linux：「
Accepted publickey for root from 192.168.1.50」 - アプリケーション：「
[INFO] User login success: admin」
これらをSIEM（セキュリティ情報を集めて分析するシステム）に放り込むとき、すべて次のような「共通の意味（タクソノミ）」に翻訳します。
- イベントカテゴリ：
Authentication（認証） - アクション：
Login（ログイン） - 結果：
Success（成功） - ユーザー名：
adminまたはsuzuki - 接続元IP：
192.168.1.50
このように、バラバラの言葉を「セキュリティ分析でよく使う共通の引き出し」に綺麗に分類するルールブックを作ることを、タクソノミの設計と呼びます。
—
3. 実践！JSONを使ったログ正規化の設計図
それでは、実際に開発やインフラの現場でどのように正規化を行うのか、具体的な設定のイメージを見てみましょう。
今回は、一般的なログ収集・転送ツール（FluentdやLogstashなど）を使って、バラバラのアプリログやOSログを、統一されたJSON形式に変換する設定例を考えてみます。
{
"timestamp": "2023-10-25T13:00:15Z",
"event": {
"category": "authentication",
"action": "login",
"outcome": "success"
},
"observer": {
"product": "ActiveDirectory",
"vendor": "Microsoft"
},
"source": {
"ip": "192.168.1.105",
"user": {
"name": "yamada"
}
}
}この設定（スキーマ）のポイント
timestamp: 世界基準の時刻（UTC）に統一しています。時差の計算で迷わなくなります。event.category/action/outcome: 「何が起きたのか」を抽象的な共通語で表現しています。これのおかげで、「失敗したログイン（outcome: failure）」だけをきれいに抽出しやすくなります。source: どこから、誰がアクセスしてきたのかをきれいに切り分けています。
—
4. 現場でありがちな落とし穴と、一歩進んだアドバイス
新人のエンジニアや開発者の方からよくいただく相談が、「とりあえず全部のフィールドをそのまま保存すればいいですよね？」というものです。
気持ちはとてもよく分かります。データを削ってしまって、あとから「あのログが必要だった！」と気づくのが怖いですよね。しかし、ここにサイバー攻撃者が狙う盲点があります。
あまりにもログの構造がバラバラのまま巨大なデータを溜め込むと、SIEMでの検索スピードが極端に遅くなります。攻撃者はその「処理の遅延や死角」を突いて、夜間にこっそり大量の不正アクセスを仕掛けてきたりします。
現場からのアドバイス
1. マッピングのルールを小さく始めましょう： 最初からすべての機器のログを完璧に正規化しようとすると挫折します。まずは「ログイン」「ファイルの書き換え」「外部通信」の3つの重要イベントにしぼって、タクソノミを設計してみてください。
2. タイムスタンプの単位を揃えましょう： 「秒」なのか「ミリ秒」なのか、タイムゾーンは「JPT（日本時間）」なのか「UTC（協定世界時）」なのか。ここがバラバラだと、相関分析（時間の前後関係を見る分析）が完全に狂ってしまいます。必ず統一しましょう。
—
まとめ
ログの正規化とタクソノミ設計は、一見すると地味で泥臭い作業に見えます。華やかなアプリ開発や、最先端のAIセキュリティに比べると、裏方の事務作業のように感じるかもしれません。
しかし、どれほど頑丈な防犯カメラや電子錠（セキュリティツール）を家につけても、それらの警報がバラバラの言語で鳴り響いていたら、泥棒を見逃してしまいます。
私たちがSOCの現場で迅速に不正アクセスの芽を摘み取ることができるのは、こうした地道な「言葉の翻訳（正規化）」の土台がしっかりしているからこそです。
ぜひ、皆さんのシステムでも「ログの共通語化」を意識して、安全で強いインフラを作っていきましょう。一歩ずつ、着実に進めていけば大丈夫です。応援しています！
コメント