Vault Auto Unseal 実践ガイド: クラウド KMS 連携で運用を安定化する

Auto Unseal は、Vault 起動時に外部 KMS でマスターキーを復号し、手動の Shamir アンシールを不要にする仕組みです。クラウド KMS と組み合わせることで、再起動やフェイルオーバーのオペレーションを簡潔かつ安全にできます。

本稿では AWS KMS / Azure Key Vault / GCP Cloud KMS を対象に、構成手順、必要権限、運用上の落とし穴と対策をまとめます。試験（Ops）でも頻出の論点を明示し、実務にもそのまま使える形で解説します。

Auto Unseal とクラウド KMS 連携の要点

Auto Unseal は Vault のマスターキーを外部 KMS でラップし、起動時に KMS を用いて自動復号する機能です。これにより運用者が複数のアンシールキーを集める手間や、リモート拠点間での手動アンシールの待ち時間を解消できます。

Auto Unseal を有効化すると、初期化時に出力されるのは Shamir の Unseal Keys ではなく Recovery Keys になります。Recovery Keys は障害復旧や一部の操作にのみ使用され、起動時のアンシールには使いません。運用上、KMS は主に起動時とマスターキーのリキー・ローテーション時に呼び出され、通常のシークレット操作時には関与しません。

可用性設計では、KMS への到達性が起動時の成否を左右します。起動中のノードは KMS が一時的に不達でも継続動作しますが、再起動やスケールアウト時は KMS 到達性が前提になります。KMS がリージョン固有である場合は、Vault クラスタの配置と KMS の配置・冗長化方針を一致させることが肝要です。

• 初期化後に得られるのは Recovery Keys（手動アンシールには非使用）
• KMS は起動時とキーのリキー・ローテーション時に主要動作
• KMS 到達不能時は起動できない（起動中インスタンスは継続稼働）
• 全ノードで同一の seal 設定（同一プロバイダ・鍵）を使用する

Auto Unseal(Raft＋クラウド KMS)概念図

seal スタンザの基本（例: AWS KMS）

seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  # 認証情報はインスタンスロール/タスクロール推奨（静的キーは避ける）
}

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = "0"
}

default_lease_ttl = "768h"
max_lease_ttl     = "768h"

AWS KMS での構成手順と最小権限

AWS KMS を使う場合、Vault 実行環境（EC2、ECS、EKS など）に付与する IAM ロールへ KMS 鍵の使用権限を与えます。鍵は対称暗号のカスタマーマスターキー（CMK）を用意し、リージョンは Vault ノードと同一または同等の冗長性で配置します。

必要権限は最低限 kms:Decrypt と kms:Encrypt、鍵の状態確認に kms:DescribeKey を付与します。鍵ポリシー側でも IAM ロールを Principal として許可しておくとトラブルを避けられます。Auto Unseal 自体のトラフィックは起動時中心のため、KMS コストやレート制限の影響は限定的ですが、頻繁なローリング再起動の設計は見直すのが無難です。

KMS をリージョン跨ぎで使用する場合はマルチリージョンキーの活用を検討します。クラスタが複数リージョンに跨るなら、同一キーの複製（マルチリージョンキー）か、リージョンごとの鍵と構成管理の整合性を確保します。

• IAM ロールに Decrypt/Encrypt/DescribeKey を付与
• 鍵ポリシーは IAM ロール Principal を許可
• 起動時依存のため再起動計画と KMS 到達性の監視が重要
• マルチリージョンキーで DR シナリオを簡素化

vault.hcl（AWS KMS）最小例

seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
# 認証は IAM ロール（EC2/EKS のメタデータ経由）を推奨
# 必要に応じて endpoint を明示（VPC エンドポイント等）
# endpoint = "https://kms.ap-northeast-1.vpce.amazonaws.com"

Azure Key Vault での構成と権限設計

Azure では Key Vault の鍵に対して wrapKey と unwrapKey（および get）権限が必要です。運用環境では Managed Identity を使うとシークレット管理を単純化できます。ネットワーク制御（Private Endpoint、Firewall）を有効化する場合は Vault からの疎通を確保します。

Key Vault 側でソフトデリートとパージ保護を有効化しておくと、鍵の誤削除に対する耐性が増します。鍵のバージョン切替時は Vault 側の再ラップ（rekey）や設定更新計画を用意します。

• 必要権限: get, wrapKey, unwrapKey
• Managed Identity での認証を推奨（クレデンシャルレス）
• Private Endpoint 利用時は DNS/ルーティングも含めて疎通確認

