2026.07.24 インフラ

HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説

HashiCorp Vaultは、データベースの接続情報やAPIキー、暗号鍵、TLS証明書といった機密（シークレット）を1か所に集約し、認証と権限（ポリシー）の制御のもとでアプリケーションに受け渡すシークレット管理ツールです。最大の特徴は、あらかじめ保存した値を返すだけでなく、要求のたびに有効期限付きの資格情報をその場で発行し、期限が来たら自動で失効させる「動的シークレット」を扱える点にあります。この記事では、認証→ポリシー→シークレットエンジンという3層の仕組みから、KV・データベース・PKI・Transitなど主要エンジン、Kubernetes認証やCI/CDでの連携、Azure Key VaultやAWS Secrets Managerとの違い、2023年のライセンス変更とOpenBaoフォーク・IBMによる買収の経緯まで、実装者が採否を判断するのに必要な範囲を、2026年時点の公式ドキュメントに基づいて整理します。

目次

まとめ：HashiCorp Vaultの要点と採用判断の分岐

Vaultは、ソースコードや設定ファイルに機密情報を直書きする状態を解消するための「集中金庫」です。アプリはネットワーク越しにVaultへ認証し、割り当てられたポリシーの範囲でシークレットを取り出します。ここで効くのが動的シークレットで、データベースやクラウドの資格情報を接続のたびに生成し、短い有効期限で自動失効させることで、長期間有効な固定パスワードが漏れ続けるリスクを断ち切ります。運用設計の中心になるのは、認証方式の選定、ポリシーによる最小権限、そして起動時のアンシール（封印解除）をどう自動化するかの3点です。

採用が合理的なのは、複数のクラウドやオンプレミスが混在し、シークレットを1つの基盤で横断管理したい場合や、動的シークレットで資格情報の寿命を短くしたい場合です。逆に、AWS単一構成で完結するならAWS Secrets Manager、Azure中心ならAzure Key Vaultといったクラウドマネージド型のほうが運用負荷は軽くなります。Vaultは自前で高可用性やアンシールを設計・運用する必要があるため、その運用体制まで含めて採否を決めるのが現実的です。設計や運用に不安が残る段階なら、インフラの構築・運用から相談できる開発会社に早めに当たると、後戻りの少ない構成にたどり着けます。

HashiCorp Vaultの仕組みと認証・ポリシー・エンジンの3層構造

Vaultを理解する近道は、機密が読み出されるまでの経路を「認証」「認可（ポリシー）」「シークレットエンジン」の3層で捉えることです。この3層がそれぞれ独立して効くため、誰が・何に・どこまでアクセスできるかを細かく切り分けられます。

シークレット・暗号化・証明書発行を1基盤に束ねるツールという位置づけ

Vaultが扱う仕事は保管だけではありません。任意の文字列を暗号化して保管するシークレットの保管に加え、アプリのデータを外部に鍵を出さずに暗号化・復号するEncryption as a Service、内部認証局としてTLS証明書を発行するPKI、データベースやクラウドの資格情報をその場で払い出す動的シークレットまでを、単一のAPIとポリシー体系で束ねます。提供元のHashiCorpはTerraformなどインフラ自動化ツール群を持つ企業で、その製品群の中でVaultが機密管理を担う位置づけです。会社と製品全体の関係は、HashiCorpの主要製品と事業の全体像を解説した記事で押さえておくと、Vault単体の役割が立体的に見えてきます。

認証からポリシーを経てシークレットエンジンへ至るアクセスの流れ

アクセスは必ず認証から始まります。クライアントは認証方式（Auth Method）でVaultに身元を証明し、その見返りにトークンを受け取る仕組みです。トークンには1つ以上のポリシーが紐づき、ポリシーは「このパスに対してread/createを許可」といった形で、HCLまたはJSONでアクセス範囲を宣言します。許可されたパスに対応するのがシークレットエンジンで、パスごとに別種のエンジンをマウントして機能を切り替える構成です。認証・認可・機密の払い出しがパス単位で分離されているため、アプリごとに触れる範囲を必要最小限に絞り込めます。Vaultが担うのは、あらゆるアクセスを検証してから通す発想であり、その土台となる考え方はゼロトラストの原則と境界型防御との違いを解説した記事と重ねて読むと理解が深まります。

