Transit Auto Unseal入門: Vault to VaultでのUnseal設計と運用

クラウドKMSが使えない環境や、Vault同士で暗号境界を完結させたいときに有効なのがTransit Auto Unsealです。Unsealer側のVaultがTransit secrets engineで暗号化/復号を担い、ターゲット側Vaultは起動時に自動でUnsealします。

本記事では、仕組み、前提条件、具体的なセットアップ、可用性・セキュリティの運用ポイント、トラブルシューティングまでを一気通貫で整理します。Ops視点の試験対策要点も併記します。

Transit Auto Unsealの仕組みとVault to Vaultパターン

Transit Auto Unsealは、ターゲット側Vaultのマスターキー（復号に必要なKey）を、別のVaultクラスタのTransit secrets engineで保護する方式です。初期化時にマスターキーをTransitで暗号化して保存し、起動時はTransitの復号APIを呼んで自動Unsealします。手動でShamir鍵を集める運用は不要になります。

ここで勘違いしがちなのは、Vault間のレプリケーションではないことです。Unsealer側Vaultは単に暗号操作を提供するだけで、ターゲット側のストレージやシークレットは共有しません。Transitクラスタの可用性がターゲットの再起動可否に直結するため、LB配下のHA構成や適切な監視が重要です。

Transitは暗号API提供役。データはターゲットVault側のストレージに保存される
ターゲットVaultの起動・再起動でTransitの復号APIが必要（既存稼働中のノードは影響を受けない）
権限は最小化。特定キーのencrypt/decrypt/rewrapのみに絞る
mTLSやピン留めCAでTransit接続を保護。監査ログで復号呼び出しを追跡

方式	外部依存	運用工数	主なリスク
Shamir手動Unseal	なし	高（所定人数での投入が必要）	鍵の配布・保管・ヒューマンエラー
Cloud KMS Auto Unseal	各クラウドKMS	低〜中	クラウド権限・地域/アカウント依存
Transit Auto Unseal（Vault to Vault）	別Vaultクラスタ	低（初期設定後は自動）	Transit停止時にターゲットの再起動不可
HSM Auto Unseal	HSMデバイス	中〜高	HSM障害・接続不良時の復旧手順の複雑さ

Vault to Vault（Transit Auto Unseal）の高レベル構成

ターゲット側Vaultのseal設定（例: vault.hcl の抜粋）

seal "transit" {
  address        = "https://vault-transit.example.com:8200"
  token          = "s.XXXXXXXXXXXXXXXX"  # 本番は権限限定トークン。極小権限・厳格なファイル権限で供給
  mount_path     = "transit/"            # Transitエンジンのマウントパス
  key_name       = "vault-unseal"       # Unseal専用キー名
  tls_ca_cert    = "/etc/vault/ca-transit.pem"
  tls_server_name= "vault-transit.example.com"
  # namespace   = "admin"               # EnterpriseのNamespace利用時のみ指定
}

# 参考: ストレージ例（Raft）
storage "raft" {
  path = "/var/lib/vault/data"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 0
  tls_cert_file = "/etc/vault/tls/vault.crt"
  tls_key_file  = "/etc/vault/tls/vault.key"
}

前提条件と設計判断（ネットワーク/セキュリティ）

Transit Auto Unsealでは、ターゲットVaultからUnsealer側VaultのHTTPSエンドポイントへ到達できること、証明書検証が通ること、最小権限のトークンが用意できることが必須です。LB配下のHA構成を推奨し、停止やロールオーバーに耐えるよう設計します。

セキュリティ境界上、Transitトークンはリークの影響が大きいため、保存時はファイル権限600やOSの秘密情報管理機構を活用し、可能であればホスト側のKMS/TPMでのディスク保護も組み合わせます。Transitキーは削除不可・エクスポート不可とし、監査ログを有効化してアクセスを追跡します。

ネットワーク: ターゲットからTransitの8200/tcp（HTTPS）のみ開放
TLS: mTLSまたは厳格なCAピン留め＋SNI一致（tls_server_name）
ポリシー: transit/encrypt・decrypt（必要に応じてrewrap）のupdate権限のみ
トークン: periodicトークンで自動更新。最小TTLと自動更新の監視
監査: Unsealer側でauditデバイスを有効化し、API呼び出しを追跡

Firewall/セキュリティの最小開放例（概念）

