Vault Secrets Engines の概要: 静的・動的・暗号化の分類

Vault の中核は Secrets Engines（シークレットエンジン）です。エンジンはパスにマウントされ、各パスごとに「何をするか（保存・発行・暗号化）」が決まります。本稿では、試験で頻出の分類（静的・動的・暗号化/署名）に沿って、挙動・用途・試験観点を整理します。

Associate レベルでは、KV による静的管理、Database/AWS などの動的発行、Transit による暗号化/署名の違いを具体例で判別できることが重要です。TTL/Lease、Revoke/Renew、ポリシー適用、パス設計といった安定した基本概念に絞って解説します。

Secrets Engines の全体像と分類

Secrets Engine は Vault にマウントされるプラグインで、用途ごとにパスが分かれます。例えば kv/ はキー・バリューの保存、database/ は動的な DB 資格情報の発行、transit/ はデータの暗号化/署名を提供します。クライアントはトークン＋ポリシーでパスにアクセスし、エンジンが所定の動作を実行します。

分類の軸は「保存するのか（静的）」「都度発行するのか（動的）」「データそのものは持たず処理だけを行うのか（暗号化/署名）」です。設計と試験の両面で、この切り分けが最初の判断ポイントになります。

• 静的: 既存の値を保存・取得（例: kv）
• 動的: 一時的な資格情報を都度発行し、Lease/TTL を付与（例: database, aws）
• 暗号化/署名: データを保存せず、鍵を使って処理を提供（例: transit）
• ポリシーはパスに対して能力（read, create, update, delete, list, sudo）を付与
• Lease は「発行物」に付く寿命。トークン TTL/Renew と併せて管理

Vault による認可とエンジン呼び出しの流れ

代表的なエンジンの有効化（例）

# 管理者が必要なパスでエンジンを有効化
vault secrets enable -path=kv kv-v2
vault secrets enable -path=database database
vault secrets enable -path=transit transit

# 現在のマウント確認
vault secrets list -detailed

静的シークレット: KV エンジンの要点

静的シークレットは、保存された値を取得するシンプルなモデルです。最も一般的なのが kv で、アプリの設定値、API キー、Webhook トークンなどを保管します。Associate では、パス設計とポリシーの最小権限付与、そして運用（更新・削除・監査）が押さえどころです。

kv はバージョニング対応の実装が広く使われています。バージョン付きの場合は「最新/特定バージョンの取得」「論理削除/完全削除」などの操作が用意され、監査・ロールバックに役立ちます。試験でバージョニングの有無が問われる際は、メタデータと履歴管理がキーワードになります。

• ユースケース: 設定値や固定トークンの集中管理
• ポリシー: パス単位で read だけを付与し、create/update は限定
• ライフサイクル: 回転（定期更新）、ラベル/フォルダ分割、監査ログ
• セキュリティ: アプリは必要な最小パスのみを許可し、環境別（dev/stg/prd）で分離

KV の基本操作（保存/取得/バージョン管理の例）

# エンジンが未有効なら先に有効化
vault secrets enable -path=kv kv-v2

# 保存（create/update）
vault kv put kv/app/config api_key=xxx timeout=30

# 取得（最新）
vault kv get kv/app/config

# 上書き（新バージョン作成）
vault kv put kv/app/config api_key=yyy timeout=30

# 特定バージョンを取得（例: バージョン1）
vault kv get -version=1 kv/app/config

# 論理削除（最新を削除）
vault kv delete kv/app/config

# 完全削除（履歴自体を消去）
vault kv destroy -versions=1 kv/app/config

動的シークレット: Database/AWS などの発行エンジン

動的シークレットは、要求のたびに短命の資格情報を発行し、Lease/TTL で寿命を管理します。期限切れや Revoke により権限が無効化されるため、漏洩リスクの低減と最小権限の実装に適しています。代表例は database（RDBMS に対するユーザー/パスワード発行）と aws（IAM 資格情報の発行）です。

発行はロールに基づきます。ロールは接続先、権限（例: DB の GRANT）、TTL の上限、Renew 可否などを規定します。クライアントは read を呼ぶだけで新規資格情報が払い出され、レスポンスには lease_id, lease_duration, renewable などのメタデータが含まれます。

• Lease/TTL: 寿命が明確で、期限後は無効化
• Renew: 必要に応じて延長（上限 TTL に注意）
• Revoke: 即時無効化（漏洩・退役時）
• ロール設計: 最小権限プリンシプル、上限 TTL とローテーション方針
• 監査: だれが、どのロールから、いつ発行したか

Database エンジンの最小構成から発行/失効まで

# エンジンの有効化
vault secrets enable -path=database database

# 接続（例: PostgreSQL）。管理ユーザーで接続情報を登録
vault write database/config/appdb \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=disable" \
  username="vault_admin" \
  password="s3cr3t"