vault.hcl（Azure Key Vault）最小例

seal "azurekeyvault" {
  tenant_id   = "00000000-0000-0000-0000-000000000000"
  vault_name  = "my-key-vault"
  key_name    = "vault-unseal"
  # Managed Identity を使う場合:
  # use_msi = true
  # システム割当またはユーザー割当 MI に鍵権限を付与
  # クライアントシークレットで行う場合（非推奨）:
  # client_id     = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  # client_secret = "..."
}

GCP Cloud KMS での構成とロール

GCP では Vault の実行サービスアカウントに対して対象の CryptoKey に roles/cloudkms.cryptoKeyEncrypterDecrypter を付与します。プロジェクト、ロケーション、キーリング、暗号鍵の指定が必要です。

認証はサービスアカウントのメタデータ（GCE/GKE）を優先し、JSON キーファイルの配布は最小化します。KMS のロケーションと Vault ノードの配置は同一リージョンまたは近接にし、起動時レイテンシと可用性を確保します。

• 必要ロール: cloudkms.cryptoKeyEncrypterDecrypter
• GCE/GKE のワークロードアイデンティティ活用で鍵配布を回避
• KMS ロケーションと Vault 配置の整合性を取る

vault.hcl（GCP Cloud KMS）最小例

seal "gcpckms" {
  project    = "my-gcp-project"
  region     = "asia-northeast1"  # KMS ロケーション
  key_ring   = "vault-ring"
  crypto_key = "vault-unseal"
  # 認証はデフォルト認証情報を推奨（GCE/GKE の SA）
  # credentials = "/path/to/service-account.json"  # 可能なら未使用
}

運用の勘所: 可用性・監視・障害対応

起動中の Vault は KMS 不達でも継続稼働します。問題は再起動タイミングです。再起動やスケールアウト時に KMS へ到達できなければアンシールに失敗します。計画メンテナンスやローリングアップグレード時は KMS 到達性とレート制限を監視し、段階的な再起動を行います。

健全性確認には /v1/sys/health のステータスを活用します。sealed 状態、初期化未了、リカバリーモードなどステータスコードが異なるため、オーケストレーションの readiness/liveness に合わせて判定条件を調整します。

ログには seal タイプやアンシール成否が出力されます。KMS 到達性や認可エラーはインシデントの初動切り分けに有用です。また、KMS キーの無効化・削除・権限変更は重大インシデントの原因になり得るため、変更管理と監査（CloudTrail/Activity Log/Cloud Audit Logs）の監視を組み込みます。

• KMS 到達性が落ちたら再起動を避け、まず回線・権限を復旧
• ローリング再起動は小さなバッチで。KMS レート制限に配慮
• health API のコードに基づく監視ルールを用意
• KMS 鍵の状態変更は変更管理プロセスに必ず載せる

ヘルスチェック例

curl -s -o /dev/null -w "%{http_code}\n" \
  http://127.0.0.1:8200/v1/sys/health
# 200: unsealed/active, 429: standby, 503: sealed など
# sealed 時は systemd/オーケストレータで自動再起動を抑止する設計が有効

試験対策とベストプラクティス

Ops 観点で問われやすいのは、Auto Unseal の作動タイミング（起動時・リキー時）、Recovery Keys の役割、KMS 到達性がクラスタ運用へ与える影響、必要権限の最小化です。設問では「KMS 不達時にどうするか」「鍵ローテーション時の影響」「複数ノード・複数リージョンでの設計」が典型です。

実務では、認証情報はロールやマネージド ID を使い、静的シークレットを vault.hcl に埋めないこと、KMS の監査ログをセキュリティ運用に組み込むこと、KMS のネットワーク到達性（PE, VPC エンドポイント、FW など）を IaC で明示的に管理することがポイントです。

• 全ノードで同一の seal 設定を使用（混在は不可）
• 鍵の自動ローテーション（同一キーID配下）ならダウンなし。別キーへ切替は計画的に再ラップ
• 障害時は Recovery Keys での復旧操作はできるが、アンシール代替にはならない
• KMS に依存するのは起動時中心。平常時トラフィックは最小

設定変更のデプロイ例（ローリング）

# 例: 3 ノードを 1 台ずつローリング
for h in vault-1 vault-2 vault-3; do
  echo "Restarting $h"
  ssh $h 'sudo systemctl restart vault && sleep 10 && curl -sf http://127.0.0.1:8200/v1/sys/health >/dev/null'
  # KMS 到達性/ステータスを確認して次へ
done

問題で確認

よくある質問