Vault File Audit Device実践ガイド：ローカルファイル出力の安全運用

Vaultの監査ログは、だれがいつ何を要求し、Vaultがどう応答したかを追跡する基盤です。File Audit Deviceは、これをホストのローカルファイルへ1行1イベントのJSONとして書き出します。

本稿は、ローカルファイル出力にフォーカスし、試験で問われやすいコマンドや用語、実務運用で外せない権限・ローテーション設計、セキュリティ上の落とし穴までを、手を動かせる粒度で解説します。

Vault File Audit Deviceの概要とローカルファイル出力

Vaultの監査デバイスは、リクエストとレスポンスのメタデータを記録します。File Audit Deviceは最もシンプルで、指定したパスに追記型でJSON行を出力します。センシティブな値は既定でHMAC化され、平文が残らない設計です。

ローカルファイル出力は、単一ノード構成、OS標準のlogrotate利用、エージェントによる転送（FilebeatやFluent Bitなど）と組み合わせる際に適しています。認定試験では、有効化・無効化のコマンド、パラメータ名（file_path）、HMACの性質（既定で機密値はハッシュ化）あたりが頻出です。

• 長所: 設定が簡単、依存が少ない、OS標準の運用に乗せやすい
• 注意: 各ノードでファイルが分散、権限/ローテーションの設計が必須、ディスク不足の影響に注意
• 用途: まずはローカルで確実に残し、別途集約基盤へフォワード

ローカルファイル出力の流れ

監査デバイス一覧の確認

vault audit list -detailed

有効化と基本設定コマンド

有効化は1コマンドで完了します。事前にディレクトリを作成し、Vaultプロセスが書き込める所有者・パーミッションにしておきます。既定では機密値はHMAC化されるため、平文が出ない設定がデフォルトです。

有効化後は、実際にリクエストを1つ発生させて（例: vault status や kv操作）ファイルにイベントが出力されることを確認します。無効化はマウントパス（例: file/）を指定します。

• 必須パラメータ: file_path=/var/log/vault/audit.log
• 推奨: ログファイルのパーミッションを0640程度にし、所有者をvaultユーザに限定
• 注意: log_raw=trueは平文を出力するため通常は使用しない（既定はfalse）

有効化〜確認〜無効化の例

sudo mkdir -p /var/log/vault
sudo chown vault:vault /var/log/vault

# 監査デバイス有効化（ローカルファイル）
vault audit enable file file_path=/var/log/vault/audit.log

# 状態確認
vault audit list -detailed

# 動作確認（イベント発生）
vault status
sudo tail -n1 /var/log/vault/audit.log

# 無効化（デフォルトのパス名は file/）
vault audit disable file/

監査ログの構造と読み方（JSON）

File Audit Deviceは1イベント1行のJSON（いわゆるNDJSON）で出力します。代表的なフィールドは、time、type（request/response）、request.path、request.operation、remote_address、auth情報（ポリシー等）、errorの有無などです。機密にあたる値（例: シークレットデータやトークン値）は既定でHMAC化され、平文は残りません。

相関調査が必要な場合は、監査ハッシュAPI（sys/audit-hash/<デバイス名>）で、特定の文字列がログ中でどのHMAC値になるかをローカルで計算できます。これにより、平文を保存せずに追跡できます。

• JSONは行単位で完結するため、収集・検索基盤に取り込みやすい
• HMACは監査デバイスごとにソルト化されるため、異なるデバイス間で同一値にならない点に注意
• error=trueの行はアラート対象にしやすい

サンプル行（一部フィールドを短縮）

{
  "time":"2026-04-19T10:15:30.123456Z",
  "type":"request",
  "auth":{
    "client_token":"hmac-sha256:2f9c...",
    "display_name":"root",
    "policies":["root"]
  },
  "request":{
    "id":"c7b0...",
    "operation":"read",
    "path":"sys/health",
    "remote_address":"192.0.2.10",
    "data":{
      "foo":"hmac-sha256:91ab..."
    }
  },
  "response":{
    "status":200
  },
  "error":false
}

実運用のポイント：権限、ローテーション、監視

権限は最小化が基本です。監査ログディレクトリはvaultユーザ所有、グループは閲覧が必要なロールのみに限定し、ファイルは0640程度に。バックアップや転送エージェントの読取りアクセスは最小限に抑えます。

ローテーションはOSのlogrotateなど既存基盤を使います。copytruncate方式は簡単ですが、一時的な行欠落の可能性も理解した上で採否を決めます。ローテーション後の権限（create句）や圧縮、世代数を明示しましょう。ディスク使用量監視（しきい値と通知）は必須です。

• 監査ログは機密性が高い前提で保管（暗号化ボリューム推奨）
• 収集はエージェントの読取り専用で行い、書込み権限はVaultのみに限定
• 容量・inode・I/Oレイテンシ監視を合わせて実装
• コンテナではstderrデバイス＋外部ログ基盤という選択肢も検討

logrotate設定例（/etc/logrotate.d/vault-audit）

/var/log/vault/audit.log {
  weekly
  rotate 12
  compress
  dateext
  missingok
  notifempty
  create 0640 vault vault
  copytruncate
}

セキュリティとコンプライアンス

log_rawは既定で無効であり、平文のシークレットが出力されないのが基本挙動です。検証以外でlog_raw=trueにすることは避けます。閲覧権限は職務分掌に基づき厳格に付与し、アクセスの監査証跡も残しましょう。

HMACは監査デバイス単位でソルト化されます。調査時は監査ハッシュAPIで同等値を生成して照合します。保持期間・暗号化・改ざん検知（WORM等）は社内規程・外部規制（例: 金融、医療）に準拠させます。

• 監査ログの保存先は暗号化し、転送経路もTLSで保護
• 保持・削除ポリシーを明文化し、定期レビューを実施
• 監査デバイスは複数同時有効化が可能（冗長性・集約の両立）

HMAC値の照合（監査ハッシュAPIの例）

# 監査デバイス名が file/ の場合
vault write sys/audit-hash/file input="[email protected]"

トラブルシューティングと試験対策の要点

Permission deniedやNo such file or directoryが出る場合は、ディレクトリの存在・所有者・SELinux/AppArmorの制約を確認します。ファイルに出力されない場合、監査デバイスの有効化状態（vault audit list）と、実際にイベントを発生させたか（操作を行ったか）を切り分けます。

試験対策としては、enable/disable/listコマンド、必須パラメータfile_path、機密値が既定でHMAC化される点、ローカルファイル出力はローテーションをOS側で行うという運用前提を押さえておけば得点につながります。

• 書込み不可: ディレクトリ作成、chown/chmodを適正化
• ログが増えない: 直近の操作でイベントが出たか、tailと時刻を確認
• クラスタで分散: 各ノードにファイルが出る点を理解し、集約戦略を用意
• 解析はNDJSON前提: 1行=1イベントで取り込む

動作確認のワンライナー（イベント発生→直近行を確認）

vault kv put secret/demo foo=bar
sudo tail -n1 /var/log/vault/audit.log | jq -r '.type + " " + .request.path'

問題で確認

よくある質問