Vault Database シークレットエンジン徹底攻略: 動的クレデンシャル発行の設計と運用

アプリが毎回ユニークなDBユーザとパスワードをVaultから受け取り、TTL切れで自動失効する。これがDatabaseシークレットエンジンの中核です。

本稿は、なぜ動的発行が安全なのか、最小構成の手順、ローテーションと失効、ポリシー設計、試験に出やすいポイントまでを一気通貫で解説します。

なぜ動的クレデンシャルか: リスク低減と運用負荷の最適化

動的クレデンシャルは、Vaultが要求のたびに短命なDBユーザを作成し、TTL満了や明示的リボークで確実に破棄する方式です。長期共有パスワードや人手配布に比べ、漏洩時の影響半径を小さくできます。

監査性も高く、誰がいつどのロールで資格情報を取得したかをVaultの監査ログで追跡可能です。障害時の切り戻しやインシデント対応においても、リース単位での失効が即効性を持ちます。

• 原則: 各取得リクエスト=一時ユーザ+一意パスワード+Lease
• TTL/Max TTLで寿命を制御。満了時は自動撤去（ユーザ削除等）
• 監査ログとポリシーで最小権限・責任追跡を両立

アーキテクチャとLeaseの動き

Databaseシークレットエンジンはプラグイン（例: postgresql-database-plugin）を通じてDBに接続し、ロール定義に基づくSQLを実行してユーザを作成します。Vaultは生成した資格情報をLeaseに紐付け、TTL満了時に撤去SQLを実行します。

アプリはVaultへのRead権限のみを保持し、DBの作成・削除はVaultが代行します。これにより、アプリケーションからDB管理権限を切り離せます。

• Creation statements: ユーザ作成/権限付与のSQL
• Revocation statements: 期限切れ時のユーザ削除/無効化
• Lease: TTLと再更新可否を管理。失効で自動撤去

動的クレデンシャル発行のフロー

最小セットアップ（PostgreSQL例）

以下は最小手順の一例です。実DBの接続ユーザ（例: vault_admin）にはユーザ作成・権限付与・削除権限が必要です。接続URLやTLS設定は環境に合わせて調整してください。

creation_statementsでは、作成する一時ユーザ名やパスワードをVaultのテンプレート変数で受け取り、必要最小限の権限だけを付与します。

• 本番ではDB接続をTLS必須にし、Vault側の最小権限を保証
• default_ttlとmax_ttlは要件に合わせて慎重に設定
• アプリには database/creds/<role> のRead権限のみを付与

Vault CLIでの設定と取得（PostgreSQL）

export VAULT_ADDR=https://vault.example.com
export VAULT_TOKEN=hvs.xxxxx

# 1) Databaseシークレットエンジンを有効化
vault secrets enable database

# 2) DB接続設定（postgresql-database-plugin）
vault write database/config/my-postgresql \
  plugin_name=postgresql-database-plugin \
  allowed_roles=app-readonly \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=require" \
  username="vault_admin" \
  password="s3cr3t"

# 3) ロール定義（読み取り専用の一時ユーザを作成）
vault write database/roles/app-readonly \
  db_name=my-postgresql \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\"; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO \"{{name}}\";" \
  revocation_statements="REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM \"{{name}}\"; DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

# 4) アプリが資格情報を取得（動的）
vault read database/creds/app-readonly
# 出力例
# Key                Value
# lease_id           database/creds/app-readonly/xxxxx
# lease_duration     1h
# lease_renewable    true
# password           A1b2C3d4e5f6g7h8
# username           v-token-app-readonly-1693258841-abcde

# 5) 最小権限ポリシー（アプリ用）
cat <<'EOF' > app-readonly.hcl
path "database/creds/app-readonly" {
  capabilities = ["read"]
}
EOF
vault policy write app-readonly app-readonly.hcl

# 必要ならアプリ用トークンを発行（例）
vault token create -policy=app-readonly -display-name=app-A

# 6) 失効（インシデント対応など、即時剥奪）
vault lease revoke database/creds/app-readonly/xxxxx

# 7) 接続ユーザのローテーション（定期的なベストプラクティス）
vault write -f database/rotate-root/my-postgresql

運用: TTL/リース、ローテーション、撤去のベストプラクティス

Leaseの更新はmax_ttlの範囲内で可能です。更新すると、Vaultの失効スケジュールが延長され、ユーザ削除（撤去）タイミングが後ろ倒しになります。ロール設計上、長期接続が不要ならdefault_ttlを短く維持します。

接続ユーザ（VaultがDBに接続するための固定アカウント）はrotate-rootでローテーション可能です。これにより、Vault-DB間の固定資格情報の露出期間を短縮できます。

• lease renewは期限延長。max_ttl超過は不可
• インシデント時はlease revokeで即時失効
• 定期的にdatabase/rotate-root/<db_name>を実施
• 監査ログで誰がどのロールを取得したかを確認

ポリシー設計: アプリ権限の最小化と境界管理

アプリは原則として database/creds/<role> のread権限のみを持たせます。書き込みや一覧取得は不要です。ロールごとにパスを分離すると、サービス間の境界が明確になります。

同一アプリでも開発・検証・本番でロール名を分離し、環境越境を防止します。NamespaceやMount Pathを分けるのも有効です。

• pathはロール単位でスコープ限定
• 環境別ロール/パスで越権防止
• ポリシーのレビューと監査ログの定期点検

トラブルシュートと試験対策ポイント

よくある失敗は、接続ユーザの権限不足（ROLE作成やGRANT不可）や、creation_statementsのエスケープ不備、DB接続のTLS要件未満です。まずはVaultログとDBサーバログの両方を併読します。

Associate / Ops向けには、Lease/TTL/Max TTLの関係、rotate-rootの意味、lease revokeの効果、allowed_rolesの制約などが頻出です。

• allowed_rolesにロール名が含まれていない→取得失敗
• max_ttl < default_ttl の誤設定→作成時エラー
• 時刻ずれ（NTP未整備）→TTL挙動が不安定に見える
• DB側オブジェクト権限の継承/既定権限に注意

問題で確認

よくある質問