はじめに：監査とログ記録が重要な理由
Ubuntu Server における監査とログ記録は、Ubuntu サーバーのセキュリティ、信頼性、説明責任を維持するために不可欠です。システムアクティビティに関する知見を提供し、異常の検出に役立ち、GDPR、HIPAA、PCI-DSS などの規制要件への準拠に欠かせません。
しかし、多くのシステムでは、ディスク容量の消費への懸念や、データを効果的に分析するツールの不足から、監査が有効化されていません。この記事では、こうした懸念に対処し、実践的でスケーラブルな方法で監査とログ記録を実装する手順を解説します。
取り上げるトピック：
- 監査の実際の活用と課題。
- ツール： auditd を使ってシステムイベントを追跡・記録する。
- 監査ログのためのディスク容量計画。
- 監査ログとシステムログを分析するツール。
- ログローテーション設定ツール： logrotate。
- 高度な監視と監査の手法
過去の記事：
01. Ubuntu Server 入門 – SysOSX: AI & Cloud
02. 初めての Ubuntu Server のセットアップ方法：初心者ガイド – SysOSX: AI & Cloud
03. Ubuntu Server のための Linux コマンドラインを極める – SysOSX: AI & Cloud
04. Ubuntu Server のユーザーと権限の管理：包括的ガイド – SysOSX: AI & Cloud
05. Ubuntu Server のネットワークの基礎：包括的ガイド – SysOSX: AI & Cloud
06. Ubuntu Server へのソフトウェアのインストールと管理：完全ガイド – SysOSX: AI & Cloud
07.Ubuntu Server のパッチ適用と更新：包括的ガイド – SysOSX: AI & Cloud
08. Ubuntu Server のセキュリティ強化：堅牢化と保護のための実践的な手順 – SysOSX: AI & Cloud
1. システム監査の実際の活用
多くのシステムが監査を省く理由
監査は強力ですが、多くの管理者は次の理由から有効化を避けています。
- ディスク容量の消費：監査ログは、特に利用の多いシステムでは急速に肥大化し、大量のディスク容量を消費することがあります。
- パフォーマンスのオーバーヘッド：詳細な監査を有効にすると、システムパフォーマンスにわずかなオーバーヘッドが加わることがあります。
- 複雑さ：監査ログは冗長で、分析には専用のツールが必要です。
監査の計画方法
ディスク容量計画
監査を効果的に計画するには、次のようにします。
- ログの増加量を見積もる：監査を一時的に有効化し、1 週間かけてログのサイズを測定することで、ログの増加率を監視します。
sudo du -sh /var/log/audit/このデータを使って、1 日、1 週間、1 か月あたりのストレージ要件を計算します。 - 専用ストレージを割り当てる：監査ログは、ルートファイルシステムをいっぱいにしないよう、別のパーティションやディスクに保存します。例：
- ログ用のパーティションを作成します（例：
/var/log/audit）。 - 必要に応じてストレージを動的に拡張できるツール：
lvcreate（Logical Volume Manager）を使います。
- ログ用のパーティションを作成します（例：
- 圧縮を有効にする：ツール：
logrotateを使って古い監査ログを圧縮し、ストレージ要件を大幅に削減します。 - 保持ポリシー：組織のニーズに基づいて保持ポリシーを定めます。例：
- トラブルシューティングのためにログを 30 日間保持します。
- 古いログは、コンプライアンス目的で外部ストレージにアーカイブします。
パフォーマンス上の考慮事項
Auditd のパフォーマンスへの影響は、ほとんどのシステムではごくわずかです。ただし、トラフィックの多いサーバー（Web サーバーやデータベースサーバーなど）では、監査を有効にした後に CPU と I/O の使用量を監視してください。必要に応じて、次のようにします。
- システム全体を監視するのではなく、監査ルールの対象を重要なファイルやディレクトリに限定します。
- サンプリング手法を使って、ログの頻度を減らします。
2. システムイベントの追跡と記録ツール： auditd の使い方
ツール： auditd は、システム監査のための最も堅牢なソリューションの一つであり続けています。実際の利用に向けた追加の考慮事項は次のとおりです。
高度な監査ルール
すべてのファイルを監査するのではなく、重要な領域に焦点を当てます。
- システム設定ファイル：
sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config_changes
- 機密ディレクトリ：
sudo auditctl -w /var/www/html -p rwxa -k web_access
- ユーザーアクティビティ：
特定のユーザーやグループを監視します。
sudo auditctl -a always,exit -F uid=1001 -F arch=b64 -S execve -k user_commands
監査ログを分析するツール
監査ログは膨大になることがありますが、いくつかのツールを使えばデータを整理して分析できます。
- Aureport：監査ログから概要レポートを生成します。
sudo aureport --summary - Auditbeat：可視化と分析のために監査ログを集中型 ELK スタックに送信する、Elastic の軽量ツールです。
- Auditbeat をインストールする：
sudo apt install auditbeat - Elasticsearch または Logstash にログを送信するよう設定します。
- Auditbeat をインストールする：
- Splunk：高度な検索・レポート機能を備えた商用ログ分析ツールです。
3. 監査ログのためのディスク容量計画
ディスク容量計画の例
次のように仮定します。
- 1 日の監査ログは 500 MB を使用します。
- ログは毎週ローテーションされ、元のサイズの 20% まで圧縮されます。
ディスク容量の計算：
- 7 日分の未圧縮ログ：500 MB×7=3.5 GB500MB×7=3.5GB
- 30 日分の圧縮済みログ：500 MB×30×0.2=3 GB500MB×30×0.2=3GB
- 必要なストレージの合計：3.5 GB+3 GB=6.5 GB3.5GB+3GB=6.5GB
予期しない急増に備えて、少なくとも 10 GB を確保します。
4. ログローテーション設定ツール： logrotate
ログローテーションは、ログのサイズを管理する上で重要です。以下に、監査ログとシステムログの高度な設定を示します。
監査ログのローテーション
監査ログは次のデーモンによって自動的に管理されます。 auditd のローテーションをカスタマイズするには、次のようにします。
- 次のファイルを編集します。
/etc/audit/auditd.conf：
max_log_file = 50 # Maximum size in MB for audit.log
max_log_file_action = rotate # Rotate logs when size exceeds limit
- 設定をテストする：
sudo service auditd restart
その他のログのローテーション
監査ログ以外のログには、次を使います。 logrotate：
- 次の例：
/var/log/syslogの設定例：
/var/log/syslog {
weekly
rotate 4
compress
missingok
notifempty
create 0640 root root
}
5. 高度な監視と監査の手法
リアルタイムログ監視
リアルタイム監視は、重要なイベントを検出するために不可欠です。ツールと手法は次のとおりです。
- Logwatch：毎日のログを要約し、管理者にメールで送信します。
sudo apt install logwatchで設定します。設定ファイル：/etc/logwatch/conf/logwatch.conf。 - 集中ログ管理：
- Rsyslog：ログを中央サーバーに転送します。
sudo apt install rsyslogの設定ファイル：/etc/rsyslog.confを使って、リモートサーバーにログを送信するよう設定します。 - Graylog：ログ分析のための Web ベースのインターフェースを提供します。
- ELK Stack：スケーラブルなログ管理のための Elasticsearch、Logstash、Kibana。
- Rsyslog：ログを中央サーバーに転送します。
セキュリティ重視の監視
- Fail2ban：ログイン失敗をログから監視し、IP をブロックします。
sudo apt install fail2ban
- Tripwire：侵入検知のためにファイルの変更を検出します。
sudo apt install tripwire
アラートの統合
次のようなツールを使って、重要なイベントのアラートを設定します。
- Nagios：サーバーの状態とログを監視し、異常を検出します。
- Prometheus with Grafana：メトリクスとログをリアルタイムで追跡します。
ログファイルの場所
ログファイルにはさまざまな種類があり、それぞれ目的が異なります。何かに関するログを探すときは、まず最も関連性の高いファイルを特定することから始めましょう。以下に、一般的なログファイルの場所の一覧を示します。
システムログ
システムログは、その名のとおり Ubuntu システムそのものを扱うもので、ユーザーが追加したアプリケーションとは異なります。これらのログには、認証、システムデーモン、システムメッセージに関する情報が含まれることがあります。
認証ログ
場所： /var/log/auth.log
パスワードプロンプト、コマンド、リモートログインなどの認証システムの記録を保持します。コマンド： sudo 。
デーモンログ
場所： /var/log/daemon.log
デーモンは、通常ユーザーとの対話なしにバックグラウンドで実行されるプログラムです。たとえば、ディスプレイサーバー、SSH セッション、印刷サービス、Bluetooth などがあります。
デバッグログ
場所： /var/log/debug
Ubuntu システムとアプリケーションのデバッグ情報を提供します。
カーネルログ
場所： /var/log/kern.log
Linux カーネルからのログ。
システムログ
場所： /var/log/syslog
システムに関するさらに詳しい情報が含まれています。他のログで何も見つからない場合は、おそらくここにあります。
アプリケーションログ
一部のアプリケーションは、次の場所にもログを作成します。 /var/log。以下に例を示します。
Apache ログ
場所： /var/log/apache2/ （サブディレクトリ）
Apache は、次のサブディレクトリに複数のログファイルを作成します。 /var/log/apache2/ 。ファイル： access.log は、ファイルにアクセスするためにサーバーに対して行われたすべてのリクエストを記録します。ファイル： error.log は、サーバーが出力したすべてのエラーを記録します。
X11 サーバーログ
場所： /var/log/Xorg.0.log
X11 サーバーは、ディスプレイごとに個別のログファイルを作成します。ディスプレイ番号は 0 から始まるため、最初のディスプレイ（ディスプレイ 0）は次のファイルにログを出力します。 Xorg.0.log。次のディスプレイ（ディスプレイ 1）は次のファイルにログを出力します。 Xorg.1.log、以下同様です。
人間が読めない形式のログ
すべてのログファイルが人間が読むことを想定して作られているわけではありません。アプリケーションによる解析を目的として作られたものもあります。以下に例をいくつか示します。
ログイン失敗ログ
場所： /var/log/faillog
ログイン失敗に関する情報を含みます。次のコマンドで表示できます。 faillog 。
最終ログインログ
場所： /var/log/lastlog
最終ログインに関する情報を含みます。次のコマンドで表示できます。 lastlog 。
ログイン記録ログ
場所： /var/log/wtmp
他のユーティリティがログイン中のユーザーを確認するために使うログイン情報を含みます。現在ログイン中のユーザーを表示するには、次のコマンドを使います。 who 。
まとめ
監査とログ記録は、安全で信頼性の高い Ubuntu サーバーを維持するために不可欠です。ディスク容量を慎重に計画し、ログを分析するツールを使い、高度な監視手法を導入することで、よくある課題を克服し、システムアクティビティをよりよく把握できます。
コンプライアンス要件の管理でも、サーバーの能動的な保護でも、この記事で解説した手法とツールは、スケーラブルで効果的なログ記録・監査戦略の構築に役立ちます。
次回： Ubuntu Server 向けシステム監視ツール
次回の記事では、 監視とパフォーマンス管理についてさらに深く掘り下げます。強力な Ubuntu Server 向けシステム監視ツールについて解説します。たとえば、 Nagios、 Prometheus、 Grafana、 htopなどを使って、リソース使用量の追跡、ボトルネックの検出、サーバーパフォーマンスの最適化を行う方法を紹介します。
サーバーを効率的に稼働させ続け、潜在的な問題が運用に影響する前に能動的に対処する方法を、次回もお楽しみに！
3 thoughts on “09. Audit and Logging on Ubuntu Server: A Comprehensive Guide”