Vault Audit Devices の概要: 改ざん防止と保管の実務

Vaultは要求と応答を監査デバイスに書き出すことで、操作の追跡可能性を担保します。

本稿では、監査ログの改ざん防止と保管(保持・ローテーション・集約)を中心に、実務と資格対策の両面から整理します。

監査デバイスの基本と改ざん耐性の考え方

Vaultの監査デバイスは、各リクエスト/レスポンスのメタデータを出力します。代表的な種類はfile、syslog、socketで、複数同時に有効化できます。実運用では少なくとも1つ以上の監査デバイスを有効化し、できれば異なる経路に二重化しておくのが定石です。

監査ログ内の機微値(トークン、秘密値など)は、監査デバイスごとの鍵でHMAC化され、値そのものは記録されません。これにより、機微情報の漏えいを防ぎつつ、一貫したハッシュで相関分析が可能です。改ざん防止は、HMAC化に加えて、保管先の不変化(append-only/WORM/権限)と経路の耐タンパ性で確保します。

• デフォルトでは監査は無効。運用前に有効化すること
• 各デバイスは独立したHMAC鍵を持つため、同一値でもハッシュはデバイスごとに異なる
• いずれかの有効な監査デバイスへの書き込みに失敗すると、要求を失敗させて未監査操作を防ぐ挙動が通常のデフォルト
• 改ざん防止は「HMACでの秘匿」＋「改ざん困難な保存先」＋「経路保護(リモート転送/TLS)」の三点で設計する

監査ログの改ざん防止と保管パス(例)

有効化の最小ステップ: 一覧とfileデバイスの追加

vault audit list
vault audit enable file file_path=/var/log/vault_audit.log mode=0640
# 推奨: root所有、ディレクトリは事前作成、監査専用パーティションも検討

有効化と構成パターン

監査デバイスは名前付きで有効化し、/sys/audit/<name> にマウントされます。file/syslog/socketはいずれも複数同時に設定可能です。異系統(ローカル保管＋リモート集約)の二重化が運用上の定石です。

fileは書き込み権限とローテーション設計が要。syslog/socketはネットワーク健全性が監査の可用性に直結します。初期構成時は、権限・パス・ネットワーク(防火壁/TLS)を最優先で点検してください。

• file: file_path とパーミッション(mode)を明示
• syslog: facility/tagを使って集約先でのフィルタを容易に
• socket: socket_type(tcp/udp/unix)とaddressを指定。Collector側の可用性をSLOに反映
• 複数デバイスを併用し、片系障害時も監査欠落を避ける

CLIとAPIでの設定例(syslog/socketも含む)

# syslog 例
vault audit enable syslog tag=vault facility=AUTH

# socket 例 (TCPでコレクタへ)
vault audit enable socket socket_type=tcp address=collector.internal:1514

# APIでfileデバイスを有効化
curl -sS \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request PUT \
  --data '{"type":"file","options":{"file_path":"/var/log/vault_audit.log","mode":"0640"}}' \
  $VAULT_ADDR/v1/sys/audit/file-1

# 無効化
vault audit disable file-1

ログ形式と機微情報のHMAC

監査ログは行単位のJSONが一般的です。代表的な要素はtime, type, request(操作/パス/リモートアドレス/ヘッダ), auth(アクセサ/ポリシー), response(コード/警告), error等です。機微値は監査デバイスごとの鍵でHMAC化されます。

同一の実値を検索する場合、対象デバイスのハッシュをVaultに計算させて突き合わせます。これにより、値そのものを知られることなく、当該値が関与した操作を相関できます。

• HMACはデバイスごとに異なるため、検索は対象デバイス単位で実施
• トークンやシークレット値は平文では出ない想定で運用設計する
• path/operation/remote_address/response_statusなどでユースケース毎のフィルタを準備すると分析が早い

サンプル行とハッシュ検索

# サンプル監査行(JSON一行)
{"time":"2026-04-19T09:12:34.567Z","type":"request","auth":{"client_token":"hmac-sha256:7f...","accessor":"hmac-sha256:62...","policies":["default"],"display_name":"token"},"request":{"id":"6f...","operation":"read","path":"secret/data/foo","remote_address":"10.0.0.5"},"response":{"status":200},"error":false}

# 値のハッシュを生成し、ログ検索に利用
vault audit hash file/ my-actual-token
# => hmac-sha256:abc123...
# 生成されたハッシュ文字列でログをgrep/jq検索

保管・ローテーションと可用性の設計

改ざん防止は、保管面の堅牢化が肝です。fileならパーミッションを最小化し、append-onlyやWORMストレージを併用。syslog/socketならリモート受信側での不変化(改ざん検出/監査証跡の連鎖保護)を確保します。

ローテーションは容量枯渇を防ぐ基本策です。fileではcopytruncateやrename＋SIGHUPなど、運用環境に合わせた確実な手順を選択します。監査デバイスは書き込み不能時に要求を失敗させるのが通常挙動のため、回線断やディスクフルの演習を通じてSLOへの影響を把握してください。

• ファイル: 所有者root、mode 0640程度、監査専用パーティションで枯渇影響を隔離
• ローテーション: copytruncate or rename＋SIGHUP。再オープン手順を定期検証
• リモート集約: 受信先はWORM/バージョニング/削除監査を有効化
• 二重系: file＋syslog(またはsocket)の併用で監査欠落を防止

logrotateの一例(fileデバイス向け)

/var/log/vault_audit.log {
  daily
  rotate 14
  compress
  missingok
  notifempty
  copytruncate
  create 0640 root root
}
# 監査要件に応じて保持期間/圧縮/暗号化を調整

運用検証とトラブルシュート

構成後は、書き込み検証を自動化します。簡易には、意図的にAPIを呼んで監査行が増えることを確認し、collector側でも同数の受信を確認します。

障害時は、vault audit listの状態、出力先の権限/空き容量、collector到達性を確認。監査書き込みに失敗しているときはリクエスト自体が失敗するため、アプリケーション側のエラー率上昇で気付きやすいです。

• vault audit list で複数デバイスがenabledになっているかを確認
• jq/grepで直近のrequest行を確認し、時刻とop/pathを突き合わせ
• collector側の受信カウンタと件数整合をチェック
• 権限エラー(EACCES)、ディスクフル(ENOSPC)、ネットワーク断(ETIMEDOUT)を想定試験

検証用スニペット

# 監査デバイス一覧
vault audit list -format=json | jq '.'

# ダミーリクエストで監査行を発生
vault kv get -field=value secret/data/foo || true

# fileに出る最新10行を確認
tail -n 10 /var/log/vault_audit.log | jq -c '{time,type,req:(.request|{op:.operation,path})}'

# 値検索に必要なHMACの生成
vault audit hash file/ my-actual-token

試験対策: Associate/Opsで問われやすい要点

試験では、監査の有効化/種類、HMACの意義、冗長化、障害時の挙動、検索方法(audit hash)が頻出です。実務との接点を意識して要点を押さえましょう。

• 監査はデフォルト無効。運用前に少なくとも1系をenable
• file/syslog/socketの使い分けと、二重化のベストプラクティス
• 機微値はHMAC化。値の相関は vault audit hash で計算して検索
• いずれかの監査デバイスが書けない場合、要求は失敗する挙動が基本
• ローテーションと権限の設計(0640、root所有、append-only/WORM)
• 中央集約/リモート保管時はTCP/TLSやmTLSで経路保護

問題で確認

よくある質問