静的シークレットと有効期限付きで自動失効する動的シークレットの違い

Vaultのシークレットは2種類に分かれます。静的シークレットは、既存のパスワードやAPIキーをそのまま保管して読み出すもので、Key/Value（KV）エンジンが担います。対して動的シークレットは、要求を受けた時点でVaultがデータベースやクラウドに接続し、その場で新しい資格情報を生成して払い出す方式です。動的シークレットにはリース（有効期限）が付き、期限が切れるとVaultが接続先に対して自動で失効させます。つまり資格情報の寿命を分単位・時間単位まで縮められ、万一漏れても被害が及ぶ時間を限定できます。長期間固定のパスワードを配り続ける運用からの脱却こそ、Vaultを選ぶ最大の理由です。

主要なシークレットエンジンと認証方式・Seal/Unsealの仕組み

実装で選択が必要になるのが、どのシークレットエンジンを使うか、アプリをどの認証方式で通すか、そして起動時の封印（Seal）をどう解くかです。ここは要件によって組み合わせが変わる部分です。

KV・データベース・AWS・PKI・Transitという代表的なシークレットエンジン

シークレットエンジンはパスにマウントする機能プラグインで、目的別に選びます。代表的なものを整理します。

エンジン 役割 シークレットの性質
KV（v2） 任意の値の保管とバージョン管理 静的
Database DBユーザーをその場で発行 動的
AWS IAM資格情報を一時発行 動的
PKI 内部認証局として証明書を発行 動的
Transit 鍵を出さずに暗号化・復号を代行 ―（暗号処理）

Databaseエンジンは、PostgreSQLやMySQLなどに対して接続のたびに専用ユーザーを作成し、リース満了で削除します。AWSエンジンが払い出すのは一時的なIAM資格情報で、その先の権限設計はAWS IAMのユーザー・ロール・ポリシーの権限モデルを解説した記事と同じ考え方で決めます。Transitエンジンは、アプリが自前で鍵を持たずにVaultへ暗号化・復号を依頼する仕組みで、鍵管理の前提は共通鍵・公開鍵の違いとデータ暗号化の基礎を解説した記事で確認しておくと設計判断がぶれません。

AppRole・Kubernetes・クラウドIAM・OIDCといった認証方式の選び分け

アプリやユーザーがVaultへ入る入口が認証方式です。人が操作する場面ではOIDCやLDAPで既存のIDと連携し、自動化されたアプリでは資格情報を持たずに認証できる方式を選びます。CI/CDやサーバー上のアプリにはAppRole（RoleIDとSecretIDの組）が使われ、Kubernetes上のPodにはKubernetes認証方式でServiceAccountトークンを検証させる方式です。AWS・Azure・GCP上のワークロードなら、各クラウドのメタデータやIAMを使ったクラウドネイティブ認証で、鍵を配布せずに身元を証明できます。「Vaultにアクセスするための資格情報をどこに置くか」という循環問題を、これらの方式が実行環境の信頼に置き換えて解消します。

Seal/Unseal・Shamirの秘密分散と自動アンシールによる起動設計

Vaultは起動直後、内部データを暗号化したまま封印（Seal）した状態にあり、マスターキーを復元しない限りシークレットを読み書きできません。既定では、マスターキーをShamirの秘密分散で複数のアンシールキーに分割し、しきい値の数（例：5分割中3つ）を集めて初めて封印を解く設計です。人手での運用は起動のたびに複数人がキーを持ち寄る必要があり現実的でないため、本番ではクラウドのKMSやHSMにマスターキーの保護を委ねる自動アンシール（Auto Unseal）を使います。再起動やスケールアウトのたびに自動で封印を解ければ、高可用性構成でも運用を止めずに済む構成です。この起動設計を軽視すると、障害復旧時にVaultだけ立ち上がらないという事故につながります。

クラウドマネージド型・OpenBaoとの違いとライセンス・買収の経緯

Vaultを検討するときに必ず比較対象になるのが、クラウド各社のマネージドサービスと、オープンソースのフォークであるOpenBaoです。ライセンス変更と買収の経緯も、採否に直結する判断材料になります。

Azure Key Vault・AWS Secrets Managerとの違いと使い分け

クラウドマネージド型は、そのクラウド内で完結する用途では運用が軽くて済みます。AWS Secrets ManagerやKMS、AzureのKey Vaultは、対象クラウドのIAMと統合され、可用性やアンシールをサービス側が引き受ける形です。一方Vaultは、クラウドやオンプレミスをまたいで機密を1つのポリシー体系で束ねられる点と、動的シークレットやTransitといった機能の幅で優位に立ちます。判断の目安は明快です。単一クラウドで完結し運用を任せたいならマネージド型、複数環境の横断管理や動的シークレットを主目的にするならVault、という切り分けになります。クラウド側の対応物であるマネージドサービスの設計はAzure Key Vaultのシークレット・キー・証明書の一元管理を解説した記事と読み比べると、自前運用と委譲の線引きが見えてきます。

BSLライセンス変更・OpenBaoフォーク・IBMによる買収という前提知識

採用判断の前提として、Vaultを取り巻く事業面の変化を押さえておきます。HashiCorpは2023年8月に、Vaultを含む主要製品のライセンスをオープンソースのMPL 2.0からBusiness Source License（BSL）1.1へ変更しました。BSLは社内利用や個人利用を認める一方、競合製品としての提供を制限し、各リリースから4年後にMPL 2.0へ切り替わる条件です。この変更を受け、BSL移行前の最後のMPL版（1.14系）を起点にコミュニティがフォークしたのがOpenBaoで、Linux Foundation傘下で2.x系として開発が続いています（2026年時点）。さらにIBMは2025年2月にHashiCorpの買収を完了し、VaultはIBM傘下の製品となりました。ライセンス条件が自社の利用形態に抵触しないか、完全なオープンソースを求めるならOpenBaoを選ぶか、という点を要件定義の段階で確認しておくと、後からの乗り換えを避けられます。

Kubernetes・CI/CDパイプラインでのVault連携の実装パターン

実装者が最も知りたいのは、アプリやパイプラインからどうシークレットを取り出すかでしょう。Vaultはコンテナ基盤とCI/CDの双方に連携する仕組みを備えています。

Kubernetes認証によるサイドカー・CSI・Operatorの取得方式

Kubernetes上での取り出し方は主に3系統あります。Vault Agent Injectorは、Podにサイドカーを注入し、取得したシークレットをファイルとして共有ボリュームに書き出す方式です。Secrets Store CSIドライバーのVaultプロバイダーは、Vaultの値をボリュームとしてマウントします。より新しいVault Secrets Operatorは、VaultのシークレットをKubernetes Secretとして同期し、アプリは通常のSecret参照だけで受け取れます。いずれもPodのServiceAccountトークンをKubernetes認証方式で検証するため、アプリ側にVault用の固定資格情報を配る必要がありません。コンテナオーケストレーションそのものの役割はKubernetesが解決する課題と自社に必要かの判断を解説した記事で確認しておくと、Vault連携の位置づけが整理できます。

CI/CDでの動的シークレット注入によるハードコード排除の設計

CI/CDパイプラインは、デプロイのたびにクラウドやレジストリの資格情報を必要とするため、機密の直書きが起きやすい場所です。ここでVaultのAppRole認証と動的シークレットを組み合わせると、ジョブ実行時にだけ有効な短命の資格情報を払い出し、ジョブ終了後は自動失効させられます。パイプライン定義や環境変数に長期キーを埋め込む運用から、実行のたびに使い捨てる運用へ切り替える形です。開発と運用をつなぐ実践全体の中でのシークレット管理の位置づけは、DevOpsの実践とツール・導入判断を解説した記事と合わせて捉えると、どこにVaultを差し込むかが見えてきます。

HashiCorp Vaultを採用すべき場面と見送るべき場面

ここからは判断です。Vaultは強力ですが運用コストも相応にかかるため、真価を発揮する場面と、マネージド型に委ねるべき場面がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

HashiCorp Vaultの採用が合理的になる実務上の条件

次のいずれかに該当するなら、Vaultが有力な候補になります。

  • 複数のクラウドやオンプレミスが混在し、機密を1つのポリシー体系で横断管理したい
  • データベースやクラウドの資格情報を動的シークレットにして、固定パスワードの寿命をなくしたい
  • 内部認証局（PKI）として短命のTLS証明書を大量に自動発行したい
  • アプリに鍵を持たせず、Transitエンジンで暗号化・復号を集中管理したい

