Vault 監査ログを Syslog に集約する実装

Vault の監査（Audit）は、全 API リクエストとレスポンスを耐改ざん性を意識した JSON で記録します。Ops では、これを Syslog に集約し、SIEM やログ基盤に連携する設計が定番です。

本稿は、公式仕様に沿って「ファイル監査デバイス」「ソケット監査デバイス」を使い分け、rsyslog/syslog-ng で集約する実装をまとめます。バージョン差異が出やすい箇所は注意書きを添え、認定試験（運用系）で問われやすい要点も押さえます。

監査と Syslog 集約の全体像

Vault は 1 台に複数の監査デバイスを同時に有効化できます。一般的には、各ノードで JSON 監査ログを出力し、ローカルの syslog デーモン（rsyslog/syslog-ng）で収集・転送します。これにより、Vault の可用性とログ収集の責務を疎結合にできます。

Syslog への集約パターンは大きく 2 つです。1) ファイル監査デバイスでローカルに書き出し、syslog のファイル入力モジュールで収集。2) ソケット監査デバイスで /dev/log（unixgram）に直接書き込み、syslog に即時取り込み。どちらも公式ドキュメントに沿った安定パターンです。

• 監査ログはデフォルトで機密値に HMAC を適用（平文は記録しない）
• 監査デバイスは HA クラスタ全体に複製（local=true 指定時を除く）
• 本番で log_raw=true は使わない（機密値が平文で出る）
• Syslog 連携は OS・ディストリビューションの標準機能を活用

Vault 監査ログの Syslog 集約（代表パターン）

Alternative: Vault (socket unixgram) → /dev/log → rsyslog → SIEM

監査デバイスの一覧確認（詳細）

vault audit list -detailed

ファイル監査デバイスから rsyslog に集約する

最も移植性が高いのが、ファイル監査デバイスで JSON を出力し、rsyslog の imfile で収集する方式です。I/O とローテーションを適切に設計すれば、取りこぼしに強く、トラブル時の切り分けも容易です。

rsyslog 側では、入力（imfile）→ 必要に応じて整形 → リモートへ転送（TLS 推奨）という直列構成にします。Vault からは JSON が出力されるため、整形は不要なことが多いです。

• Vault 側は file_path の権限を 0600 など最小化
• rsyslog は inotify で追従。大容量時はキュー設定を追加
• リモート転送は TCP/TLS（失敗時の再送・キュー）を有効化

Vault と rsyslog の代表構成（例）

# Vault: ファイル監査デバイスを有効化（本番で log_raw は使わない）
vault audit enable -path=file file file_path=/var/log/vault_audit.log mode=0600

# 動作確認（エントリ生成）
vault kv put secret/demo foo=bar

tail -n1 /var/log/vault_audit.log

# rsyslog: imfile で取り込み、TLS で中央へ転送（/etc/rsyslog.d/50-vault.conf）
module(load="imfile")
input(type="imfile" File="/var/log/vault_audit.log" Tag="vault" Severity="info" Facility="local6")
action(type="omfwd" Target="syslog.example.com" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="syslog.example.com")
# 必要に応じてキューを有効化
# action(type="omfwd" ... queue.type="LinkedList" queue.size="10000" queue.filename="vault_audit")

ソケット監査デバイスで /dev/log に直接送る

ディスクを経由せずに syslog に渡したい場合は、ソケット監査デバイスで /dev/log（unixgram）へ送ります。多くの Linux で /dev/log は datagram（unixgram）です。rsyslog や syslog-ng はこれを受けて標準のフィルタ・転送ルールを適用します。

バージョンによりオプション名やサポートが異なる場合があります。以下は代表的な指定例です。unix ドメインソケットは path、UDP/TCP は address と type を使います。運用投入前に開発者ドキュメントの該当バージョンを必ず確認してください。

• unixgram はローカル限定・低遅延。syslog 停止時はバックプレッシャ有り
• UDP/TCP はネットワークの到達性に依存。信頼区画で利用
• 障害切り分けは logger(1) や nc/socat でローカル受信確認

