Ubuntu 26.04 auditd の基本設定 – 監査ログの土台を整える

Ubuntu 26.04 をサーバーとして運用する場合、ログは単なる障害調査の材料ではなく、変更や操作を後から確認するための証跡になります。auditd は Linux Audit Framework のユーザー空間側 daemon であり、監査イベントを受け取り、/var/log/audit/audit.log へ記録する役割を持ちます。

この記事では、Ubuntu 26.04 で auditd を導入し、/etc/audit/auditd.conf を整え、サービスとして起動するところまでを整理します。監査ルールそのものを細かく設計する前に、まず監査ログを受ける daemon の土台を作る位置づけです。

auditd で何を扱うのか

auditd は、カーネルの audit subsystem から渡されるイベントを受け取り、ログとして保存します。たとえば、認証、権限昇格、ファイルアクセス、監査ルールに一致した操作などを追跡するための基盤になります。

ただし、auditd を入れただけで監査設計が完成するわけではありません。ここでは daemon の設定、ログ出力先、ローテーション、ディスク逼迫時の動作を整えます。どの操作を監査対象にするかは、別途 audit.rules や augenrules の設計になります。

現在の状態を確認する

まず、auditd が既に入っているか、サービスが動いているか、ログディレクトリが存在するかを確認します。

dpkg -l auditd
systemctl status auditd --no-pager
sudo auditctl -s
sudo ls -ld /var/log/audit
sudo ls -l /var/log/audit/audit.log

auditctl -s では、audit subsystem の状態を確認できます。未導入の環境ではコマンドが存在しないか、サービスが起動していない状態になります。

auditd をインストールする

Ubuntu の標準パッケージから auditd をインストールします。監査ログは OS の運用基盤に近い要素なので、アプリケーション単位ではなく、サーバー共通の基盤として導入するのが自然です。

sudo apt update
sudo apt install -y auditd

auditd.conf を設定する

Ansible 側では、/etc/audit/auditd.conf をテンプレートで明示的に配置しています。ここでは同じ考え方で、ログファイル、ログ形式、ローテーション、ディスク逼迫時の動作を設定します。

sudo tee /etc/audit/auditd.conf >/dev/null <<'EOF'
local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = adm
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50
max_log_file = 8
num_logs = 5
priority_boost = 4
name_format = NONE
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
verify_email = yes
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
report_interval = 0
use_libwrap = yes
tcp_listen_queue = 5
tcp_max_per_addr = 1
tcp_client_max_idle = 0
transport = TCP
krb5_principal = auditd
distribute_network = no
q_depth = 2000
overflow_action = SYSLOG
max_restarts = 10
plugin_dir = /etc/audit/plugins.d
end_of_event_timeout = 2
EOF
sudo chmod 0644 /etc/audit/auditd.conf

重要な設定項目を見る

すべての項目を暗記する必要はありませんが、運用上の意味が大きい項目は押さえておくと切り分けがしやすくなります。

監査ログは「残っていれば便利」ではなく、「残っていないと後から追えない」種類のログです。一方で、ログ出力が無制限に増えるとサーバー自体を圧迫します。そのため、ログの保存先、保持世代、ディスク逼迫時の挙動を最初から決めておくことが重要です。

auditd を reload して起動する

設定を配置したら、auditd を reload し、サービスを起動・自動起動にします。

sudo service auditd reload
sudo systemctl enable --now auditd
systemctl status auditd --no-pager

Ansible 側でも reload は service auditd reload として扱っています。auditd は監査基盤なので、設定変更後はサービス状態とログ出力を必ず確認します。

動作を確認する

最後に、audit subsystem の状態、サービス状態、ログファイルの生成を確認します。

sudo auditctl -s
systemctl is-enabled auditd
systemctl is-active auditd
sudo ls -l /var/log/audit/audit.log
sudo tail -n 50 /var/log/audit/audit.log

auditctl -s で enabled 状態や backlog の状況を確認し、/var/log/audit/audit.log にログが出ていることを確認します。ここまで確認できれば、少なくとも auditd daemon の土台は整っています。

監査ルールは別に設計する

この記事で扱ったのは、auditd の導入と daemon 設定です。実際に何を監査するかは、別の設計になります。

• sudo や su などの権限昇格を追跡する
• 重要設定ファイルの変更を監査する
• ユーザーやグループの変更を監査する
• 認証関連ファイルの変更を監査する
• アプリケーションやミドルウェアの重要ファイルを監査する

監査ルールは多ければよいわけではありません。大量に出すだけでは、必要なイベントが埋もれます。どの操作を後から説明できる必要があるのか、どの変更を検知したいのかを決めてから設計するべきです。

まとめ

Ubuntu 26.04 で auditd を使う場合、まず daemon の土台を整えることが重要です。パッケージを入れ、/etc/audit/auditd.conf を明示し、ログの出力先、形式、ローテーション、ディスク逼迫時の動作を決めます。

監査ログは、障害調査だけでなく、変更や操作を後から説明するための証跡です。だからこそ、なんとなく入れるのではなく、OS 共通の管理基盤として扱う方がよいです。

監査ルールの設計は別の論点ですが、その前提として auditd が安定して動作し、ログを確実に残せる状態を作っておく必要があります。

参考書籍

次に読む記事

関連記事

Ubuntu 26.04 Apache の基本設定 – Web サーバーの土台を整える Ubuntu 26.04 Nginx の基本設定 – Web サーバーを起動して確認する Ubuntu 26.04 PowerDNS の基本設定 Ubuntu 26.04 Postfix の基本設定 Ubuntu 26.04 Samba の基本設定 Ubuntu 26.04 NFS の基本設定 Ubuntu 26.04 TFTP の基本設定 – tftpd-hpa と PXE boot の入口を整える Ubuntu 26.04 autofs の基本設定