いずれも、機密の寿命を短くし、配布そのものを減らす方向の要件です。動的シークレットとPKIを主目的に置くほど、Vaultを自前運用する手間に見合う効果が出ます。

HashiCorp Vaultを選ぶべきでない場面と適切な代替

一方で、次の要件にはVaultをそのまま当てはめません。第一に、AWS単一構成やAzure単一構成で完結し、動的シークレットまでは要らないなら、Secrets ManagerやKey Vaultなどクラウドマネージド型のほうが可用性とアンシールをサービスに任せられ、運用が軽くなります。第二に、高可用性やAuto Unsealを設計・監視する運用体制を用意できないなら、Vaultの停止がシステム全体の停止に直結するため、無理に導入すると単一障害点を増やすだけです。第三に、完全なオープンソースライセンスが要件なら、BSLのVaultではなくMPL 2.0系のOpenBaoを検討します。第四に、扱う機密がごく少数の静的な値だけなら、Vaultは過剰で、クラウドの標準機能で足ります。

受託開発におけるHashiCorp Vault運用設計の勘所と外注先への相談

実際のシステムでVaultを入れる際は、認証方式・ポリシー設計・自動アンシール・高可用性・監査ログを一体で組む必要があり、どれか1つの設計漏れが運用時の事故につながります。どの機密をどのエンジンに置き、どのアプリにどのポリシーを与え、起動をどう自動化するかは、可用性・監査要件・運用体制のトレードオフで決まり、後からの権限再設計にはアプリ改修が伴う点も見落とせません。導入だけでなく、稼働後のアンシール監視やバージョン追随、キーローテーションまで含めた継続運用が成否を分けます。Vaultを含む機密管理基盤の設計からシステムの保守運用・内製化支援まで、要件定義の段階から一貫して相談すると、導入後に運用が回らなくなる事態を避けられます。

よくある質問

HashiCorp Vaultの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

HashiCorp VaultとAWS Secrets Managerは何が違いますか？

役割は近いものの、対象範囲が異なります。AWS Secrets ManagerはAWS内で完結し、IAMと統合されて可用性もサービス側が担う設計です。Vaultはクラウドやオンプレミスをまたいで機密を1つの基盤で束ねられ、データベースやクラウドの動的シークレット、Transitによる暗号化、PKIによる証明書発行まで幅広く扱えます。単一クラウドで完結するならマネージド型、複数環境の横断管理や動的シークレットが目的ならVault、という切り分けが目安です。

静的シークレットと動的シークレットはどう使い分けますか？

既存のAPIキーや外部サービスのトークンのように、Vault側で生成できない値は静的シークレットとしてKVエンジンに保管します。データベースやAWSのように、Vaultが接続して資格情報を生成できる対象は動的シークレットにし、リース（有効期限）付きで払い出して自動失効させます。漏洩時の被害時間を縮めたいものは、可能な限り動的シークレットへ寄せるのが基本方針です。

OpenBaoとHashiCorp Vaultはどちらを選ぶべきですか？

機能面は共通の起源を持ちますが、判断軸はライセンスと運用方針です。完全なオープンソース（MPL 2.0）を要件とし、コミュニティ主導の開発を選びたいならOpenBaoが候補になります。IBM傘下の商用サポートやエンタープライズ機能を前提に据えるならVaultです。BSL 1.1の条件が自社の利用形態に抵触しないかを、要件定義の段階で確認したうえで決めるのが安全です。

Vaultの起動時に必要なアンシールとは何ですか？

Vaultは起動直後、内部データを封印（Seal）した状態にあり、マスターキーを復元しないとシークレットを扱えません。この封印を解く操作がアンシールです。既定ではShamirの秘密分散で分割したキーをしきい値の数だけ集めて解きますが、本番ではクラウドのKMSやHSMにマスターキーの保護を委ねる自動アンシールを使い、再起動時も止まらないようにします。

小規模なシステムにHashiCorp Vaultは過剰ですか？

扱う機密が少数の静的な値だけで、単一クラウドで完結するなら過剰になりがちです。Vaultは高可用性やアンシールを自前で設計・運用する前提があるため、その体制を用意できない小規模構成では、クラウドの標準的なシークレット管理機能で足りることが多いでしょう。動的シークレットや複数環境の横断管理といった要件が出てきた段階で導入を検討するのが現実的です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る