午前2時の悪夢：誰が設定を書き換えたのか？
午前2時15分。ページャーが鳴り響いた。本番のNginxサーバーが500エラーを吐き出しており、1万人以上の有効ユーザーがサイトにアクセスできない状態だった。ログインしてサービスの状態を確認すると、nginx.confがわずか数分前に変更されていることがわかった。mtime（修正時刻）は嘘をつかないが、rootユーザーのシェル履歴（history）は真っ白だった。誰か、あるいは何らかのスクリプトが重要なファイルを変更し、証拠隠滅のために.bash_historyを消去したのだ。
/var/log/auth.logやsyslogのような標準的なログは行き止まりだった。ログインがあったことは確認できたが、その後に何が起きたのかについては全く手がかりがなかった。これは、多くのシステム管理者が眠れなくなる瞬間だ。基本的なアプリケーションログだけに頼っていると、セキュリティ侵害が発生した際に「盲目」状態で対応することになる。これを解決するには、隠蔽される前にアクティビティをカーネルレベルで直接記録する方法が必要だった。
死角：なぜ標準ログでは不十分なのか
標準的なLinux의 ロギングは、主にアプリケーション層での「イベントベース」だ。SSHは接続を記録し、Nginxはリクエストを記録する。しかし、これらのシステムはファイル操作の**意図**までは理解しない。悪意のある攻撃者がvimやsed、あるいはPythonのワンライナーを使って/etc/shadowを上書きした場合、カーネルはシステムコールを処理するが、通常のログはそれを無視してしまう。
きめ細かな可視性が必要だ。誰がファイルを開いたのか、どのプロセスを使用したのか、そして正確に何を実行したのかを知る必要がある。このデータは、ユーザーが履歴ファイルを削除したとしても残らなければならない。カーネルのシステムコール（syscalls）をフックすることで、これらのアクティビティをリアルタイムでキャプチャできる。
解決策の比較
この可視性のギャップを埋める方法を探す際、私は主に3つの選択肢を検討した：
- シェル履歴 (HISTFILE): これは利便性のためのものであり、セキュリティのためではない。
unset HISTFILEやkill -9 $$を実行するだけで、誰でも数秒で回避できてしまう。 - EDR (Endpoint Detection and Response): CrowdStrikeやWazuhのようなツールは強力だ。しかし、リソースの負荷が高く、ライセンス費用も高額になることが多いため、すべての特殊なサーバーに適しているわけではない。
- Auditd (Linux監査フレームワーク): これはネイティブで軽量な選択肢だ。ほとんどの主要なディストリビューションに組み込まれており、ユーザースペースとカーネルの間に位置する。標準ユーザーがこれを回避することは事実上不可能だ。
フォレンジックの深さにおいて、Auditdは明らかに勝者だ。単にファイルが変更されたことを報告するだけでなく、PID、UID、実行ファイルのパス、飾してシステムコールの正確なタイムスタンプを提供する。ほとんどのシステムで、CPUオーバーヘッドは3%未満であり、本番環境での導入に迷う理由はない。
より良い方法：Auditdの実装
インストールは簡単だ。UbuntuやDebianなら、一つのコマンドで実行できる：
sudo apt update && sudo apt install auditd audispd-plugins -y設定に入る前に、自分自身のアクセス権が安全であることを確認した。サーバーの認証情報を更新するために、toolcraft.app/ja/tools/security/password-generatorにあるパスワードジェネレーターを使用した。これはブラウザ上でローカルに高エントロピーな文字列を生成するため、最初から資格情報の漏洩を防ぐ簡単な方法だ。
1. 機密ファイルの監視
