Vault Transit エンジン徹底ガイド：Encryption as a Service を安全に運用する

Vault Transit エンジンはアプリの秘密情報を保存しません。鍵を安全に保管し、API 経由で暗号操作だけを提供する“Encryption as a Service”を実現します。

本記事では、機能の要点、運用設計、試験に出やすい論点、最小コマンドをまとめ、現場で迷いやすい設定（derived/convergent、min_decryption_version、rewrap など）を具体的に押さえます。

Transit エンジンの基本と Encryption as a Service

Transit はアプリケーションのデータを保存しません。保存するのは鍵とメタデータのみで、暗号化・復号・署名・HMAC・データキー発行を API/CLI で提供します。これによりアプリは鍵管理や実装差異を気にせず、安定した暗号操作を委譲できます。

対称鍵（aes256-gcm96 等）による暗号化/復号、非対称鍵（RSA/ECDSA/Ed25519）による署名/検証、HMAC、データキー（KMS 風の一時鍵）などが代表機能です。キーはバージョン管理され、ローテーションや復号許可の下限設定（min_decryption_version）などの制御も可能です。

• データ非保存：アプリの平文/暗号文は Vault に残らない（監査ログは除く）
• 暗号操作の統一 API：encrypt/decrypt/sign/verify/hmac/datakey/rewrap
• キーのバージョン管理とローテーション：復号可能バージョンの下限も制御可
• 高可用 Vault 構成に乗る：HA/パフォーマンススタンバイでスループットと可用性を確保

EaaS リクエストフロー（アプリ⇔Vault Transit）

Transit の有効化と最小セットアップ（CLI）

# Transit エンジンを有効化（デフォルトパス transit/）
vault secrets enable transit

# 暗号鍵 'payments' を作成（対称鍵 aes256-gcm96）
vault write transit/keys/payments type=aes256-gcm96

