【ITニュース解説】Lost Recovery Keys with Auto Unseal – Vault

HashiCorp Vaultは、データベースのパスワード、APIキー、認証情報といった機密性の高い情報、いわゆる「シークレット」を一元的に安全に管理するための重要なツールである。システムエンジニアにとって、これらのシークレットの安全な取り扱いは、システムのセキュリティを確保する上で不可欠だ。Vaultは、これらのシークレットを安全に保管し、必要な時にだけアクセスできるようにする役割を果たし、オンプレミス、クラウド、ハイブリッドのあらゆる環境で、集中管理と詳細な監査機能を提供する。

Vaultは「Unseal」モードで稼働し、シークレットの管理やアクセスに応じる。対して「Seal」モードではシークレットへのアクセスを停止し、安全性を確保する。セキュリティ問題発生時には即座にSealすることで不正アクセスを防ぐ。 VaultのUnsealプロセスにはShamir's Secret Sharing（シャミアの秘密分散法）が用いられることが多い。これはマスターキーを複数の断片（ポーション）に分割し、それぞれを異なる管理者に配布する方式で、例えば5つの断片のうち3つが集まらなければキーを復元できないように設定する。しかし、この手動Unsealは、頻繁な再起動や緊急時の対応には手間がかかる。 この手間を解消するため、「Auto Unseal」機能がある。Auto Unsealでは、Unsealキーの保護をAWS Key Management Service（AWS KMS）のような信頼できる外部サービスに委ねる。これにより、Vaultは起動時に自動的にUnsealされ、管理者の介入なしにシークレットへのアクセスが可能となる。

Auto Unsealが設定されていても、新しいrootトークンの生成やキーの再生成（Rekey）といったVaultの重要な管理操作には、Unsealキーとは別の「Recovery Key」が必要だ。Recovery KeyはVaultをUnsealするためではなく、特定の管理操作に対する承認を得るために使用され、これもShamir's Secret Sharingによって管理される。 今回のケースでは、システムはAuto Unsealで稼働していたが、rootトークンの再生成やスナップショットの保存・復元に必要なRecovery Keyが失われてしまった。Vaultの状態を確認すると、Auto UnsealがRecovery Keyを使用していることが示されており、このキーがなければこれらの操作が実行できない状態だった。

解決の鍵はShamir's Secret Sharingの特性にあった。この技術では、一度シークレット（Recovery Key本体）が生成されていれば、そこから何度でも新しいポーションを生成できる。元のシークレット自体が失われていなければ、ポーションを紛失しても再生成が可能だ。 そこでまず、Vaultのストレージ（例えば/opt/vault/core/）を調査し、「_recovery-key」というファイルを発見した。このファイルには、Auto Unsealで使われるAWS KMSによって暗号化されたRecovery Key本体が保存されていた。AWS KMSのキーIDと適切な権限があれば、この暗号化されたキーを復号化できると判断された。 HashiCorp提供のGo言語ライブラリとVault設定ファイルから取得したAWS KMSラッパーキーIDを使い、ストレージから抽出した暗号化Recovery Keyを復号化した。これにより、失われていたRecovery Keyの「本体」を復元できた。 次に、復号化されたRecovery Key本体から、Shamir's Secret Sharingの原理に基づき、新しいRecovery Keyポーションを再生成するプログラムを実行。これにより、Vault管理操作に必要な新しいポーションセットが生成された。 最後に、この新しく生成されたRecovery Keyポーションを使用してVaultのRecovery Keyを再生成（Rekey）し、rootトークンを生成するテストで無事にログインできることを確認した。古いポーションではrootトークン生成が失敗することから、Rekeyが正しく行われ、問題が解決したことが裏付けられた。

この解決策は、Shamir's Secret Sharingの原理に基づき、元のシークレットがあれば新しいポーションをいつでも生成できるという特性を活かしたものだ。Recovery Keyポーションが失われても、Recovery Key本体を復元し、そこから新しいポーションを生成することで、必要な管理操作を再開できた。 今後の運用では、Recovery KeyがUnsealに直接利用できるよう求める声もあるが、現状はそうではないため、AWS KMSのような外部サービスを使うAuto Unsealにおいても、自身のキーを導入し、バックアップを用意しておくことが推奨される。これにより、Auto Unsealサービス自体に障害が発生した場合でも、代替手段でVaultをUnsealできる。また、Kubernetesなどのコンテナオーケストレーション環境におけるシークレット管理とのより深い連携も、今後の課題として挙げられている。