VaultのSeal/Unsealを正しく理解する：起動時フローの基本

Vaultはプロセス起動直後は必ず“Sealed”状態から始まり、Barrierを開くUnsealが完了して初めて秘密情報を扱えます。

本稿では、起動〜Unseal〜HAアクティブ化までの流れと、Shamir方式（手動）とKMS/HSM方式（Auto Unseal）の違いを、運用と試験対策の両視点で押さえます。

起動時フローの全体像

Vaultは設定ファイルを読み込み、ストレージ（Raft統合ストレージやConsul等）、リスナー、そして“seal”スタンザ（デフォルトはShamir）を初期化します。プロセスは必ずSealedで立ち上がり、Barrier（暗号化のバリア）を開くUnsealが必要です。

Unsealが完了すると、HA構成ではリーダー選出が行われ、1台がActive、他はStandbyとして動作します。Auto Unseal構成では各ノードがKMS/HSMに問い合わせて自動的にBarrierを開き、手動操作は不要になります。

• プロセス起動 → 設定読込 → ストレージ接続（Raft/Consul等）
• Sealスタンザ適用（Shamir もしくは KMS/HSM 等）
• 状態はSealed（vault status で確認可能）
• Unseal（手動 or Auto）
• Barrier復号に成功 → Unsealed
• HAリーダー選出（Active/Standby）

Vault 起動〜Unseal〜HA化の流れ（概念図）

 [Client]
    |
[Vault Process] --read--> [Config: storage/listener/seal]
    |
    v
 [Sealed Barrier]
   / \
  /   \
manual  auto
(SHAMIR) (KMS/HSM)
  |         |
  v         v
[Unseal Shares t/n]   [KMS decrypt barrier key]
        \             /
         v           v
           [Barrier Opened]
                   |
                   v
             [HA Election]
              /         \
             v           v
         [Active]     [Standby]
            |            |
      serve writes   proxy/reads* (*構成による)

Seal/Unsealの内部動作と用語

Vaultはストレージ上のデータを“Barrier”で暗号化し、Barrierを開くための鍵素材を保護します。初期化（operator init）時に生成されるマスターキーは、Shamirの秘密分散で分割され（手動Unsealの場合）、所定のしきい値に達すると復元されてBarrierが開きます。

Auto Unsealでは、マスターキーの保護と復号をKMS/HSM等の外部キーマネージャが担い、起動時に自動でBarrierが開きます。この場合は“復旧キー（Recovery Keys）”が発行され、災害復旧やrootトークン生成等の特定オペレーションに用います。

• Sealed: Barrierが閉じており、ストレージのデータは復号できない状態
• Unseal: しきい値（t/n）を満たすUnsealキー、またはKMS/HSMを用いてBarrierを開く操作
• Shamir分散: 手動Unsealで配布されるキー分割（n個の共有、t個が必要）
• Auto Unseal: KMS/HSMにより自動復号。各ノードが起動時に外部鍵を利用
• Recovery Keys: Auto Unseal時に配布される分散鍵。generate-rootやrekey等の保守操作に用いる

手動Unseal（Shamir）の実務手順

手動Unsealは、初期化で作成したUnsealキーのうち“しきい値”の数だけを入力してBarrierを開きます。HAクラスタでは各ノードでUnsealが必要です（Active/Standbyともに）。

キー管理は運用上の要。共有数としきい値は組織の人員/BCPに合わせて設計し、キーの保管・配布・ローテーション（rekey）を計画します。

• 初期化はクラスタで一度だけ。二重初期化はデータを失います。
• unsealは各ノードで複数回実行（t回）し、vault statusで確認。
• rekeyは安全なメンテナンスウィンドウで実施。旧キーは失効させる。

典型的な手動Unseal手順（例）

# 初期化（共有数5、しきい値3）※クラスタで一度のみ
vault operator init -key-shares=5 -key-threshold=3
# => Unseal Key 1..5 と 初期rootトークンが出力される（安全に保管）

# Unseal（1台につき3回、異なるキーを入力）
vault operator unseal
vault operator unseal
vault operator unseal

# 状態確認
vault status
# Sealed: false になっていればUnseal完了

# しきい値の変更や共有の再生成（ローテーション）
vault operator rekey -key-shares=5 -key-threshold=3

# 手動で再Sealする場合（緊急時の遮断など）
vault operator seal

Auto Unseal（KMS/HSM）の設計と設定

Auto Unsealは、Vaultのマスターキーを外部KMS/HSMで保護し、起動時に各ノードが自動でBarrierを開きます。人的オペレーションを減らし、再起動やスケールアウト時の負担を抑えられます。

本方式ではUnsealキーの代わりにRecovery Keysが発行されます。generate-rootやrekey（recovery用）など特定の保守操作に必要となるため、分散保管ポリシーを整えておきます。

• 各ノードからKMS/HSMへの到達性と認可（IAM/Service Principal等）が必須
• KMS障害時は新規起動したノードのUnsealができない点に留意（既にUnsealedなノードは動作継続）
• クラウドKMSの鍵ローテーションポリシーとVaultのrekey手順を整合
• 監査: Vault auditデバイスとKMS側のアクセスログを突合できる状態に

Auto Unseal（AWS KMS例）設定スニペット

# /etc/vault.d/config.hcl（抜粋）
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

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

seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

api_addr = "https://vault-1.example.com:8200"
cluster_addr = "https://vault-1.example.com:8201"

HAクラスタとUnsealの関係

HA構成（Raft/Consul）では、全ノードがUnsealedであることが前提です。Activeノードがリーダーとして書き込みを担当し、Standbyはリクエストのプロキシや読み取り（設定と機能に依存）を行います。未Unsealのノードはクラスタに参加できず、フェイルオーバーの健全性を損ないます。

Auto Unsealでは各ノードが独立してKMS/HSMに問い合わせてUnsealします。手動Unsealでは各ノードでしきい値回数のキー入力が必要です。ローリング再起動時は、Unsealの自動化（Auto Unseal）または運用手順書の整備が効果的です。

• 初期化は1回のみ。以降に追加するノードは“join”→“unseal”の順で参加
• status監視（Sealed, HA Mode, Active/Standby）をヘルスチェックに組み込む
• 再起動テストを定期実施し、Unseal経路（手動/KMS）の健全性を確認

HA状態確認の例

# HA/Barrierの状態確認
vault status
# 出力例
# Sealed: false
# HA Enabled: true
# HA Cluster: https://vault-1.example.com:8201
# HA Mode: active  （他ノードは standby）

試験対策の要点と方式比較

Associate/Ops向けでは、手動UnsealとAuto Unsealの違い、しきい値t/n、HA各ノードのUnseal要件、KMS障害時の挙動が頻出です。コマンドでは operator init / unseal / rekey / seal / status の基本を押さえ、Auto Unseal時の“Recovery Keys”の用途（generate-rootやrecovery用rekey）を区別できるようにしておきましょう。

実務では、BCPに基づいたしきい値設計、鍵の保管先と手順化、KMS到達性の監視（VPCエンドポイントやファイアウォール）を明確にします。

• 手動Unsealは人的オペレーション、Auto Unsealは外部KMS/HSM依存
• 全ノードUnsealが前提（Active/Standbyとも）
• 二重初期化は厳禁。バックアップとDR演習を定期実施

問題で確認

よくある質問