問題：コマンド履歴（History）は嘘をつく
サーバー上で誰かが誤って rm -rf を実行した犯人を特定するために、一晩中調査したことはありませんか？私は、SSHへのブルートフォース攻撃が成功してしまった際に、その経験をしました。深夜2時に断片的なログを漁る作業は、本当に苦痛なものです。
多くの人は .bash_history ファイルを完全に信頼していますが、悪意のあるユーザーは history -c や unset HISTFILE というコマンド一つで、すべての痕跡を消し去ることができます。さらに危険なのは、history はユーザーが入力した内容のみを記録し、実行結果や vi、nano で編集した内容までは記録しないという点です。
複数の管理者がいるシステムや、外部ベンダーに保守を委託している場合、監視の欠如は致命的な脆弱性となります。tlog は、この問題を根本から解決するためのソリューションです。
なぜ他のツールではなく tlog なのか？
技術者はよくいくつかの選択肢で迷いますが、現実を見てみましょう：
- scriptコマンド: すべてのLinuxマシンで利用可能です。ログをテキストファイルに記録しますが、非常に削除されやすいのが難点です。
rm一つで証拠は消えてしまいます。 - Auditd: システムコールの監視には非常に強力ですが、ログが人間にとって極めて読みにくく、リプレイ（再生）機能もありません。
- tlog: セッションをJSON形式で記録し、直接
journaldに送信します。このログを集中管理サーバー（ELKやGraylogなど）に転送することも可能です。ユーザーがこのログを改ざんしたり削除したりすることは、ほぼ不可能です。
tlogの注目すべきメリット：
- すべてのキー入力、バックスペース、および表示されたすべての結果を記録します。
- リプレイ機能により、セッションを画面録画ビデオのように見直すことができます。
- JSON形式を採用しているため、集中管理ツールでのログ検索が非常に簡単です。
tlogを30秒でインストールする
tlogはRed Hat系（RHEL, AlmaLinux, Rocky Linux）で特によく使われていますが、Ubuntuでも非常にスムーズに動作します。
RHEL/CentOS/Rocky Linuxの場合：
sudo dnf install tlog -yUbuntu/Debianの場合：
sudo apt update && sudo apt install tlog -yセッション記録の設定
特定のユーザーのみを対象にするクイック設定と、システム全体を対象にする本格的な設定の2つの方法があります。
方法1：ユーザーに tlog を強制する（個人向け）
ユーザーを直接 /bin/bash に入れる代わりに、tlog-rec-session でラップします。例として dev-user で試してみましょう：
sudo usermod -s /usr/bin/tlog-rec-session dev-userこれで、dev-user がSSHでログインするたびに、すべての行動が監視下に置かれるようになります。
方法2：SSSDを使用する（エンタープライズ向け）
サーバーがActive Directoryに接続されている場合は、/etc/sssd/conf.d/sssd-session-recording.conf ファイルを編集します：
[session_recording]
scope = all # システム上のすべてのユーザーを記録する変更を適用するために、サービスの再起動を忘れないでください：
sudo systemctl restart sssdビデオのように再生（Replay）する方法
ここが tlog の真骨頂です。データは journald内にあるため、journalctl でデータを取得し、tlog-play で再生します。
記録ID（Recording ID）を探す：
journalctl -t tlog-rec-session再生を開始する：
直近のセッションを再生するには、以下のコマンドを入力します：
journalctl -t tlog-rec-session -o cat | tlog-play画面には、入力されたキーや、削除されたタイポ（打ち間違い）まで逐一表示されます。まるで本人の後ろに座って画面を覗き込んでいるかのような感覚です。
実践的なアドバイスと注意点
ログをそのサーバー自体に保存したままにしないでください。ハッカーがroot権限を取得した場合、journald を操作される可能性があります。
systemd-journal-remote を使ってログを集中管理サーバーに転送しましょう。そうすれば、メインサーバーのデータが消去されても、デジタル証拠を安全な場所に保管できます。
ディスク容量に注意
tlogはすべてを記録します。ユーザーが top や htop のような頻繁に画面を更新するコマンドを10分間実行し続けると、ログが5〜10MBに達することがあります。100人のユーザーが常に活動している場合、ログファイルは急速に肥大化します。ディスクフルでサーバーが停止しないよう、journald のLog Rotationを適切に設定してください。
システムパフォーマンス
実際のテストでは、tlogによるレイテンシは極めて低く、通常CPU使用率は1〜2%未満です。一般的なユーザーが、自分が記録されていることに気づくことはまずありません。
結論
tlogは単なる従業員監視ツールではありません。「深夜2時にNginxの設定を変更してサイトをダウンさせたのは誰か？」という問いに答えるためのセキュリティレイヤーです。
推測に頼るのではなく、リプレイを再生して数分で原因を特定しましょう。トラブルが起きてから「何が起きたのか分からない」と後悔する前に、今すぐ tlog を導入することをお勧めします。
