Posted inセキュリティ

Linuxターミナルセッションの記録：tlogによる監査ガイド

Security tutorial - IT technology blog
Security tutorial - IT technology blog

ユーザーセッションの監査：標準ログが不十分な理由

運用サーバーの管理は、時にフォレンジック調査のように感じられることがあります。サービスがダウンしているのを確認し、シニアエンジニアのログイン履歴も見つかるものの、bash_history は不自然に空っぽといった状況です。auth.log のような従来のログは誰がログインしたかは記録しますが、実際の意図やユーザーが目にした視覚的なフィードバックまでは捉えられません。unset HISTFILE を実行したり、サブシェルを使ったりするだけで、ユーザーの痕跡は瞬時に消し去られ、設定ファイルが消失した原因も闇に葬られてしまいます。

セッション記録は、ターミナルのブラックボックスとして機能し、このギャップを埋めてくれます。監査を設定する前に、私はいつも管理用のエントリポイントが盤石であることを確認します。例えば、toolcraft.app のパスワード生成ツールを使用して、エントロピーの高いキーを作成します。これはブラウザ内でローカルに動作するため、機密データがネットワークに流れることはありません。アクセスを保護した上で、透明性が高く改ざんが困難な監査トレイルを提供するために tlog を導入します。

セッション記録手法の比較

Linuxにはユーザーのアクティビティを追跡する方法がいくつかありますが、信頼性や使いやすさは大きく異なります。

‘script’ コマンド

ほとんどのディストリビューションには、デフォルトで script ツールが含まれています。これはターミナルセッションをローカルのテキストファイルに記録しますが、プロフェッショナルな監査ツールとは言えません。ユーザーが簡単に記録を停止できてしまいますし、生成されるファイルは複雑なタイプスクリプト形式で、検索やリアルタイムの再生も困難です。

商用PAMソリューション

CyberArkやBeyondTrustのような特権アクセス管理（PAM）スイートは、非常に強力です。これらはユーザーとサーバー間のプロキシとして機能し、堅牢な機能を提供します。しかし、多くの場合、数万ドル規模の予算と複雑なインフラが必要であり、ほとんどの小規模チームにとっては正当化しにくいものです。

tlogによるアプローチ

tlog は中央集権的なロギングのために構築されたオープンソースパッケージです。ユーザーが削除できるようなローカルファイルには書き込みません。その代わりに、正確なタイミングを含むセッションデータを構造化された JSON として systemd ジャーナルにストリーミングします。Cockpit と組み合わせることで、画面上で何が起こったのかを YouTube のようなインターフェースで確認できるようになります。

tlogのメリットとデメリット

すべてのツールにはトレードオフがあります。さまざまな本番環境で tlog を運用して気づいた点を挙げます。

  • メリット:
    • 構造化データ: JSON出力により、自動アラートのためにログを直接 Elasticsearch や Graylog にパイプ処理できます。
    • 精密な再生: キーストロークのタイミングを記録します。ユーザーがコマンドをコピー＆ペーストしたのか、手動で入力したのかまで判別可能です。
    • SSSD統合: デフォルトシェルを変更することなく、特定のグループ（外部委託業者など）に対して強制的に記録を行うことができます。
    • 最小限の負荷: CPU消費はごくわずかです。標準的な10分間のセッションでも、ログに追加されるのは通常200KB未満です。
  • デメリット:
    • CLIのみ: X11やWaylandでのGUIアクティビティはキャプチャできません。
    • ログの肥大化: 記録されている最中に稼働中のログファイルに対して tail -f を実行すると、数秒で数メガバイトのデータが生成されることがあります。
    • 設定の不備: SSSDを使用して記録を強制しない場合、賢いユーザーならラッパーを回避する可能性があります。

推奨スタック

信頼性の高いセットアップのために、AlmaLinux や Rocky Linux といった RHEL ベースのシステムを推奨しますが、Ubuntu 22.04以降でも十分に動作します。記録用の tlog、管理用の SSSD、そして視覚的なインターフェース用の Cockpit が必要です。

ステップバイステップの導入手順

このガイドでは、Cockpit との統合が最も成熟している RHEL 派生版の AlmaLinux を例に使用します。

1. パッケージのインストール

記録エージェントと Cockpit プラグインをインストールします。その後、Webインターフェースが有効であることを確認します。

sudo dnf install tlog sssd cockpit-session-recording -y
sudo systemctl enable --now cockpit.socket

2. SSSDによる記録の強制

最も安全な方法は、SSSD を介してセッションラップを強制することです。これにより、ユーザーが認証した瞬間に記録が開始されます。セッション記録ルール用の新しい設定ファイルを作成します。

sudo nano /etc/sssd/conf.d/session_recording.conf

システム上のすべてのユーザーを記録するには、以下の設定を使用します。

[session_recording]
scope = all

特定のグループ（’contractors’ や ‘wheel’ など）のみを追跡したい場合は、scopeを some に変更し、グループをリストアップします。このファイルには厳格なパーミッションを設定してください。そうしないと SSSD が起動を拒否します。

sudo chmod 600 /etc/sssd/conf.d/session_recording.conf
sudo systemctl restart sssd

3. tlog設定の微調整

/etc/tlog/tlog-rec-session.conf の設定を確認します。ユーザーが出力ファイルを改ざんできないよう、writerが “journal” に設定されていることを確認してください。

{
  "writer": "journal",
  "latency": 10,
  "payload": 2048
}

4. 記録の確認

SSH 経由で標準ユーザーとしてログインします。セッションが監視されている旨の通知が表示される場合があります。いくつかコマンドを実行してデータを生成します。

ssh myuser@server-ip
ls -la /etc/
sudo systemctl status nginx
exit

5. セッションの再生

映像を確認する方法は2つあります。コマンドラインによる方法は迅速ですが、Webインターフェースの方がはるかに直感的です。

CLIによる方法

ジャーナルを検索し、データをプレイヤーにパイプします。

journalctl -o export | tlog-play -i

Cockpitインターフェース

https://your-server-ip:9090 にアクセスしてログインします。サイドバーの Session Recording をクリックします。タイムスタンプと実行時間が記載されたセッション一覧が表示されます。Play をクリックして、ユーザーが見た通りのセッションの様子を確認しましょう。

セキュリティとコンプライアンスに関する注意点

導入は戦いの半分に過ぎません。データも責任を持って管理する必要があります。

ログの保護: tlog は、ユーザーが cat .env を実行した場合の機密情報を含め、すべてをキャプチャします。ジャーナルと Cockpit へのアクセスは、信頼できる少数の監査人に限定してください。

ディスク容量の管理: /etc/systemd/journald.conf の SystemMaxUse を使用してログサイズを制限してください。これを行わないと、1人のユーザーが冗長なデバッグコマンドを実行しただけで /var パーティションが一杯になる可能性があります。

法的透明性: /etc/motd を更新し、記録されていることを必ずユーザーに通知してください。これは職場のプライバシーコンプライアンスにおいて、法的な要件となることが多いです。

tlog の導入により、トラブルシューティングにかかる膨大な時間を節約できました。何がサービスを壊したのかを推測する代わりに、再生を確認して正確なタイポを見つけ出すことができます。これは、Linux インフラに完全な説明責任をもたらす、軽量で効率的な方法です。

Share:
Tags: