HashiCorp Vault Ops: Rekey で Unseal Key を更新する実務手順

Vault の Unseal Key は運用メンバーやしきい値（threshold）の見直しに合わせて更新すべき重要情報です。Rekey は稼働中クラスタでも実施できる標準手順ですが、いくつかの実務的な落とし穴があります。

本稿では、Shamir ベースの手動アンシール環境と Auto Unseal 環境の違いを押さえつつ、代表的な CLI 手順、比較表、試験対策ポイントをまとめます。

Rekey の基礎と用語整理

Vault の Rekey は、Unseal Key（Shamir の N-of-M 共有）の構成を更新する操作です。具体的には share 数（M）や閾値（N）の変更、PGP による配布時暗号化の導入・更新などを行います。Rekey は暗号化鍵自体（データ暗号鍵）を回転させる vault operator rotate とは目的が異なります。

Auto Unseal（クラウド KMS などで自動開封）を使う構成では、日常運用で Unseal Key は使いません。その代わりに Recovery Key が用意され、Rekey 対象は Recovery Key になります（コマンドに -recovery フラグを付与）。

Rekey はクラスタ稼働中に実施でき、通常はサービス中断を伴いません。ただし、進行中はノンス（nonce）管理や share 入力の取り扱いが厳密に求められます。

• 目的の典型例: 運用メンバー交代、しきい値の見直し、share の増減、PGP での配布保護導入
• 対象の違い: 手動アンシール＝Unseal Key、Auto Unseal＝Recovery Key（-recovery）
• 稼働影響: 通常はダウンタイム不要（ただし実施窓は確保）
• セキュリティ: 新旧 share を同時に保持しない、転送は安全なチャネルで

Rekey の概念フロー（Shamir 手動アンシールの場合）

┌───────────────────────┐           ┌─────────────────────┐
│  Operators (旧 Unseal Keys 保有) │           │    Vault Leader     │
└───────────────┬──────────┘           └───────────┬─────────┘
                 │ 旧 Unseal Key を N-of-M で入力 + Nonce            │
                 ▼                                              │
          ┌──────────────────┐                                 │
          │ 旧マスターキー復元 │  ←――――――――――――――――――――――――――――――┘
          └─────────┬──────┘
                    │ 新構成(M', N')で分割（Shamir）
                    ▼
          ┌──────────────────┐
          │ 新しい share 群   │  → PGP で暗号化して各オーナーへ返却
          └──────────────────┘

最小限の事前確認（安全なメンテ時間に実施）

vault status
# コマンド仕様の再確認（バージョンによりオプション差異があるため）
vault operator rekey -help

実施前の計画と前提チェック

Rekey は開始後にノンスでトランザクションを識別し、所定数の旧 share 入力が完了すると新 share が発行されます。途中キャンセルや再開にもノンスが必要になるため、取り扱い計画が必須です。

PGP 鍵で新 share を暗号化して配布する運用が推奨されます。公開鍵の収集方法（Keybase 連携か、各ユーザーの公開鍵ファイルか）と件数が、新しい share 数と一致していることを確認します。

• 参加者とロール: 旧 Unseal/Recovery Key を保有するメンバー、実行担当、承認者
• PGP 準備: Keybase ユーザー名、または base64 化した公開鍵を事前収集
• メンテ時間: 入力待ちで長引くケースに備えて余裕を確保
• 監査と証跡: 実行ログ、誰がどの share を受領したか、保管・廃棄手順
• リスク低減: 新旧 share の同時長期保有を避け、配布後ただちに旧 share を回収・破棄

PGP 公開鍵の準備例

# Keybase を使う場合（新しい share 数と同数のユーザーを列挙）
# 例: alice, bob, carol の3名に配布
# 後続の -pgp-keys で keybase:alice のように指定

# ローカル公開鍵を使う場合（ASCII でエクスポートし base64 化）
# 各受領者の公開鍵をエクスポートして base64 ファイルに
# alice の例
gpg --export -a [email protected] | base64 > alice.pub.b64
# 受領者分を縦に並べたファイルを作成
cat alice.pub.b64 bob.pub.b64 carol.pub.b64 > pgp_keys.b64

手順: 手動アンシール（Shamir）環境での Rekey

Shamir 方式の環境では、vault operator rekey を使って Unseal Key を更新します。開始時に -init を付けて新しい構成（-key-shares と -key-threshold）を宣言し、返されたノンスを保持します。その後、旧 Unseal Key を N-of-M だけ順に入力すると、新しい share が返されます。

PGP を併用する場合、-pgp-keys（Keybase 指定）または -pgp-keys-file（base64 公開鍵の列挙ファイル）を使います。Vault は各 share を対応する公開鍵で暗号化して出力します。

• 開始前に旧 share オーナーの参加可否を確認（途中離脱が最大の遅延要因）
• ノンスは共有するが、公開場所に貼らない（限定メンバーの安全チャネルで）
• 出力された新 share はただちに配布・受領確認。旧 share は適切に廃棄
• PGP なし配布は極力避ける（誤配・盗聴リスク）