# 例: ターゲット側からUnsealer(LB)へのアウトバウンドのみ
# egress allow: tcp dst=vault-transit.example.com:8200
# ingress deny: （ターゲットへは既存の運用ポリシー通り）
# mTLSを使う場合、ターゲット側にクライアント証明書を配布し、Unsealer側で検証を必須化

Unsealer側Vaultの準備（Transitエンジン、キー、ポリシー、トークン）

Unsealerとして機能するVaultクラスタでTransit secrets engineを有効化し、Unseal専用のキーを作成します。次に、encrypt/decrypt（必要ならrewrap）だけを許可する最小権限ポリシーを作成し、そのポリシーに基づくperiodicトークンを払い出します。

実環境ではLB配下のエンドポイントをaddressに使い、証明書とホスト名の検証が通ることを事前に確認します。キーの削除やエクスポートは無効化し、キー回転は計画的に実施します（後述）。

キー作成時はexportable=false、deletion_allowed=falseを推奨
ポリシーは対象キーに限定し、ワイルドカードを避ける
periodicトークンで期限切れ時も自動更新可能に（監視必須）
Unsealer側の監査ログで復号リクエストを追跡

Transitエンジン有効化〜ポリシー・トークン発行（例）

# Transitエンジンの有効化
vault secrets enable transit

# Unseal専用キーの作成（削除不可・エクスポート不可）
vault write -f transit/keys/vault-unseal deletion_allowed=false exportable=false

# 最小権限ポリシーの作成
vault policy write transit-unseal - <<'EOF'
path "transit/decrypt/vault-unseal" { capabilities = ["update"] }
path "transit/encrypt/vault-unseal" { capabilities = ["update"] }
path "transit/rewrap/vault-unseal"  { capabilities = ["update"] }
EOF

# periodicトークンの発行（例: 24h）。適切な親権限で実行
vault token create -policy=transit-unseal -period=24h -orphan
# 出力されたtokenをターゲットVaultに安全に配布（権限・監査・保管に注意）

ターゲット側Vaultのブートストラップ（初期化と検証）

ターゲット側Vaultのvault.hclにseal "transit"スタンザを設定し、サービスを起動します。初回のvault operator initでマスターキーがTransitで暗号化され、以後の起動時は自動Unsealされます。Raft（Integrated Storage）利用時は、出力がUnseal KeysではなくRecovery Keyになる点に注意してください。

起動後はvault statusでsealed=falseになっていること、監査ログにTransitへのdecrypt呼び出しが記録されていること、トークンの自動更新が行われていることを確認します。

vault operator initは最小分割のrecovery-shares/threholdで試験環境を素早く構築
本番ではvaultサーバプロセスの実行ユーザだけがsealトークンを読めるよう権限を設定
初期化直後にrootトークンを破棄または厳格に保管（必要最小限の期間で）

初期化と状態確認（Raft例）

# Vaultサービス起動後、初期化（Raftの場合はRecovery Keyが出力）
vault operator init -recovery-shares=1 -recovery-threshold=1

# 自動Unsealの確認
vault status
# 期待: Sealed: false, HA: active/standby など

# Transit側の監査で呼び出し確認（例: file監査）
# /var/log/vault_audit.log に transit/decrypt のエントリが残っているか確認

運用設計の要点（可用性・更新・監査）

可用性: Transitクラスタが停止するとターゲットは再起動時にUnsealできません。LB配下のHA構成と健全性チェック、ネットワーク疎通監視、証明書期限監視をセットにしてください。既存で稼働中のノードは影響を受けませんが、ローリング再起動時に詰まります。

更新: Transitキーのローテーションは互換性を保ったまま可能です。復号は暗号文に埋め込まれたバージョンに基づき行われるため、即時の作業は不要です。計画停止時にターゲットを一度再起動して最新キーで再暗号化する運用をとるか、次回の自然再起動まで待つ選択が取れます。

監査: Unsealer側でauditデバイスを有効化し、transit/encrypt・decryptへのアクセスを継続的に確認します。トークンの自動更新失敗（期限切れ）や権限逸脱を早期検知するため、メトリクス・ログのダッシュボード化が有効です。

TransitはLB配下のHA。ヘルスチェックは/v1/sys/healthを活用
トークンはperiodic＋自動更新の可観測性（更新失敗でアラート）
キー回転は事前周知し、変更凍結期間を越える前にテスト
監査ログの保存先はWORM相当を推奨

キー回転とヘルスチェックの例

# Transitキーのローテーション（Unsealer側）
vault write -f transit/keys/vault-unseal/rotate