# ロールを定義（最小権限、TTL 設定）
vault write database/roles/app \
  db_name=appdb \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

# 動的資格情報の発行（read で新規払い出し）
vault read database/creds/app
# -> username/password と lease_id/lease_duration を受領

# 失効（漏洩時など即時無効化）
vault lease revoke <lease_id>

暗号化/署名: Transit エンジンの設計ポイント

Transit はデータを保存しません。鍵を Vault 側で保護・操作し、クライアントから渡された平文を暗号化/復号、データに署名/検証を行う“暗号化サービス”です。保存先（DB/S3 など）はアプリケーション側で管理します。

メリットは、アプリが鍵素材を直接扱わない点と、監査・ローテーション・アクセス制御を Vault に集約できる点です。用途は、機密列の暗号化、透過的なトークン署名、アプリ間のメッセージ認証など。

• データは保存しない（暗号文/署名を返す）
• キー管理の一元化（作成、ローテーション、無効化）
• 操作: encrypt/decrypt、sign/verify、rewrap（キーローテ時の暗号文更新）
• 権限は transit/keys/<name> や encrypt/decrypt パス単位に付与

Transit の鍵作成と暗号化/復号・署名/検証

# エンジンの有効化
vault secrets enable -path=transit transit

# 鍵の作成（対称鍵の例）
vault write -f transit/keys/payroll

# 暗号化（Base64 入出力が基本）
PLAINTEXT=$(echo -n "card=4111111111111111" | base64)
vault write transit/encrypt/payroll plaintext="$PLAINTEXT"
# -> ciphertext: vault:v1:...

# 復号
CIPHERTEXT="vault:v1:..."
vault write transit/decrypt/payroll ciphertext="$CIPHERTEXT"
# -> plaintext: Base64（平文化はクライアント側で）

# 署名/検証（非対称鍵や HMAC 用途）
vault write transit/sign/payroll input="$PLAINTEXT"
# -> signature: vault:sha2-256:...
vault write transit/verify/payroll input="$PLAINTEXT" signature="vault:sha2-256:..."

アクセス制御とライフサイクル: ポリシー、TTL、監査

Vault はポリシーでパスごとの能力を制御し、トークンと Lease に TTL を持たせてライフサイクルを管理します。トークンの期限と、動的シークレットの Lease 期限は独立しており、どちらかが切れると実質的にアクセスは失われます。

運用では、Renew（延長）と Revoke（失効）の使い分け、上限 TTL、ロールやポリシーの見直しを定期的に行います。監査ログ（誰が何を読んだ/発行した）を前提に、インシデント時は速やかに lease revoke とトークン無効化を実施します。

• ポリシーは最小権限（必要なパスに必要な能力のみ）
• トークン TTL と Lease TTL を混同しない
• Renew は上限 TTL の範囲内、Revoke は即時失効
• 監査に基づく定期棚卸し（不要なロール/パスを削除）

読み取り専用ポリシーとトークンの TTL/更新

# ポリシー定義（kv/app/config の読み取りのみ）
cat > ro-app.hcl <<'POLICY'
path "kv/data/app/config" {
  capabilities = ["read"]
}
POLICY
vault policy write ro-app ro-app.hcl

# ポリシー付与トークンを作成（1時間 TTL, 更新可）
vault token create -policy=ro-app -ttl=1h -renewable=true

# トークンの更新（追加1時間）
vault token renew <token>

# トークンの失効
vault token revoke <token>

試験対策の要点と落とし穴（Associate）

シナリオから分類を即断する訓練が有効です。保存が必要なら kv、短命の資格情報なら database/aws、データは保存せず暗号処理だけなら transit。さらに Lease/TTL、Renew/Revoke、ロール/ポリシーの関係を言語化して説明できると得点に直結します。

バージョン管理（kv）と Lease（動的）の概念は混同しやすいポイントです。Transit は“保存しない”が本質で、暗号文の保管先はアプリ側という前提を忘れないこと。

• 保存 vs 発行 vs 暗号処理の三択で出題されやすい
• Lease 情報（lease_id, lease_duration, renewable）を見て動的と判断
• Revoke は即時無効化、Renew は上限内延長
• transit は鍵を管理するがデータは保管しない
• kv はポリシーで読み取り専用にしやすく、環境別パス分離が定石

分類の当てはめ素振り（コマンドで確認できる観点）

# どのエンジンが有効か（分類の前提）
vault secrets list -detailed

# 動的なら lease 情報が返る read パスがある（例: database/creds/...）
vault read -format=json database/creds/app | jq '.lease_id, .lease_duration, .renewable'

# transit は encrypt/decrypt パスが中心で、kv のような data 保持はしない
vault list transit/keys

問題で確認

よくある質問