# 平文を Base64 にして暗号化
echo -n 'card:4111-1111-1111-1111' | base64 | \
  xargs -I{} vault write transit/encrypt/payments plaintext={

# 復号（ciphertext は encrypt の戻り値）
vault write transit/decrypt/payments ciphertext=vault:v1:...

# 最小ポリシー（encrypt だけ許可）
cat <<'EOF' > transit-app.hcl
path "transit/encrypt/payments" {
  capabilities = ["update"]
}
EOF
vault policy write transit-app transit-app.hcl

キーライフサイクルと主要設定（versioning/derived/convergent）

Transit の鍵はバージョン管理され、rotate で新バージョンが発行されます。既存暗号文は従来バージョンで復号可能ですが、min_decryption_version を引き上げると古いバージョンでの復号を拒否できます。これにより計画的な暗号更新と段階的カットオーバーが可能になります。

対称鍵（aes256-gcm96 既定、chacha20-poly1305 等）は暗号化/復号に、非対称鍵（rsa-*, ecdsa-*, ed25519）は署名/検証に主に用います。exportable や allow_plaintext_backup を有効化すると鍵素材の取得が可能になりますが、リスクが大きいため運用では慎重に扱います。

derived=true は呼び出し時の context（Base64）から派生鍵を生成する仕組みで、マルチテナントやデータクラス別の分離に有効です。convergent_encryption=true を併用すると（前提として derived=true 必須）、呼び出し側が与える 96-bit の nonce により決定性暗号（同一平文→同一暗号文）を実現できます。決定性は機微情報の漏えいに繋がる可能性があるため、要件が明確な場合のみ使用します。

• rotate: vault write -f transit/keys/<name>/rotate
• 復号制御: min_decryption_version / min_encryption_version
• 削除: deletion_allowed=true のキーのみ削除可能（安全策）
• エクスポート: exportable / allow_plaintext_backup の有効化は最小限に
• derived/context: Base64 エンコード必須。テナント境界に活用
• convergent: derived とセット。ユーザー提供 nonce(12バイト)が必要

キー操作の代表コマンド

# キー作成（派生鍵 + 決定性暗号）
vault write transit/keys/customer-data \
  type=aes256-gcm96 derived=true convergent_encryption=true

# ローテーションと設定変更
vault write -f transit/keys/customer-data/rotate
vault write transit/keys/customer-data/config \
  min_decryption_version=2 deletion_allowed=true

# キー情報確認
vault read transit/keys/customer-data

主要ユースケースと他手段との比較

Vault Transit はアプリ層での暗号操作に適しています。PII の保護、決済トークンの暗号化、Webhook シークレットの署名/HMAC、機密ログの暗号化などが典型です。一方、トークナイゼーションや書式保持が必要なら Transform エンジンが適合する場合があります。

クラウド KMS や DB の TDE と競合するのではなく、階層化して併用する設計が現実的です。TDE は保存時暗号化、Transit はアプリ視点のフィールド暗号化、KMS は鍵素材のルート・オブ・トラストという分担が分かりやすい整理です。

• フィールド暗号化：アプリで特定列のみ暗号化（復号は必要時のみ）
• 署名/検証：Webhook、リリースアーティファクト、監査イベントの整合性
• HMAC：リクエスト改ざん検出、MAC ベースのトークン
• データキー：一時鍵で大量データをアプリ側ライブラリで暗号化

署名・検証 / HMAC の API 呼び出し例（curl）

# 署名（入力は Base64）。ed25519 や ecdsa-p256 等の鍵で利用
curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST "$VAULT_ADDR/v1/transit/sign/release-key" \
  -d '{"input":"'$(echo -n artifact-sha256 | base64)'","hash_algorithm":"sha2-256"}'

# 検証
curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST "$VAULT_ADDR/v1/transit/verify/release-key" \
  -d '{"input":"'$(echo -n artifact-sha256 | base64)'","signature":"vault:v1:..."}'

# HMAC
curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST "$VAULT_ADDR/v1/transit/hmac/webhook-key" \
  -d '{"input":"'$(echo -n payload | base64)'","algorithm":"sha2-256"}'

運用ベストプラクティス（Associate/Ops 視点）

パス設計は最初に固めます。鍵名はテナントやシステム境界を意識し、派生鍵（derived）で論理分離を補強します。ポリシーは encrypt/update の最小権限を基本に、decrypt は厳格に限定しましょう。

可用性は Vault クラスター構成（HA、パフォーマンススタンバイ）に依存します。Transit はステートレスに近いので、リーダー切替時のリクエスト転送が有効です。監査ログを必ず有効化し、鍵操作・設定変更の追跡可能性を確保します。

性能はネットワーク往復と暗号処理コストの合算です。バッチ API（batch_input）やデータキーでアプリ側暗号を併用すると、レイテンシを抑えやすくなります。大容量データはデータキーで暗号化し、Vault は鍵管理に専念させるのが定石です。

• 最小権限：encrypt のみ付与トークンと decrypt 可能トークンを分離
• Base64 規約：plaintext/context は Base64。エンコード忘れは典型的エラー
• min_decryption_version：一気に上げず段階的に。復旧計画とセットで
• exportable/allow_plaintext_backup：原則オフ。やむを得ない移行時のみ
• rewrap：平文を晒さず新バージョンへ移行できる安全な経路
• 監査：transit/keys/* の変更操作は変更加重監査対象に

最小権限ポリシー例（HCL）

# アプリは暗号化のみ、SRE は設定閲覧・ローテーション
# アプリ用
path "transit/encrypt/payments" {
  capabilities = ["update"]
}
# 署名/HMAC も最小権限で個別パスに付与
path "transit/hmac/webhook-key" {
  capabilities = ["update"]
}

# SRE/運用用
path "transit/keys/payments" {
  capabilities = ["read", "update"]  # read:状態確認, update:設定変更
}
path "transit/keys/payments/rotate" {
  capabilities = ["update"]
}
# 復号は原則別トークンで限定
auth "*" {
  capabilities = []
}

試験対策メモ：頻出ポイントと落とし穴

Transit は“データを保存しない”がキーワード。暗号操作だけを提供し、鍵は Vault ストレージに保存されます。Transform と混同させる問題や、rewrap の挙動、min_decryption_version の意味が出題されがちです。

Base64 入出力、batch_input、derived/context、convergent と nonce、exportable/allow_plaintext_backup のリスク、データキーの用途（大量データ暗号のオフロード）も押さえておきましょう。

• rewrap：平文を知らずに暗号文を最新キーへ再暗号化
• min_decryption_version：この値より古いバージョンでは復号不可
• datakey：plaintext と ciphertext の両方を返す（アプリ側暗号に使う）
• 署名鍵の用途：Ed25519/ECDSA は署名/検証、RSA は署名や暗号化で用途差がある
• Transform との違い：Transit は暗号、Transform はトークナイゼーション/書式保持

HTTP 動詞とエンドポイントの対応（復習スニペット）

# 作成/設定変更: POST /v1/transit/keys/<name>
# ローテーション: POST /v1/transit/keys/<name>/rotate
# 暗号化:         POST /v1/transit/encrypt/<name>
# 復号:           POST /v1/transit/decrypt/<name>
# 署名/検証:      POST /v1/transit/sign|verify/<name>
# HMAC:           POST /v1/transit/hmac/<name>
# Rewrap:         POST /v1/transit/rewrap/<name>
# データキー:     POST /v1/transit/datakey/plaintext|wrapped/<name>

ハンズオン：暗号化/復号、Rewrap、データキー、バッチ

最小フローは「キー作成 → 暗号化 → 復号」です。運用ではローテーション後の rewrap、データキー併用、バッチ暗号でスループット最適化を行います。

以下は CLI と curl の混在例です。試験演習では“どの操作が平文を扱わないか（rewrap）”や“どのフィールドが Base64 か（plaintext/context/input）”を確認しましょう。

• encrypt/decrypt：平文は Base64、戻りは vault:v<ver>:... 形式の暗号文
• rewrap：古い暗号文を最新バージョンへ再ラップ（平文は扱わない）
• datakey：アプリ側で大量データ暗号化、Vault は鍵管理と監査に集中
• batch_input：同一エンドポイントへの複数要素暗号で往復回数削減

実践コマンド/リクエスト集

# 暗号化（単発）
echo -n 'pii:john.doe' | base64 | \
  xargs -I{} vault write transit/encrypt/pii plaintext={

# 復号
vault write transit/decrypt/pii ciphertext=vault:v2:...

# Rewrap（平文不要で最新バージョンへ）
vault write transit/rewrap/pii ciphertext=vault:v1:...

# データキー（平文キーでアプリ側暗号）
vault write transit/datakey/plaintext/pii bits=256

# バッチ暗号（curl 例）
JSON='{"batch_input":[{"plaintext":"'$(echo -n a | base64)'"},{"plaintext":"'$(echo -n b | base64)'"}]}'
curl -s -H "X-Vault-Token: $VAULT_TOKEN" -H "Content-Type: application/json" \
  -X POST "$VAULT_ADDR/v1/transit/encrypt/pii" -d "$JSON"

# 派生鍵 + 決定性暗号の呼び出し（context と nonce は Base64/バイナリ要件に注意）
CTX=$(echo -n tenant-123 | base64)
NONCE=$(head -c 12 /dev/urandom | base64)  # 96-bit（12 バイト）
curl -s -H "X-Vault-Token: $VAULT_TOKEN" -H "Content-Type: application/json" \
  -X POST "$VAULT_ADDR/v1/transit/encrypt/customer-data" \
  -d '{"plaintext":"'$(echo -n ssn:123-45 | base64)'","context":"'$CTX'","nonce":"'$NONCE'"}'

問題で確認

よくある質問