Shamir 分散秘密とVaultでの鍵シャーディング実務

Vaultはストレージを暗号化するためのマスターキーをShamir分散秘密で分割し、一定数のシャードを集めたときだけ復元できるようにします。これがいわゆる鍵シャーディングです。

本稿では、N-of-Mのしきい値設計、手動アンシールと自動アンシール、リキーやリカバリ鍵の違いを、コマンド例と運用ガードレールを交えて解説します。Associate / Opsレベルの出題を意識した要点整理付き。

Shamir分散秘密の基礎とVaultのシール動作

Shamir分散秘密は、1つの秘密値をM個のシャードに分割し、N個以上を集めたときだけ復元できる方式です。Vaultはこの性質を使い、マスターキーを直接保持せず、アンシール時にしきい値分のシャード提供を受けて復元します。

Vaultが起動すると初期状態はシール済みで、ストレージのデータは暗号化バリアの背後にあります。しきい値分のアンシール鍵（シャード）が与えられると、マスターキーが復元されアンシールされます。自動アンシールを構成している場合、HSMやクラウドKMSがこの復号を自動的に行い、Shamirで配布されるのはリカバリ鍵になります。

• N-of-Mの代表例は3-of-5。5人に配布し、うち3人の合意でアンシール可能。
• アンシール鍵は秘密そのものではなく、秘密を復元するためのシャード。
• 自動アンシール構成時は通常の運用でアンシール鍵を使わない。代わりにリカバリ鍵が発行される。

3-of-5のShamirとVaultシール/アンシールの流れ

サンプル: 現在のシール状態を確認する

vault status
# Key             Value
# Seal Type       shamir | awskms | gcpckms | hsm ...
# Sealed          true/false
# Unseal Progress 0/3  など

鍵シャーディングの設計ポイント

シャード数Mとしきい値Nは、事業継続性と内部統制の両立で決めます。多すぎるMは配布負荷と漏えいリスクを上げ、Nが高すぎると障害時にアンシールできない恐れがあります。一般的にはM=5〜7、N=3程度から検討を開始します。

自動アンシールがある場合も、災害復旧やトークン喪失への備えとしてリカバリ鍵の保管運用を定義しておきます。PGPで各シャードを個別に暗号化し、ホット/コールドラインと監査の分離を設けるのが実務的です。

• 配布は役割分散（SRE、セキュリティ、管理部門など）で持ち回りにする
• しきい値Nは休暇・交代要員を見込んだ可用性優先で決定
• 紙・HSMカード・パスワードマネージャなど媒体の多様化と保管場所の分離
• PGPを使う場合はvault operator initの-pgp-keysを利用

サンプル: しきい値設計に合わせた初期化オプション

vault operator init \
  -key-shares=5 \
  -key-threshold=3 \
  -pgp-keys="key1.asc,key2.asc,key3.asc,key4.asc,key5.asc"
# 出力される各シャードは対応するPGP公開鍵で個別暗号化される

初期化とアンシールの手順

初期化では、Vaultがバックエンドに暗号化バリアを構築し、Shamirで分割された鍵と初期ルートトークンを生成します。自動アンシール構成時はアンシール鍵ではなくリカバリ鍵が出力されます。

アンシールはしきい値に達するまで複数回の鍵入力を行います。クラスタでは各ノードをアンシールする必要があります（自動アンシールを除く）。

• 初期化は一度だけ。すでに初期化済みのストレージに対して再初期化しない
• 各シャードの受け渡しはオフラインで安全に。チャットやメールは避ける
• アンシール完了後は管理者トークンのローテーションを早期に行う

コマンド例: 初期化とアンシール

# 初期化（手動アンシール構成の例）
vault operator init -key-shares=5 -key-threshold=3 > init.out

# 出力からUnseal Key 1..5を安全に配布

# アンシール（しきい値分を順に入力）
vault operator unseal <Unseal_Key_1>
vault operator unseal <Unseal_Key_2>
vault operator unseal <Unseal_Key_3>

# 状態確認
vault status

# 自動アンシール構成時は初期化でRecovery Keyが出力される
# 通常運用ではunsealは不要（自動）。recovery操作時のみ鍵を使用

リキーとルートトークンの生成・ローテーション

運用中にシャード配布先やしきい値を変更したくなる場面では、リキーを実行します。リキーは現在のしきい値を満たす提供を受けて新しいセットを生成します。PGPを併用している場合は新しいPGP鍵を渡して再暗号化します。

ルートトークンを紛失した場合はgenerate-rootを使います。自動アンシール構成ではリカバリ鍵のしきい値を満たす必要があります。

• リキーは計画停止やメンテナンスウィンドウを確保して実施
• しきい値を上げると可用性が下がる点に注意
• 生成された新しい鍵セットの配布と古いセットの回収・破棄を必ず実施

コマンド例: リキーとルートトークン生成

# アンシール鍵のリキー（手動アンシール構成）
vault operator rekey -init -key-shares=7 -key-threshold=4
# 出力されたNonceを保持し、しきい値分の現行鍵を順に入力して承認
vault operator rekey -nonce=<nonce> <Unseal_Key_1>
...

# 自動アンシール構成でのリカバリ鍵のリキー
vault operator rekey -target=recovery -init -key-shares=5 -key-threshold=3
vault operator rekey -target=recovery -nonce=<nonce> <Recovery_Key_1>
...

# ルートトークンの再生成（generate-root）
vault operator generate-root -init
# 出力されたOTP/Nonceを保持し、しきい値分の鍵を提供
vault operator generate-root -nonce=<nonce> <Key_Share_1>
...
# 完了すると新しいルートトークンが表示（またはOTPで復号）

運用ガードレールと試験対策ポイント

Associate / Opsでは、ShamirのN-of-M、アンシール鍵とリカバリ鍵の違い、自動アンシールの利点と前提、リキーとgenerate-rootの使いどころを正確に区別できれば十分です。

実務では、権限分散、鍵の媒体と保管場所の分離、監査有効化、災害復旧手順の演習が鍵シャーディングの成否を分けます。

• auditデバイスを有効化し、鍵操作と管理APIを監査
• wrap TTL付きのレスポンスラッピングを利用し、鍵やトークンの移送を防御
• KMS/HSMのIAM、可用性、DRをVaultと同等レベルで設計
• クラスタでは各ノードのアンシール要件と自動アンシールの挙動を確認
• 手順書はオフラインで参照可能な形で保管し、年1回は演習

チェックリスト例: 監査と安全な受け渡し

# 監査の有効化（ファイル例）
vault audit enable file file_path=/var/log/vault_audit.log

# レスポンスラッピング（一次シークレットの受け渡し）
VAULT_TOKEN=<admin> vault kv get -wrap-ttl=5m secret/bootstrap
# 受け取り側はwrapping_tokenのみを受領し、unwrap
vault unwrap <wrapping_token>

問題で確認

よくある質問