HashiCorp Vault Recovery Keys 実務運用ガイド: Auto Unseal 時の運用鍵

Auto Unseal を導入すると、日常運用で人手による Unseal は不要になりますが、その代わりに Recovery Keys が組織の最後の砦になります。

本稿では、Recovery Keys の正しい位置付け、必要となる具体的な場面、保管・ローテーション手順、ブレイクグラスの実行例までを、資格対策と実務の両面から解説します。

Recovery Keys とは何かと Auto Unseal の関係

Auto Unseal は外部の KMS/HSM（例: AWS KMS, GCP KMS, Azure Key Vault, HSM）を使って Vault のバリア鍵を自動で復号し、起動時の Unseal 作業を不要にします。これにより Shamir の Unseal Keys は生成されません。その代替として、例外時にのみ使う運用鍵が Recovery Keys です。

Recovery Keys は Shamir の分散秘密分割で生成され、しきい値に達する数のシェアを集めることで、特定のリカバリ操作（新規 root トークンの生成や Recovery Keys の再生成など）を実行できます。通常のシークレット操作やポリシー管理には不要で、Auto Unseal 稼働中は保管・監査・定期的なテストが主な運用タスクになります。

• 日常運用では使わない。ブレイクグラス専用
• Shamir 分割のシェアとしきい値を init 時に決定
• Auto Unseal でも初期化は必要で、そこで Recovery Keys が払い出される

Auto Unseal と Recovery Keys の位置付け

どの操作で Recovery Keys が必要になるか（運用視点）

Auto Unseal 環境で Recovery Keys を使うのは、通常の認証・認可では解決できない例外対応だけです。最も代表的なのは、既存の root トークンを全て失い、かつポリシー上の昇格もできない場合に、新規 root トークンを発行するケースです。

また、Recovery Keys 自体の再生成（しきい値やシェア数の変更を含む）にも Recovery Keys を用います。バリア鍵のローテーション（operator rotate）は root トークンで実施し、Recovery Keys は不要です。

• 新規 root トークンの発行: vault operator generate-root -recovery
• Recovery Keys の再生成: vault operator rekey -recovery
• バリア鍵のローテーション: vault operator rotate（root トークン使用、Recovery Keys 不要）
• Enterprise の一部運用（DR プロモート等）で Recovery Keys が関与する場合があるが、環境とバージョン仕様に依存するため設計時に必ず公式ドキュメントで確認する

生成と保管のベストプラクティス

init 時に Recovery Keys のシェア数としきい値を定義します。一般的には 5 シェア中 3 をしきい値とする N-of-M 構成が多いですが、組織の人員配置・地理冗長性・監査要件を踏まえて決定します。

鍵の配布は、PGP で各担当者の公開鍵にラップして出力し、担当者ごとに秘密裏に配布・保管するのが実務的です。保管先はオフライン保管（耐火金庫）、シークレットマネージャの堅牢なスロット、あるいは物理封印付き保管庫など、二重管理を前提に選びます。

• vault operator init 時に recovery-shares と recovery-threshold を明示的に指定する
• PGP ラップ（-pgp-keys）を使い、担当者ごとに異なる公開鍵で暗号化して配布
• 配布後に受領確認と復号テスト（オフライン）を行い、監査ログを残す
• シェアの所在台帳、担当交代時の引継ぎ、定期在庫点検を運用プロセス化する
• 鍵素材はリポジトリやチケットに貼らない。必ず暗号化・分離保管

ランブック: Auto Unseal 環境のブレイクグラス（新規 root の生成）

前提: Vault は起動しているが、root トークンが全て失われ、昇格もできない。Recovery Keys のしきい値分のシェアが回収可能であること。操作は監査対象として手順開始前にチェンジ記録を作成すること。

流れ: generate-root を初期化し、表示された Nonce と One-time password を控え、しきい値分の Recovery Key シェアを順次投入。最後にエンコード済みトークンを OTP で復号して root を得ます。実行後は速やかに目的タスクを完了し、root を取り消すか封じるのが望ましいです。

