実際の現場から：深夜2時の当直と不正操作の追跡という難題
午前2時15分、PagerDutyのアラートが鳴り響きました。Nginxのリバースプロキシクラスタが完全にダウン。毎分15,000件以上押し寄せるHTTPSリクエストがすべて502エラーを返していました。本番環境のCentOS Stream 9サーバーへSSH接続して調査したところ、証明書ファイル /etc/pki/tls/certs/api.crt のパーミッションが 000 に変更されているのを発見しました。しかし history を実行しても、ターミナルには何も表示されません。犯人はコマンドの先頭にスペースを挿入したか、シェルを抜ける前に unset HISTFILE を実行していたのです。
journalctl -u nginx や /var/log/messages を確認しても、残っていたのは cannot load certificate: Permission denied という素っ気ないメッセージのみ。深夜に誰が証明書ファイルに対してchmodコマンドを実行したのか、その痕跡は一切見当たりませんでした。
これこそが、新規サーバー構築時にLinux Audit Frameworkの導入を怠った代償です。syslogやjournaldは、アプリケーションが出力したログを受動的に記録するにすぎません。対照的に、auditd はAudit Subsystemを介してLinuxカーネルに直接フックします。プロセスがシステムコール（ファイルの読み取り、上書き、削除、パーミッションや所有者の変更など）を発行するたびに、カーネルが即座に記録を残します。特に強力なのが auid（Audit UID）フィールドです。ユーザーが sudo su - でrootに昇格したとしても、カーネルは実際にコマンドを実行した元のログインアカウントを正確に特定できます。
CentOS Stream 9へのAuditdのインストール
CentOS Stream 9のMinimalインストール環境では、auditパッケージ自体は標準で含まれていることが多いものの、管理用ユーティリティツールが不足している場合があります。以下のコマンドで一式をインストールします：
sudo dnf install -y audit audit-libs
デーモンの有効化と起動を行います：
sudo systemctl enable auditd
sudo systemctl start auditd
重要な注意点： RHEL 9およびCentOS Stream 9のsystemdでは、カーネルによるセキュリティ監査ログの記録中断を防ぐため、systemctl restart auditd コマンドの実行がブロックされています。サービスを再起動する場合は、必ず以下のコマンドを使用してください：
sudo service auditd restart
カーネル内のaudit subsystemの動作ステータスを確認します：
sudo auditctl -s
実行結果として enabled 1 が返り、pid に有効なプロセスIDが表示されていれば、カーネル側でイベントを捕捉する準備が完了しています。
詳細設定：本番サーバー向けの実践的ルールセット
Auditdの構成は大きく2つの要素に分かれます。ログファイル、容量、ローテーション動作を管理する /etc/audit/auditd.conf と、監視ルールを格納する /etc/audit/rules.d/ ディレクトリです。
1. auditd.confによるディスク枯渇の防止
高負荷なサーバー環境では、監査ログが1日で数十ギガバイトに達することもあります。/var/log パーティションが溢れてしまうと、サーバー全体が停止する危険性があります。設定ファイルを開いて調整しましょう：
sudo vi /etc/audit/auditd.conf
安全に運用できるようストレージ関連のパラメータを設定します：
# 各ログファイルの最大サイズ (MB)
max_log_file = 50
# ローテーションで保持する最大ファイル数（合計最大500MB）
num_logs = 10
max_log_file_action = ROTATE
# 残りディスク容量が100MB未満になった際のアラート
space_left = 100
space_left_action = SYSLOG
# 残り容量が50MB未満になった際にログ記録を一時停止しサーバークラッシュを回避
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
この設定により、監査ログの総容量を上限500MBに抑えつつ、ディスクが枯渇する前にsyslog経由で早期警告を通知できます。
2. 永続的な監視ルールセットの構築
auditctl コマンドで直接ルールを追加すると、OS再起動時に消失してしまうため推奨されません。すべてのルールは /etc/audit/rules.d/audit.rules ファイルに定義します：
sudo vi /etc/audit/rules.d/audit.rules
以下の標準化されたルールセットを貼り付けます：
## 衝突を防ぐため既存のルールをすべて消去
-D
## バッファサイズを8192メッセージに拡張（急激なI/O増加時のログドロップを防止）
-b 8192
## 1. アカウントおよびシステム権限の変更を監視
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/sudoers -p wa -k sudoers_tamper
-w /etc/sudoers.d/ -p wa -k sudoers_tamper
## 2. Nginx設定およびSSL証明書を監視
-w /etc/nginx/ -p wa -k nginx_config_tamper
-w /etc/pki/tls/ -p wa -k ssl_certs_tamper
## 3. ファイル権限変更のシステムコールを捕捉 (chmod, chown)
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k file_permission_change
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=unset -k file_owner_change
## 4. ファイルおよびディレクトリの削除操作を捕捉
-a always,exit -F arch=b64 -S unlink,unlinkat,rmdir -F auid>=1000 -F auid!=unset -k file_deletion
## 5. 設定のロック（システムが安定稼働した後にコメントを解除）
#-e 2
覚えておくべき重要なパラメータ：
-w <path>: 特定のパスを監視するウォッチポイント（Watchpoint）。-p wa:write（書き込み/編集）およびattribute（パーミッション、所有者、タイムスタンプの変更）の2つのアクションをフィルタリング。-k <key>: ログ検索時にイベントをすばやく抽出するための識別キーを付与。-F auid>=1000 -F auid!=unset: システムにログインした実ユーザー（UID 1000以上）のみを対象に設定。不要なログの肥大化を防ぐため、システムデーモン（UID < 1000）を除外。-e 2: カーネル内で設定を完全にロック。このフラグを有効にすると、サーバーを再起動しない限りルールを変更できなくなります。
新しいルールをカーネルにロードします：
sudo augenrules --load
現在有効なルール一覧を確認します：
sudo auditctl -l
調査の実践：ausearchとaureportによる痕跡の追跡と解析
/var/log/audit/audit.log ファイルに対して直接 cat や grep を使用するのは避けてください。生データには16進数の文字列が多く含まれており、可読性が極めて低いためです。解析には ausearch と aureport の組み合わせを活用しましょう。
1. 疑似インシデントの再現テスト
一般ユーザーアカウント（例：UID 1001の hungnd）でログインし、sudoを実行してNginx設定ファイルのパーミッションを変更してみます：
sudo chmod 000 /etc/nginx/nginx.conf
2. ausearchによる追跡調査
キー file_permission_change でイベントを検索し、-i（interpret）オプションを付与して16進コードを人間が読めるテキストに変換します：
sudo ausearch -k file_permission_change -i --recent
出力されるログから、インシデントの全体的なコンテキストを正確に把握できます：
type=SYSCALL msg=audit(18/10/2026 02:15:30.120:412) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xffffff9c a1=0x154b200 a2=000 items=1 ppid=2450 pid=2810 auid=hungnd uid=root gid=root euid=root ses=3 comm="chmod" exe="/usr/bin/chmod" key="file_permission_change"
type=PATH msg=audit(18/10/2026 02:15:30.120:412) : item=0 name="/etc/nginx/nginx.conf" inode=135894 dev=fd:00 mode=0100644 ouid=0 ogid=0
主要なデータフィールドの意味：
- comm & exe: 実行されたコマンドは
/usr/bin/chmodです。 - name: 対象となったファイルは
/etc/nginx/nginx.confです。 - uid=root: コマンドはroot権限で実行されました。
- auid=hungnd: 元の実行者（Audit UID）。ユーザーが
sudoを経由してroot権限を行使した場合でも、監査サブシステムはセッションを最初に開始したユーザーがhungndであることを正確に特定します。
3. aureportによる迅速な統計レポートの作成
定期的なセキュリティ監査を実施する際、aureport を利用すればわずか数秒で集計レポートを出力できます。
ログインの成功および失敗回数を集計：
sudo aureport -l --summary
カーネルによって拒否された操作を一覧表示（権限探索や特権昇格の試行兆候を検知）：
sudo aureport --failed
過去24時間に改変されたファイルの一覧を確認：
sudo aureport -f -ts yesterday
Auditdは不正操作そのものをリアルタイムに阻止するツールではありません。しかし、インシデントが発生した際に最も価値あるものをもたらします。それは、責任の所在を明確にし、運用の脆弱性を根本から是正するための、動かぬ決定的な証拠です。
