多くの障害はログに兆候を残し、不正アクセスの痕跡もまたログに刻まれる――。
それがデータベース監査ログ（Audit Log）です。
しかし、実際の運用現場では「とりあえず保存してるけど見てない」「どれが重要かわからない」といった声もよく聞かれます。
この記事では、エンジニアが押さえておきたい監査ログの基礎、見るべきポイント、不正や障害を見抜くコツをわかりやすく解説します。
そもそも「監査ログ」とは？
監査ログとは、誰が・いつ・どのような操作をしたかという“足跡”を記録するためのログです。通常のクエリログやエラーログと違い、主にセキュリティ監査・トラブル対応・コンプライアンスの目的で使われます。
記録内容には、以下のようなものがあります：
- 接続元IPアドレス
- ログインユーザー名
- 実行されたSQL文
- 実行時刻
- 成否（成功／失敗）
- 対象テーブルやスキーマ など
この情報があれば、例えば「誰がDELETEしたのか？」「深夜にログインしたのは誰か？」「障害発生直前に何があったのか？」を追跡できるわけです。
代表的なDBごとの監査ログ機能
MySQL
general_log: 全てのSQLを記録（パフォーマンスに注意）audit_log（Enterprise版）: より詳細な監査用ログ。誰が何をしたかを明確に追跡可能。
PostgreSQL
pgaudit: 拡張モジュールで監査機能を強化。SELECT/INSERTなど操作ごとに分類できる。log_statement = 'all': 全クエリ記録。ただしログ肥大に注意。
SQL Server
SQL Server Audit: GUI・TSQL両方で設定可能。SELECT含む詳細なトラッキングが可能。
Oracle
AUDIT文で細かく監査設定。接続・操作・失敗ログなど、強力な機能を標準で提供。
見るべき監査ログのポイント
膨大なログの中から、特に注目すべきアクションは以下です。
1. 認証失敗ログ
Failed login from IP 203.0.113.42 using user 'admin'
- 繰り返す失敗 → ブルートフォース攻撃の兆候
- 深夜帯など通常と異なるアクセス → 内部不正の可能性
2. 権限外操作の試行
ERROR: permission denied for table customer_data
- 誰がいつ、どのテーブルでエラーになったか
- 開発者が誤って本番データを操作しようとした痕跡もここに現れる
3. DML（INSERT/UPDATE/DELETE）操作
- 特にDELETEやUPDATEなど破壊的操作は重要
- 何時・誰が・どのテーブルに・どれだけの件数かをチェック
4. スキーマ変更系操作（DDL）
ALTER TABLE accounts ADD COLUMN sensitive_data text;
- 本番環境で意図せぬDDLは大事故のもと
- CI/CD外で行われた手動作業が検出できる
不正アクセスを見抜くパターン
✔ 典型例：
- 普段アクセスのない時間帯（例：03:00〜04:00）のログイン
- 一般ユーザーによる管理者向けテーブルへの操作
- 複数のIPアドレスから短時間にログイン試行（スキャニング）
✔ 要注意パターン：
- 同一ユーザー名による複数の失敗ログイン
- 1回のセッションで数百件のSELECT/UPDATE/DELETE
障害予兆を見抜くには？
✔ 前兆ログ例：
- クエリエラーやタイムアウトの頻発
- 接続数の急増、遅延ログの蓄積
- 特定のテーブルに対する重いUPDATE
こうした情報が、障害発生“直前”の監査ログに残っていることは少なくありません。
日頃から監査ログを監視・定期レビューしておくと、障害の早期察知・未然防止に繋がります。
監査ログ活用のベストプラクティス
- 定期的なログの自動収集と集約
- FluentdやFilebeat、CloudWatchなどで集中管理
- 監査対象を絞って記録
- 全てのSELECTではなく、特定テーブルの変更操作に絞る
- アラート連携
- 異常な操作（深夜ログイン、失敗回数超過）を監視ツールと連携して通知
- 定期レビューとレポート作成
- 毎月ログのサマリを作成し、チームでレビューする文化づくり
おわりに：ログは語る、見れば見える
監査ログは地味で目立たない存在ですが、「何が起きたか」を証明できる唯一の証人です。
障害対応での“あの時誰が何をしたのか”を可視化し、不正アクセスやミスの痕跡も残さず記録します。
「なんかおかしいな」と感じたら、まずはログを見ましょう。
そして何も起きていないときこそ、ログを“仕込んでおく”のがインフラ・運用エンジニアの真価です。