# Transitクラスタのヘルス（LB経由）
curl -sS https://vault-transit.example.com:8200/v1/sys/health | jq .

# トークン更新の確認（例: ログ/メトリクス）
# renewal 成功/失敗件数を監視基盤に送出する設定を整備

セキュリティの落とし穴とOps試験対策ポイント

Transitトークンの権限過多、mount_pathのミス、証明書検証の無効化は典型的な失点ポイントです。試験では、Transit停止がターゲットの再起動可否に与える影響、ポリシーの最小化、監査の有効化が問われやすいです。

EnterpriseのNamespacesを利用する場合、seal設定のnamespace指定を忘れると権限エラー（403/404）になります。LB配下でSNIが食い違うとTLSハンドシェイクで失敗します。これらはログに明確な痕跡が残るため、メッセージを手掛かりに切り分けましょう。

mount_pathとkey_nameの誤りで404/permission deniedが発生しやすい
tls_server_name不一致やCA未設定でTLS失敗
transit/decryptのみ許可すると初期化時のencryptで失敗する点に注意
トークンに最大TTLがあると長期運用で失効。periodicを使う

権限の検証とエラーログ例

# トークンの権限確認（期待: update のみ）
vault token capabilities $(vault token lookup -format=json | jq -r .data.id) transit/decrypt/vault-unseal

# 典型的なログ例（抜粋・擬似）
# permission denied: path=transit/encrypt/vault-unseal (policy missing)
# TLS handshake error: remote error: tls: bad certificate

トラブルシューティングと検証チェックリスト

ターゲットがUnsealできない場合、まずTransit到達性（DNS/ポート/証明書）を確認し、次にポリシーのcapabilities、最後にトークンの有効期限を確認します。ログには復号API呼び出しの成否が残ります。

時間ずれ（NTP未設定）、プロキシ越しの接続、Namespace指定漏れなども原因になります。sys/healthでUnsealer側のステータスを見て、クラスタがsealedでないことも要確認です。

通信: curlで/v1/sys/health、SNI一致、CA検証
認可: transit/encrypt・decrypt・rewrapそれぞれのcapabilitiesを点検
期限: token lookupでttl/period、自動更新ログの有無
Namespace: Enterprise利用時はseal設定のnamespace一致
LB: 宛先がリーダー選出に追従するようヘルスチェックを設定

確認コマンド集

# Unsealer側のヘルス
curl -sS https://vault-transit.example.com:8200/v1/sys/health | jq .

# ターゲット側の状態
vault status

# トークン情報
vault token lookup

# Transitパスの存在確認（権限があるクレデンシャルで）
vault read transit/keys/vault-unseal  # 読み取り権限がない場合は政策的にdenyでもOK（最小権限優先）

問題で確認

Ops

問題 1

Transit Auto Unseal（Vault to Vault）構成で、ターゲット側Vaultのローリング再起動を計画しています。可用性とセキュリティの観点から、最も適切な事前準備はどれか。

Unsealer側Transitポリシーにtransit/encrypt・decrypt・rewrapのupdateのみを許可し、LB配下のHAと証明書検証を確認する
ターゲット側のsealトークンをrootトークンに置き換え、失敗時の再試行回数を増やす
Unsealer側のTransitキーをexportableに設定し、復旧時に平文でバックアップを取得する
ターゲット側VaultのShamir鍵を全員に配布し、手動Unsealの併用でリスクを下げる

正解: A

可用性はUnsealer側のHAと正しいTLS検証に依存し、セキュリティは最小権限（encrypt/decrypt/rewrapのupdateのみ）で担保します。rootトークン利用やキーのexportable化、Shamirとの無秩序な併用はリスク増大につながります。

よくある質問

Transitクラスタが停止したとき、ターゲット側の既存ノードは止まりますか？

既にUnseal済みで稼働中のノードはそのまま動作します。ただし再起動や新規ノード追加時にはTransitの復号が必要なため、停止中はUnsealできません。計画停止時はローリング再起動を避け、Transit側の可用性を確保してください。

Transitキーをローテーションすると、即座に何か対応が必要ですか？

通常は不要です。暗号文にバージョン情報が含まれるため、復号は継続して成功します。計画的にターゲットを再起動し、最新キーで再暗号化させる運用をとることは可能です。

EnterpriseのNamespacesを使っています。seal設定で何に注意すべきですか？

Unsealer側のTransitエンジンが属するNamespaceをseal設定のnamespaceに正しく指定してください。指定漏れや不一致は403/404のエラー要因になります。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる

この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。