HashiCorp Vault - 暗号化全般

HashiCorp Vaultとは

HashiCorp Vaultは、シークレット管理、暗号化サービス、アクセス制御を提供するオープンソースツールです。APIキー、パスワード、証明書、暗号化キーなどの機密情報を安全に保存し、きめ細かいアクセス制御と監査ログを提供します。

Vaultの主要機能：

• シークレット管理：静的/動的なシークレットの保存と配布
• Encryption as a Service：アプリケーションデータの暗号化
• 動的シークレット：データベース認証情報のオンデマンド生成
• PKI：証明書の発行と管理
• アクセス制御：ポリシーベースの権限管理

これらの機能を支えているのは、Vault独自の暗号アーキテクチャです。次の「仕組み・詳細解説」では、内部でどのようにデータが暗号化され、鍵が保護されているのかを実装レベルで見ていきます。

仕組み・詳細解説

Vaultが単なる「暗号化されたKVSストア」ではなく企業のシークレット管理基盤として選ばれているのは、内部にある暗号アーキテクチャの設計によるところが大きいです。ここでは実装レベルでの仕組みを4つの観点から解説します。

暗号バリア（Barrier）とストレージの暗号化

Vaultのアーキテクチャの中核は「Barrier」と呼ばれる暗号化レイヤーです。Vaultはシークレット・ポリシー・監査ログなど内部で扱うすべてのデータを、Integrated Storage（Raftベース）やConsul、あるいはファイルシステムといった実際のストレージバックエンドに書き込む前に、必ずこのBarrierを通過させてAES-256-GCMで暗号化します。逆に言えば、ストレージバックエンド自体は平文を一切保持せず、ディスクやバックアップファイルが漏洩してもBarrierの鍵がなければ内容を復元できません。この暗号化に使う鍵（Encryption Key）自体も、さらに上位の鍵（Root Key）で暗号化されて保管されており、「鍵を暗号化する鍵」という階層構造（Key Encryption Key）を形成しています。

Shamir's Secret SharingによるUnseal（アンシール）

Vaultを初期化した直後は「Sealed（封印）」状態にあり、Barrierを復号するためのRoot Keyにアクセスできません。このRoot Keyは、暗号学者Adi Shamirが1979年に発表したShamir's Secret Sharingというアルゴリズムによって複数の断片（Unseal Key）に分割されます。既定ではvault operator init実行時に5個のUnseal Keyへ分割し（key-shares=5）、そのうち3個が揃わないと復号できない（key-threshold=3）という閾値方式が使われます。

# Vaultの初期化（5分割・閾値3）
vault operator init -key-shares=5 -key-threshold=3

# Unseal（閾値分だけ異なる担当者が個別に実行）
vault operator unseal <unseal-key-1>
vault operator unseal <unseal-key-2>
vault operator unseal <unseal-key-3>

この方式により、単一の管理者がRoot Keyを単独で保持・悪用できない「権限分散（Knowledge Split）」が実現されます。ただし手動Unsealは運用負荷が高く、実務ではAWS KMS・GCP Cloud KMS・Azure Key Vault等のクラウド鍵管理サービスを使ってVault自身のUnseal処理を自動化するAuto Unsealを採用し、Shamir方式の手動Unsealはディザスタリカバリ用の最終手段として保持しておくのが定石です。

Transit Secrets Engineによる暗号アルゴリズムの詳細

Vaultの「Encryption as a Service」を実現するのがTransit Secrets Engineです。既定の暗号方式はAES-256-GCM（認証付き暗号／AEAD）ですが、ChaCha20-Poly1305、RSA-2048/3072/4096、ECDSA（P-256/P-384/P-521）、Ed25519といった鍵タイプも選択できます。アプリケーションは平文をVaultのAPIに送信し、Vaultが暗号化・復号を代行するため、暗号鍵そのものはアプリケーションコードやDB設定ファイルに一切露出しません。

