Vault のHSM連携: FIPS要件と設計の実務

HSM連携は、Vaultのマスターキー保護と自動アンシールを実現し、FIPS 140-2/140-3の要件充足に直結します。とはいえ、ベンダーごとのPKCS#11差分やFIPSモードの前提、TLS暗号スイート制約など、設計・運用で外せない細部があります。

本稿は、公式ドキュメントに基づく安定した概念を中心に、Opsとして現場で迷いがちなポイントを具体化。試験対策（Operations系）で問われやすい比較観点と落とし穴も併せて押さえます。

アーキテクチャと用語整理（HSM・PKCS#11・自動アンシール）

Vaultはシール鍵（バリア鍵）でデータを保護します。HSM連携では、この鍵素材の生成・保持・暗号処理をHSMに委譲し、起動時にHSMが自動的にアンシール（Auto Unseal）します。これにより、運用者がシャミア分散のアンシール鍵を持ち回る必要がなくなります。

PKCS#11はHSMとアプリケーションをつなぐ標準APIで、Vaultはsealタイプとしてpkcs11をサポートします。実運用ではベンダーのPKCS#11ライブラリ、スロット、PIN、キーラベルの整合性が肝になります。

FIPS適合を主張するには、FIPS認証済み暗号モジュール（VaultのFIPS準拠ビルドやHCP提供物など）と、FIPS認証済みHSM、FIPS承認アルゴリズムのみを使うTLS設定など、システム全体の設計が問われます。

• 自動アンシール: HSMが鍵素材を保護し、起動時にアンシールを自動化
• Recovery Keys: 自動アンシール構成時に配布される復旧用の鍵（手動アンシール鍵とは別物）
• Seal Wrap: ストレージ上の機密エントリを、シール鍵由来の鍵で二重に保護するエンタープライズ機能

Vault と HSM（PKCS#11）による自動アンシールとFIPS適合の全体像

最初に押さえる確認コマンド（疎通と状態）

vault status
# HSMスロット・トークン確認（ベンダー依存。例: OpenSC）
pkcs11-tool -L
# VaultのTLS疎通確認（FIPS承認スイートのみで接続できるか）
openssl s_client -connect vault.example.com:8200 -tls1_2

FIPS要件のチェックリスト（暗号モジュール・TLS・鍵境界）

FIPS適合は単一プロダクトではなく、暗号モジュール、TLS構成、鍵のライフサイクル全体を含むシステム要件です。Vault単体の設定に加え、OS/ライブラリ、HSMの運用手順、監査証跡まで含めて設計します。

特にTLSは見落とされがちです。最小バージョンをTLS 1.2以上に固定し、FIPS承認スイートのみに限定します。クライアント/中間プロキシ側の非FIPSスイートを許可すると、評価で不適合判定を受けやすくなります。

• VaultはFIPS準拠ビルド/HCPなど公式のFIPS対応提供物を利用する
• HSMはFIPS 140認証済みモデルを選定し、鍵のバックアップ/クローン手順を運用設計に含める
• TLSはtls_min_versionとtls_cipher_suitesでFIPS承認のみに制限
• 監査ログは改ざん耐性のある宛先に出力し、時刻同期を厳密化
• 鍵素材はHSM外に抽出しない方針を明文化（鍵境界の明確化）

FIPS観点の境界イメージ

TLSのFIPS志向設定例（listener/tcp）

