こんにちは！インフラや開発の現場に飛び込んだばかりの新人IT担当者の皆さん、日々の業務本当にお疲れ様です。
システムを安全に運用していく上で、「ファイルが勝手に書き換えられていないか？」をチェックする仕組みはめちゃくちゃ重要です。今回は、その基本となる「ファイル整合性監視（FIM）」と、そこで使われる「SHA-256ハッシュ」の仕組みについて、身近な防犯に例えながら分かりやすく紐解いていきましょう！
難しい用語が出てきても、「一歩ずつ対策を学んでいきましょう！」という気持ちで解説していくので、安心してついてきてくださいね。
—
1. 家の鍵で例える「ファイル整合性監視（FIM）」とハッシュ値
突然ですが、皆さんの大切な財産を守るために、自宅の玄関に「絶対にピッキングされない最強の鍵」をかけた仮定をしてみてください。でも、もし留守の間に泥棒が窓ガラスを割って侵入し、リビングの金庫の中身をごっそり持ち去って、さらに何食わぬ顔で鍵をかけ直して去っていったら……？ 帰宅したあなたは「鍵がちゃんと閉まっていたから大丈夫」と油断してしまいますよね。
これ、実はITの世界でも全く同じことが起きるんです。
サーバーの中にある重要な設定ファイルやプログラムが、不正アクセスによって書き換えられてしまったとします。サイバー攻撃者は、ファイルを書き換えた後に「見つからないように、ファイルの更新日時（タイムスタンプ）をこっそり元に戻す」なんてワザを平気で使います。見た目やタイムスタンプが完璧に偽装されていると、人間の目で「あれ、おかしいぞ？」と気づくのは至難の業です。
そこで登場するのが、ファイル整合性監視（FIM：File Integrity Monitoring）という仕組みです。
SHA-256ってなに？データの「指紋」の正体
FIMの心臓部で使われるのが、「SHA-256」というハッシュ関数です。
ハッシュ関数というのは、どんなに長いファイルでも、一瞬で「長さが完全に決まったバラバラの文字列（指紋のようなもの）」に変換してくれるマジックボックスのようなものです。
例えば、config.php というファイルの中身がたった1文字でも変わると、そこから生成されるSHA-256のハッシュ値（指紋）は、雪崩式に全く別の文字列に変化します。
- 正常なファイルの中身:
データベース接続OK→ SHA-256:e3b0c442...（仮のハッシュ値） - 泥棒がこっそり書き換えた中身:
データベース接続NG (別サーバーへ転送)→ SHA-256:8f434346...（全く違う値になる！）
つまり、定期的にファイルのハッシュ値を計算して、あらかじめ安全だと分かっている「正しいハッシュ値」と見比べることで、「目に見えないファイルの改ざん」を100%に近い精度で瞬時に見抜くことができるんです。
—
2. 実践！Pythonで体験するファイル整合性監視（FIM）
「理屈は分かったけれど、実際にどうやってチェックしているの？」気になりますよね。
百聞は一見にしかず。Pythonというプログラミング言語を使って、指定したファイルのSHA-256ハッシュを計算し、あらかじめ記録しておいた「正解のハッシュ値」と比較するシンプルなプログラムを作ってみましょう。
実務の現場でも、こうしたスクリプトや専用の監視ツールがバックグラウンドで常に目を光らせています。
import hashlib
import os
# 監視対象となる重要ファイルへのパス
TARGET_FILE = "/var/www/html/config.php"
# 事前に安全な状態で記録しておいた「正しいハッシュ値」（本来は安全な別場所に保存します）
# 例としてダミーのSHA-256ハッシュ値を設定しています
KNOWN_GOOD_HASH = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
def calculate_sha256(file_path):
"""
指定されたファイルのSHA-256ハッシュ値を計算して返す関数
"""
sha256_hash = hashlib.sha256()
# ファイルが存在するかチェック
if not os.path.exists(file_path):
print(f"[エラー] ファイルが見つかりません: {file_path}")
return None
try:
# メモリを圧迫しないよう、ファイルを少しずつ読み込んでハッシュを計算します
with open(file_path, "rb") as f:
for byte_block in iter(lambda: f.read(4096), b""):
sha256_hash.update(byte_block)
return sha256_hash.hexdigest()
except Exception as e:
print(f"[エラー] ファイルの読み込み中に問題が発生しました: {e}")
return None
def verify_file_integrity():
"""
ファイルの整合性を検証するメイン処理
"""
print(f"[*] ファイルの整合性をチェック中...: {TARGET_FILE}")
current_hash = calculate_sha256(TARGET_FILE)
if current_hash is None:
return
# 計算した現在のハッシュ値と、正解のハッシュ値を比較する
if current_hash == KNOWN_GOOD_HASH:
print("[安全] ファイルの改ざんは検知されませんでした。正常です。")
else:
print("[警告!] ファイルが改ざんされている可能性があります！")
print(f" 期待されるハッシュ: {KNOWN_GOOD_HASH}")
print(f" 現在のハッシュ : {current_hash}")
# ここでセキュリティチームへSlackやメールでアラートを飛ばす処理を実装します
if __name__ == "__main__":
verify_file_integrity()このコードでは、ファイルを小さなブロック（4096 バイトずつ）に分けて読み込んでいます。大きなファイルを扱うインフラの現場でも、サーバーのメモリを食いつぶさないためのちょっとした泥臭い配慮です。
—
3. 攻撃者が仕掛ける「盲点」と改ざん検知の限界
さて、ここからがセキュリティエンジニアの腕の見せ所であり、少し怖い現実のお話です。
「よし、SHA-256を使ってファイルのハッシュ監視を導入したから、もう完璧だね！」……本当にそうでしょうか？
サイバー攻撃者は、私たちが考える一歩先を行きます。もし攻撃者がサーバーの管理者権限（root権限など）を奪って侵入した場合、彼らはこんな行動に出ます。
1. システムファイル (config.php) を自分たちの都合の良いように書き換える。
2. 書き換えた後の新しいファイルのSHA-256ハッシュ値を計算する。
3. 監視システムが参照している「正解のハッシュ値のリスト（データベース）」そのものを、新しいハッシュ値に書き換えてしまう！
こうなるとどうでしょう？ FIMが定期的にチェックを走らせても、「おっ、現在のファイルのハッシュ値と、リストに書いてあるハッシュ値が一致しているから問題なし！」と判定してしまい、改ざんされたことに全く気づけなくなってしまうのです。これが、FIM単体が持つ最大の限界です。
玄関の鍵の例えに戻りましょう。泥棒が家に侵入して中身を盗んだだけでなく、「合鍵を作って、あなたの家の鍵のカタログそのものをすり替えてしまった」状態だと言えます。これでは警備会社も「鍵は一致しています」と報告してしまいますよね。
—
4. 限界を突破せよ！実践的な防御策とログの守り方
では、攻撃者にハッシュ値のリストまで書き換えられてしまうリスクに対して、私たちはどう立ち向かえば良いのでしょうか？ 現場で使われている具体的なアプローチをいくつか紹介します。
① ハッシュ値のリストやログを「絶対に書き換えられない場所」に逃がす
監視対象のサーバー（ローカル環境）の中にハッシュ値のリストを保存しているから、攻撃者に書き換えられてしまいます。対策はシンプルで、「書き換えたサーバーとは別の、ネットワークで切り離された安全なログ専用サーバー（SIEMなど）」に、計算したハッシュ値やアラートのログをリアルタイムで転送・保存するのです。
例えば、Linuxの rsyslog や Fluentd などのツールを使い、次のようにリモートの安全なログサーバーへ飛ばす設定を行います。
# /etc/rsyslog.conf の設定例（ローカルの改ざん検知ログをリモートサーバーへ転送する）
# 重要なセキュリティログを自分の足元に置かず、別の金庫に即座にコピーするイメージです
*.* @@logserver.internal.net:514*(※ @@ はTCPプロトコルを用いた確実な転送を指定しています。UDPよりも途中でログが欠落しにくいため実務で好まれます)*
② 書き込み不可（イミュータブル）なストレージの活用
AWSの S3 Object Lock や、Linuxの chattr +a（アペンドオンリー属性）コマンドなどを使い、「一度記録したら、二度と削除も上書きもできない（追記しかできない）」状態のストレージにログやハッシュ値を保存します。
これなら、たとえ攻撃者がサーバーの管理者権限を一時的に奪ったとしても、過去のログの改ざんや隠蔽を防ぐことができます。
③ 定期的なオフライン検証と多層防御
システムそのものを信頼し切るのではなく、「そもそも不正アクセスをさせないためのファイアウォール設定」や「不要な権限の排除（最小権限の原則）」といった、複数の防壁を組み合わせる多層防御が何よりも大切です。
—
おわりに
今回は、ファイル整合性監視（FIM）におけるSHA-256の仕組みと、その限界、そして現場でのリアルな防御策についてお伝えしました。
セキュリティの世界に「100%安全な絶対要塞」はありません。だからこそ、仕組みの便利さだけでなく、「もし攻撃者にここまで突破されたらどうなるか？」という攻撃者の視点（盲点）を常に持ち続けることが、私たちエンジニアの腕の見せ所になります。
難しく感じるかもしれませんが、一つひとつの仕組みを紐解いていけば必ず理解できます。焦らず、一歩ずつ安全なシステムづくりを楽しんでいきましょう！応援しています！
コメント