# Transit engineの有効化と鍵作成
vault secrets enable transit
vault write -f transit/keys/ml-pipeline-key

# 暗号化・復号
vault write transit/encrypt/ml-pipeline-key plaintext=$(base64 <<< "secret-data")
vault write transit/decrypt/ml-pipeline-key ciphertext="vault:v1:...."

# 鍵のローテーション（ダウンタイムなし）
vault write -f transit/keys/ml-pipeline-key/rotate

鍵はバージョン管理されており、ローテーション後もmin_decryption_versionの設定次第で旧バージョンで暗号化されたデータの復号を継続できます。これにより「暗号鍵の定期ローテーション」と「既存データの継続利用」を両立できる点が、自前で暗号処理を実装する場合との大きな違いです。

動的シークレットとリース（Lease）・TTLモデル

Vaultの静的なKVストア機能に加えて特徴的なのが、Database Secrets EngineやAWS Secrets Engineなどが提供する「動的シークレット」です。あらかじめ登録したPostgreSQL・MySQL・AWS IAMなどに対し、Vaultがリクエストの都度、短命な認証情報をオンデマンドで発行します。発行された各シークレットにはLease ID（貸与ID）とTTL（有効期限）が付与され、期限が切れると自動的に失効（Revoke）します。これにより、仮にシークレットが漏洩しても悪用可能な時間を数分〜数時間程度に限定でき、恒久的なパスワードを使い回すよりもリスクを大幅に縮小できます。

AIエンジニアとしての実体験

AIエンジニアとして、機械学習パイプラインでのシークレット管理にVaultを活用しています。APIキー、データベース接続情報、モデルストレージの認証情報などを安全に管理できます：

# Vault CLIでシークレットを保存
vault kv put secret/ml-pipeline/openai api_key="sk-..."

# シークレットの取得
vault kv get -field=api_key secret/ml-pipeline/openai

# 動的データベースシークレットの取得
vault read database/creds/ml-readonly

# Pythonでの使用例
import hvac

client = hvac.Client(url='https://vault.example.com:8200')
client.token = os.environ['VAULT_TOKEN']

# シークレットの取得
secret = client.secrets.kv.v2.read_secret_version(
    path='ml-pipeline/openai'
)
api_key = secret['data']['data']['api_key']

Kubernetesとの統合

Kubernetesでのシークレット管理にVaultを使用する設計：

# Vault Agent Sidecar Injector
apiVersion: v1
kind: Pod
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "ml-pipeline"
    vault.hashicorp.com/agent-inject-secret-config: "secret/ml-pipeline/config"
spec:
  containers:
  - name: ml-app
    image: ml-inference:latest

メリット・デメリット

Vaultの導入を検討する際は、機能の豊富さだけでなく運用コストとのトレードオフを理解しておく必要があります。

混同されやすい用語・類似技術との違い

「Vault（金庫）」という一般名詞が示す通り、シークレット管理の文脈では類似の製品やコンポーネントが多数存在し、しばしば混同されます。代表的なものとの違いを整理します。

トラブル事例と対策

実装上の注意点

実務でVaultを本番導入する際に押さえておくべきポイントを整理します。

• Rootトークンの取り扱い：初期化時に発行されるRootトークンは万能権限を持つため、初期設定完了後はvault token revokeで失効させ、日常運用では最小権限ポリシーを紐づけたトークン・AppRole認証を使う。
• Unseal Keyの分散管理：Shamirで分割したUnseal Keyは、必ず異なる担当者・異なる保管場所（金庫・パスワードマネージャー等）に分散させ、単一障害点・単一人物への集中を避ける。
• Auto Unsealの採用：本番運用ではクラウドKMSによるAuto Unsealを基本とし、手動Shamir方式は災害復旧用の最終手段として文書化しておく。
• 認証方式の選定：人間の運用者にはOIDC/LDAP等の既存IDプロバイダ連携、アプリケーションにはAppRoleやKubernetes認証（ServiceAccountのJWTを検証）を使い、静的トークンの直書きを避ける。
• 監査ログ（Audit Device）の有効化：既定では監査ログが無効なため、導入時に必ずファイル監査デバイスまたはSyslog監査デバイスを有効化し、誰がいつどのシークレットにアクセスしたかを追跡できるようにする。
• バックアップとDR：Raft SnapshotやConsulのスナップショットを定期取得し、別リージョン・別クラウドへのリストア手順を年に一度は実際に検証する。