代表的な CLI シーケンス（Shamir）

# 1) Rekey を開始（例: 新しい構成は 5 shares / threshold 3、Keybase を使用）
vault operator rekey -init \
  -key-shares=5 -key-threshold=3 \
  -pgp-keys="keybase:alice,keybase:bob,keybase:carol,keybase:dave,keybase:erin"
# 出力に Nonce が含まれる。安全な方法で控える
# Nonce: 7f4b9c1a-... （例）

# 2) 旧 Unseal Key を N 回（例: 3 回）入力して進捗を進める
vault operator rekey -nonce=7f4b9c1a-... -key=<旧_unseal_key_1>
vault operator rekey -nonce=7f4b9c1a-... -key=<旧_unseal_key_2>
vault operator rekey -nonce=7f4b9c1a-... -key=<旧_unseal_key_3>
# 閾値に達すると、新しい share（PGP 暗号化済み）が出力される

# 進行状況の確認（バージョンによりサブコマンド有無が異なる場合あり）
vault operator rekey -status -nonce=7f4b9c1a-...

# 中止する場合（ノンス必須）
vault operator rekey -cancel -nonce=7f4b9c1a-...

手順: Auto Unseal 環境での Recovery Key Rekey

Auto Unseal 構成では、日常の開封は KMS（または HSM）に委ねられるため、Rekey の対象は Recovery Key です。操作の考え方は Shamir と同様で、-recovery フラグを付けて実行します。

Recovery Key は緊急時の復旧や特定のオペレーションに用いるため、配布・保管は Unseal Key 同様に厳密さが求められます。クラウド KMS 側の鍵ローテーションは別手順であり、Rekey とは独立です。

• コマンドは -recovery フラグを付与して開始・進行・中止
• しきい値と share 数は運用設計に合わせて見直し
• KMS 側の鍵ローテーションと混同しない（Vault 側の Recovery Key は別物）

代表的な CLI シーケンス（Auto Unseal / Recovery Key）

# 1) Recovery Key の Rekey を開始
vault operator rekey -recovery -init \
  -key-shares=5 -key-threshold=3 \
  -pgp-keys-file=pgp_keys.b64
# Nonce を控える

# 2) 旧 Recovery Key をしきい値分入力
vault operator rekey -recovery -nonce=<Nonce> -key=<旧_recovery_key_1>
vault operator rekey -recovery -nonce=<Nonce> -key=<旧_recovery_key_2>
vault operator rekey -recovery -nonce=<Nonce> -key=<旧_recovery_key_3>

# 必要に応じて進行状況確認や中止
vault operator rekey -recovery -status -nonce=<Nonce>
vault operator rekey -recovery -cancel -nonce=<Nonce>

Rekey と関連操作の比較（選定の目安）

似た名称の運用操作と混同しやすいため、目的・影響・コマンドを並べて確認します。試験でも問われやすい論点です。

特に、Rekey（Unseal/Recovery Key の再分割）と Rotate（データ暗号鍵のローテーション）は別物です。

• Rekey は share の再構成（人数・しきい値・PGP 配布）
• Rotate はデータ暗号鍵の世代を進める（ストレージ再暗号化はバックグラウンドで進行）
• Auto Unseal 環境では Recovery Key を対象に rekey（-recovery）

データ暗号鍵のローテーション例（参考）

# Rekey と混同しないよう注意
vault operator rotate
# 進行状況や鍵世代は監査ログやメトリクスで確認（環境に依存）

トラブルシュートと試験の観点

最頻出のつまずきは、ノンス紛失や PGP 鍵の不一致です。開始時の構成（share 数・しきい値・PGP 鍵の数）がずれていると最後に出力が揃わず、やり直しが発生します。ノンスは再開・中止にも必要なため、安全かつ確実に保管します。

試験では、どの構成でどのキーが対象か（手動アンシール＝Unseal、Auto Unseal＝Recovery）、目的が何か（Rekey と Rotate の違い）、PGP による安全配布の意義、が狙われます。

• ノンス管理: 紛失すると再開・中止が困難。安全チャネルで共有し、短時間で完結させる
• PGP 数の整合: 新 share 数と公開鍵件数を一致させる（Keybase ならユーザー数）
• 参加者拘束時間: 入力待ちでタイムアウトや日跨ぎを避ける計画を
• ログ: 監査ログを有効化し、誰がどの操作を行ったかを記録
• 演習: 検証環境で疑似実施してから本番に臨む

PGP で暗号化された share の復号イメージ（各受領者ローカルで実施）

# 受領した share が PGP で暗号化されている前提の例
# 実際の出力形式は環境・オプションに依存

echo "<encrypted_share_base64>" | base64 -d | gpg --decrypt
# 復号したプレーンテキストの share は安全に保管し、誤転送・再配布を禁止

問題で確認

よくある質問