現場で泥をすすりながらインシデント対応をしていると痛感するんだが、「ログ」ほど信用できず、かつ「ログ」ほど裏切られるものはない。
攻撃者がシステムに侵入した直後に何をするか知っているか？ rm -rf なんて派手なことはしない。静かに、実に丁寧に、自分の足跡だけをログから消去するんだ。sed や awk で特定のUIDやIPアドレスが含まれる行を抜き取り、残りを結合してタイムスタンプを修正する。これに気づけない運用は、もはや「裸で戦場を歩いている」のと同義だ。
今日は、そんな「ログの改ざん」という絶望的な事態を防ぐための、ハッシュチェーンによるログの完全性保護について話そう。
ログ改ざんは「線」で防げ：ハッシュチェーンの概念
単にログを別のサーバーに転送するだけでは不十分だ。転送経路が乗っ取られていたら終わりだし、ログサーバー自体が侵害されれば過去の履歴は書き換えられてしまう。
ここで使うのが「ハッシュチェーン」だ。
今のログのハッシュ値を計算する際、「一つ前のログのハッシュ値」を混ぜ込む。これを行うことで、途中のログを1行でも書き換えれば、以降のすべてのハッシュ値が崩壊する。攻撃者は、過去のハッシュ値をすべて再計算し、かつ、保存先（WORMや書き込み専用のS3バケットなど）の整合性すら突破しなければならなくなる。
実装：Pythonによるログのハッシュチェーン
現場ですぐに組み込めるシンプルな実装例だ。ログを追記するたびに、前回のハッシュ値を読み込み、新しいログと連結してSHA-256でハッシュ化する。
import hashlib
import os
# 前回のハッシュを保存するファイル（保護された領域に置くこと）
HASH_FILE = "/var/log/app_secure/last_hash.txt"
LOG_FILE = "/var/log/app_secure/access.log"
def append_secure_log(message):
# 前回のハッシュ値を取得（初期値は0）
if os.path.exists(HASH_FILE):
with open(HASH_FILE, "r") as f:
prev_hash = f.read().strip()
else:
prev_hash = "0"
# 新しいログ内容を作成
new_log = f"{message}"
# ハッシュチェーンの計算: H(n) = Hash(prev_hash + log_data)
combined = (prev_hash + new_log).encode('utf-8')
current_hash = hashlib.sha256(combined).hexdigest()
# ログとハッシュを保存（実際にはDBや追記専用ファイルに書き込む）
with open(LOG_FILE, "a") as f:
f.write(f"{current_hash} | {new_log}\n")
# 次回のためにハッシュを更新
with open(HASH_FILE, "w") as f:
f.write(current_hash)
# 使用例
append_secure_log("User ID 101 logged in from 192.168.1.5")運用上の鉄則：防御の「最後の一線」
コードだけでは不十分だ。インフラ側でこのログをどう守るかが勝負になる。
1. S3 Object Lock (WORMストレージ) の活用
ログファイルをS3に転送する場合、必ず「Object Lock」を有効にしろ。一度書き込まれたら、たとえルート権限を持った攻撃者であっても、設定した期間は削除も改ざんもできない。これが最強の盾だ。
2. ログ転送の分離
アプリケーションサーバーからログを飛ばす際、通常のネットワーク経路とは別に「ログ専用の閉域網（VPCエンドポイント等）」を通せ。攻撃者にパケットを傍受・改ざんされる余地を極限まで減らす。
3. IAMポリシーの厳格化
ログ管理サーバーに対する DeleteObject や PutObject の権限は、人間には与えるな。あくまで「ログ転送用のIAMロール」のみに限定する。
最後に：なぜ「泥臭い」ことが重要か
「そんな手間をかけてまでログを守る必要があるのか？」と思うかもしれない。だが、インシデント発生時、フォレンジック調査で「ログが改ざんされている可能性がある」という疑念が1秒でも浮かぶと、調査コストは数倍に跳ね上がる。 信頼できるログは、調査のスピードを上げ、被害の拡大を止める唯一の武器だ。
ログを単なる「テキストの羅列」と捉えるな。それは君たちが戦場で生き残るための「証拠」だ。エンジニアとして、システムを守るための誇りを持ってログを管理してほしい。
もし、実装していて「このログの整合性が取れない」というアラートが鳴った瞬間、それが君のシステムの危機だ。その時は迷わず、即座にインシデントレスポンス体制を起動させろ。ログが嘘をつかないということは、それだけ重い責任を伴うんだよ。
コメント