listener "tcp" {
  address          = "0.0.0.0:8200"
  tls_disable      = 0
  tls_min_version  = "tls12"
  # 環境のGo/OS実装に依存。代表的なFIPS承認スイートを列挙
  tls_cipher_suites = [
    "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ]
  tls_cert_file    = "/etc/vault/tls/server.crt"
  tls_key_file     = "/etc/vault/tls/server.key"
}

HSM連携の設定例（PKCS#11 自動アンシール）

Vaultではsealにpkcs11を指定し、ベンダーのPKCS#11ライブラリ、スロット、PIN、キーラベルを設定します。初回起動時にHSM内で鍵を生成するか、既存ラベルの鍵を参照するかを選びます（ベンダーツールで事前作成する方式も一般的）。

ベンダーごとにライブラリのパスやスロット表現、PINポリシーが異なります。Cloud HSMやネットワーク型HSMでは、クライアントミドルウェアの状態（ログインセッションや接続数上限）が起動の成否に影響します。

• libraryはPKCS#11共有ライブラリの絶対パス（例はベンダーごとに異なる）
• slotは整数またはトークンラベルで指定される場合があるため、ベンダーツールで実値確認
• key_labelとhmac_key_labelは衝突しないよう運用命名規則を設ける
• PIN更新時はVault再起動計画と同時に行い、全ノードで整合させる

起動〜自動アンシールの最小フロー

vault.hcl（PKCS#11自動アンシールとRaftの一例）

seal "pkcs11" {
  library         = "/opt/vendor/lib/pkcs11.so"   # 例: /opt/cloudhsm/lib/libcloudhsm_pkcs11.so 等
  slot            = "0"                              # ベンダー/環境に依存
  pin             = "file:/etc/vault/hsm.pin"       # 外部ファイル参照も可（権限管理必須）
  key_label       = "vault_wrap_key"
  hmac_key_label  = "vault_hmac_key"
  generate_key    = true                             # 既存鍵を使う場合はfalse
}

storage "raft" {
  path    = "/var/lib/vault"
  node_id = "vault-1"
}

listener "tcp" {
  address          = "0.0.0.0:8200"
  tls_disable      = 0
  tls_min_version  = "tls12"
}

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

運用・トラブルシュート要点（セッション・PIN・レイテンシ）

HSM連携の障害は、PIN不一致、スロット誤指定、ライブラリ不整合、セッション上限超過、ネットワーク遅延に収束しがちです。ノードごとにHSMクライアントを同一バージョンで整え、HSM側の監査ログと突き合わせて原因特定します。

起動直後にアンシールできない場合、HSM側の並列セッション数やトークンポリシーで弾かれていることがあります。再試行のバックオフやノードシリアライズ起動を検討します。

• セッション上限: HSMの同時ログイン許容量を超えないよう、ノード数とワーカー数を設計
• PIN変更: 全ノードで同期。ローリング再起動計画を用意
• 遅延: HSMが遠隔拠点にあるとアンシールが遅延。ネットワーク品質をSLOに反映
• 監査: HSMの監査ログをVaultイベントと時刻同期して相関分析

簡易トラブルシュート分岐

現場で使う確認系コマンド例

# HSMスロット/トークン
pkcs11-tool -L
# Vaultステータス
vault status
# Recovery Keysの有無と閾値確認（出力取り扱い注意）
vault operator init -status
# HSMクライアント（例: CloudHSM）のセッション確認はベンダーツールを使用

可用性とDR設計（HSMクラスター/Recovery/バックアップ）

HSMは単体障害に備えクラスター化するのが前提です。Vaultノードは全て同一のHSMクラスターに到達できるようネットワークとクライアント設定を統一します。鍵はHSMベンダー機能でレプリケーション/バックアップし、DRサイトのHSMにも事前配備します。

VaultのデータはRaftスナップショット等でバックアップしますが、シールラップによりHSM鍵で保護されたままです。DRで復旧する際は、対象サイトのHSMに同一ラベルの鍵が存在することが前提になります。

• HSMクラスター間で鍵をクローン/同期する標準手順を確立
• DRサイトはVaultとHSMの両方を用意（ネットワーク疎通・証明書も事前整備）
• 定期的にDRフェイルオーバー訓練を実施し、RTO/RPOを実測で確認
• Recovery Keysの保管は本番/DRで分散し、紛失時の手順を文書化

プライマリ/DRとHSMの対応関係

バックアップ/DR関連の代表コマンド

# Raftスナップショット保存（権限要）
vault operator raft snapshot save /backup/vault.snap
# リストアはDR環境で停止状態から実施（手順は本番と分離保管）
# HSM側の鍵配備はベンダーツール（例: クローン/バックアップリストア）で実施

選定と比較：HSM vs Cloud KMS vs 手動アンシール

規制要件、RTO/RPO、運用負荷、コストで選定は変わります。FIPS 140のレベルや"ハードウェア境界内に鍵を留める"要件があるかどうかをまず確認します。運用面では、起動時のSLOと鍵ライフサイクルの手順化がポイントです。

Cloud KMSはFIPS承認モジュールを用いる場合が多いものの、"専用HSM内での鍵保持（アクセス境界の明確化）"という厳格な要件があるなら、PKCS#11で直接連携する専用HSMが選好されます。

• 専用HSMは鍵境界を最も厳格にできるが、導入/運用コストは高い
• Cloud KMSは運用しやすいが、要件次第では境界定義が合致しないことがある
• 手動アンシールは最小構成だが、FIPS観点や運用SLOでは不利

方式ごとの鍵境界ざっくり像

比較用：awskmsシール設定の骨子（参考）

seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:...:key/..."
  # HSMではなくKMS連携の自動アンシール例（要件に応じ選定）
}

試験対策：よく問われる観点と落とし穴

"自動アンシール時はRecovery Keysが配布され、手動アンシール鍵は不要"という差分を確実に説明できるようにします。FIPS要件の文脈では、"鍵がどこで生成・保護されるか（鍵境界）"と"TLSの最小バージョン/スイート制約"が頻出です。

設計選択肢の比較問題では、規制要件（例: FIPS 140-2 L3のハードウェア鍵保護、運用者が鍵素材に触れない）を満たす選択肢を選ぶのが定石です。

• 自動アンシール: Recovery Keys、手動アンシール: Unseal Keys を正しく区別
• FIPSは"モジュール認証＋運用手順"の両輪。TLS制約を忘れない
• PKCS#11の基本パラメータ（library/slot/pin/key_label）を暗記
• DRではHSM鍵の事前配備がないと復旧不能になり得る

用語マッピングの最小図

監査強化（試験での加点要素になりやすい）

vault audit enable file file_path=/var/log/vault_audit.log
# 監査先は改ざん耐性を確保（例: WORMストレージや集中ログ基盤）

問題で確認

よくある質問