最新動向（2026年）

Vaultを取り巻く動向は、Kubernetesとの統合強化、マネージドサービスの普及、そして買収に伴うエコシステムの変化という3つの軸で進んでいます。

Kubernetes統合の標準化

Vault Secrets Operatorにより、KubernetesのPodが起動時にVaultからシークレットを自動取得し、ローテーション時にも自動的に同期される仕組みが標準化されました。従来のVault Agent Sidecar Injectorに加え、CSI Provider・Secrets Operatorという複数の統合方式から用途に応じて選択できるようになっています。

HCP Vault / HCP Vault Secretsの普及

HashiCorp Cloud Platform（HCP）が提供するマネージドVaultサービスにより、Self-Hosted環境特有のHA構成・バックアップ・アップグレード作業をHashiCorp側に委ねられます。小規模チーム向けの軽量版であるHCP Vault Secretsも普及が進み、SaaSアプリケーションやCI/CDパイプラインからの利用ハードルが下がっています。

IBMによる買収とライセンス・エコシステムの変化

2024年のIBMによるHashiCorp買収以降、VaultはIBMのセキュリティ製品ポートフォリオへの統合が進められています。一方、2023年のBSL（Business Source License）へのライセンス変更を契機に、Linux Foundation配下でVault OSS版をフォークしたOpenBaoのようなオープンソース代替の開発も継続しており、商用版とOSS系フォークという選択肢の多様化が進んでいます。導入・移行の検討時はライセンス条件を必ず最新の一次情報で確認することが重要です。

暗号アルゴリズムと標準規格への準拠

暗号技術の観点では、Transit Secrets EngineのデフォルトであるAES-256はNIST SP 800-57が示す長期的に安全とされる鍵長の推奨に合致しており、当面は標準的な選択肢であり続けると考えられます。連邦政府機関等の要件がある環境では、Vault EnterpriseのFIPS 140-2/140-3検証済みモジュール構成を利用することで、暗号モジュールの認定要件を満たすことができます。また、量子コンピュータの実用化を見据えた耐量子暗号（Post-Quantum Cryptography）についても業界全体で標準化・移行の議論が進められており、Vaultを含む鍵管理基盤についても今後のアルゴリズム移行（Crypto Agility）を見据えた設計が一般に推奨されています。

関連用語

• シークレット管理 - 機密情報の安全な管理手法
• 鍵管理 - 暗号鍵のライフサイクル管理
• 鍵ローテーション - 暗号鍵を定期的に更新する運用手法
• HSM - ハードウェアセキュリティモジュール
• PKI - 公開鍵基盤と証明書発行の仕組み
• AEAD - Transit Secrets Engineが使う認証付き暗号方式

外部リンク・参考資料

• HashiCorp Vault公式サイト - 製品概要・機能一覧
• Vault Documentation - Transit Secrets Engine、Auto Unseal等の公式ドキュメント
• Vault GitHub - ソースコード・Issue・リリースノート
• NIST SP 800-57 Part 1 - 鍵管理に関する推奨事項（鍵長・アルゴリズム選定の基準）
• NIST Cryptographic Module Validation Program - FIPS 140-2/140-3の検証済みモジュール一覧
• OpenBao公式サイト - Linux Foundation配下のオープンソースフォークプロジェクト

📝 関連ブログ記事

【2026年最新】OpenSSLの深刻な問題とは？

シークレット管理のご相談