ソケット監査デバイスの設定例

# /dev/log に送る（多くの Linux の syslog が受ける）
vault audit enable -path=syslog socket type=unixgram path=/dev/log

# ローカル rsyslog の UDP ポートへ送る
vault audit enable -path=udp1514 socket type=udp address=127.0.0.1:1514

# 確認
vault audit list -detailed

# 障害切り分け（例：ローカルで UDP 1514 を仮受信）
sudo nc -ul 1514

運用設計：ローテーション、可用性、バックプレッシャ

ファイル方式では、ログローテーションの方式を明確化します。copytruncate はプロセスの再オープン不要ですが、極端な高負荷で一時的な取りこぼしの可能性があります。安全側に振るなら、十分なディスク余裕とキューを設けて転送を安定化します。

ソケット方式はディスクを介さない一方で、受け側が詰まると Vault にバックプレッシャが返り、最悪リクエスト処理に影響します。Syslog デーモン側のキュー、リモートへの堅牢な TCP/TLS 転送、再送設定が重要です。

• 監査デバイスは複数併用可（例：file と socket を同時に有効化）
• 停止前に vault audit list で現行構成を必ず保存
• HA 構成では、監査デバイス設定はデフォルトでクラスタ複製（local=true は除外）
• 監視指標：syslog キュー深さ、フォワード遅延、ディスク残量、Vault の request エラー率

logrotate の雛形（copytruncate 例。環境に合わせて調整）

/var/log/vault_audit.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
    create 0600 vault vault
}

セキュリティ：HMAC、機密の保護、検索性

Vault の監査ログは、シークレット値やトークン ID などの機密は HMAC 化されます。これによりログからの漏えいリスクを抑えつつ、同一値は同一ハッシュになる性質を使った相関が可能です。試験でも「監査ログに平文は残るか？」が定番です。答えは、log_raw=true にしない限り平文は出ません。

調査時にハッシュ値を逆算することはできませんが、vault audit hash コマンドで入力値を同じアルゴリズムで HMAC し、ログ中の値と突き合わせることができます。

• 本番で log_raw=true は不可。検証環境でも取り扱いを厳格に
• hmac_accessor オプションでアクセサの扱いを制御（バージョンに依存）
• Syslog 転送は TLS を既定にし、施設/タグでフィルタリング
• 最小権限の Vault ポリシーで監査操作を限定（sys/audit/*）

ハッシュ照合の例（調査時のワークフロー）

# 例: file/ という監査デバイス上で 'bar' の HMAC を得る
vault audit hash file/ value=bar
# 出力されたハッシュが、監査ログの request.data.foo に対応していれば一致
# jq 等でログを検索
jq -r 'select(.request.data.foo=="<ハッシュ>")' /var/log/vault_audit.log

試験対策とトラブルシュートの要点

Ops 系の出題では「どの監査デバイスを選ぶべきか」「機密を平文で残さないための設定」「HA と複数デバイスの併用」「syslog 取りこぼし時の影響」などが狙われます。選択肢に log_raw=true が紛れていたら、まず除外してください。

トラブル時は、1) vault audit list -detailed、2) syslog 側の受信確認（/dev/log, UDP/TCP ポート）、3) 一時的に file を追加して比較、という順で最小切り分けを行うと迅速です。

• 監査デバイスはいつでも追加可能。削除は計画的に（証跡要件）
• local=true は単一ノード限定のデバッグ用途（本番常用は避ける）
• ソケット方式で詰まりを検知したら、即時に file を併設して退避

即席の切り分け手順

# 監査デバイスの状態
vault audit list -detailed

# 追加で一時ファイル出力を有効化
aud_path=$(date +%s)
vault audit enable -path=file-$aud_path file file_path=/var/log/vault_audit_$aud_path.log mode=0600

# イベント生成と双方での到達確認
vault login -method=token token=<your-token>
tail -n1 /var/log/vault_audit_$aud_path.log

問題で確認

よくある質問