• 操作前に vault status と監査デバイスの有効化状況を確認
• OTP を安全に控え、復号手順を誤らないようにする
• しきい値未満では生成されないことをチームに周知
• 作成した root は短命で使い捨て（目的達成後に撤収）

ブレイクグラス: Recovery Keys で新規 root を発行する

# 0) 環境確認
export VAULT_ADDR=https://vault.example.com:8200
vault status

# 1) 生成プロセスを初期化（-recovery を明示）
# 出力される Nonce と One-time password (OTP) を安全に控える
vault operator generate-root -init -recovery
# 例: 出力
# Nonce:  6f4c...e1
# One-time password:  yxD-2V...-H9
#   (Encoded token はこの時点では表示されない)

# 2) Recovery Key の各シェアを順次投入（しきい値回数繰り返す）
# <SHARE_i> は各オペレーターが保有する回復用シェア（復号済みの文字列）
vault operator generate-root -recovery -nonce 6f4c...e1 <SHARE_1>
vault operator generate-root -recovery -nonce 6f4c...e1 <SHARE_2>
# ... しきい値に達する最後の 1 回で Encoded token が表示される
# 例: Encoded token: VVNF... (省略)

# 3) Encoded token を OTP で復号し、root トークンを得る
vault operator generate-root -decode=VVNF... -otp=yxD-2V...-H9
# 例: Root token: s.p7y... (保護された経路で安全に共有)

# 4) 目的の作業を実施後、root の無用な長期保有を避ける
# 例: 緊急対応のための最小限の操作のみ実施

# 参考: Recovery Keys の再生成（しきい値・シェア変更）
# PGP で各担当の公開鍵を指定してラップすることを推奨
vault operator rekey -recovery -init \
  -recovery-shares=5 -recovery-threshold=3 \
  -pgp-keys="keybase:alice,keybase:bob,keybase:carol,keybase:dave,keybase:erin"
# 初期化後、しきい値分のシェアを順次投入
vault operator rekey -recovery <SHARE_1>
# ...（しきい値回数）
# 完了すると新しい Recovery Keys が払い出される（配布・受領記録を更新）

ローテーションと監査の要点

Recovery Keys のローテーションは rekey -recovery で実施します。サービス継続に影響しないため、計画停止は不要ですが、シェア回収のための人的調整が発生します。完了後は旧シェアを速やかに廃棄し、台帳と監査記録を更新します。

バリア鍵のローテーション（vault operator rotate）は root トークンで実行し、Recovery Keys は使用しません。Auto Unseal のラップ鍵（KMS/HSM 側）のライフサイクルはクラウド/HSM のポリシーに従い、Vault 側と整合させます。監査については operator エンドポイントの呼び出しが確実に記録されるよう、少なくとも 2 系統の監査デバイスを推奨します。

• rekey -recovery は無停止で実施可能だが、人的しきい値を満たす日程設計が肝心
• rotate（バリア鍵）は root トークンで実施し、事前にバックアップと監視を強化
• 監査デバイスは複数系統（例: ファイル + Syslog）、改ざん検出の仕組みを併用
• KMS/HSM のキー更新・失効計画を Vault の運用カレンダーに反映する

Ops 資格対策の要点と落とし穴

試験では、Auto Unseal と Recovery Keys の役割分担、どの操作にどの鍵が要るか、コマンドのスイッチ指定を正しく選べるかが頻出です。特に generate-root と rekey に -recovery を付けるかどうか、rotate は root トークンで実行するという区別を確実に押さえてください。

設問は実務の落とし穴を突いてくることが多く、例えば「Auto Unseal だから Recovery Keys は不要」といった誤りを誘ってきます。Recovery Keys は日常では使わないが、無いと詰む最後の砦、という位置付けを忘れないこと。

• Auto Unseal 環境では Unseal Keys は生成されず、代わりに Recovery Keys が生成される
• 新規 root 発行: vault operator generate-root -recovery
• Recovery Keys の再生成: vault operator rekey -recovery
• バリア鍵ローテーション: vault operator rotate（root トークン使用）
• PGP ラップと N-of-M 設計は実務・試験ともに重要トピック

問題で確認

よくある質問