LASSIC Media らしくメディア
HashiCorp Vault入門｜シークレット管理
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
APIキーやデータベースの接続情報、証明書の秘密鍵――こうしたシークレットが、設定ファイルやソースコード、担当者のメモに散らばっていないでしょうか。システムの数が増えるほど所在の把握が難しくなり、退職者のアカウント情報が残ったまま、一つの認証情報を複数システムで使い回しているといった状態は、監査や事故対応の場面で大きな負担になります。
こうした課題への選択肢の一つが、HashiCorpが開発するHashiCorp Vaultです。APIキーやDB認証情報、証明書などのシークレットを一元的に保管・管理し、必要に応じて動的に発行・失効できる仕組みを備えたプラットフォームで、セルフホスト構築のほか、HashiCorpが運用するHCP Vaultとしても提供されています*1。本記事では、Vaultの主な機能と、クラウド事業者のKMS（鍵管理サービス）との違い、導入手順、認証・ポリシー設計の勘所、委託の判断軸を、法人のIT基盤・セキュリティ部門向けに整理します。
なお本記事は、HashiCorp Vaultという製品そのものの特性と導入手順に主題を絞ります。クラウド事業者が単体で提供するマネージドの鍵管理サービス（KMS）の解説は別記事のテーマとしており、本記事では両者の役割の違いを整理する範囲にとどめる方針です。
この記事のポイント
- HashiCorp Vaultは、APIキーやDB認証情報、証明書などのシークレットを一元管理し、シークレットエンジンを介して動的に発行・失効できるプラットフォームです。
- クラウドKMSがマネージドな鍵管理サービスであるのに対し、Vaultはマルチクラウド／オンプレミスを横断してシークレットを扱える点や、動的シークレットの発行機能に特徴があります。
- セルフホストとHCP Vaultのどちらを選ぶか、内製と外部委託のどちらで進めるかは、運用体制と機密度を踏まえて判断する必要があります。
目次
HashiCorp Vaultとは：シークレット管理を一元化するプラットフォーム
HashiCorp Vaultは、APIキーやデータベースの接続情報、証明書、トークンといった機密情報（シークレット）を一元的に保管し、アクセス制御・払い出し・失効までを一貫して扱うプラットフォームです*1。設定ファイルやコード中に平文で埋め込まれがちなシークレットをVaultに集約し、アプリケーションや担当者はVault経由でのみ必要な情報を取得する形にすることで、シークレットの所在と利用状況を把握しやすくする狙いがあります。
提供形態：セルフホストとHCP Vault
提供形態は大きく二つに分かれます。一つは、Vaultのソフトウェアを自社のサーバーやコンテナ基盤に構築するセルフホストです。もう一つは、HashiCorpが運用するクラウドサービスであるHCP Vaultで、インフラの構築・保守をHashiCorp側に委ねる形態になります*2。なお、Vaultは執筆時点でBusiness Source License（BSL）という形態のライセンスを採用しており、単純な完全オープンソースではない点に留意が必要です*3。ライセンス条件・料金体系・対応バージョンは今後変更され得るため、正式に採用を検討する際は公式サイト・公式ドキュメントで最新情報を確認することをおすすめします。
Vaultの主な機能：シークレットエンジン・動的シークレット・PKI・認証・監査
Vaultの中核にあるのが「シークレットエンジン」という仕組みです。用途ごとにエンジンを有効化することで、静的なシークレットの保管だけでなく、動的シークレットの発行や証明書の発行といった機能を使い分けられます*1。代表的な機能を整理すると、次のとおりです。
| 機能カテゴリ | できること |
|---|---|
| KVシークレットエンジン | APIキーやパスワードなど静的なシークレットをキー・バリュー形式で保管する |
| データベースシークレットエンジン | DBへの接続情報をその都度動的に発行し、期限つきで自動失効させる |
| PKIシークレットエンジン | Vaultを認証局として、TLS証明書などの発行・更新・失効を行う |
| クラウドシークレットエンジン | AWS／Azure／GCPなどの一時的なIAM認証情報を動的に発行する |
| 認証方式（Auth Methods） | AppRole・Kubernetes認証・LDAP・OIDCなど、人・アプリ双方の認証を扱う |
| 監査ログ（Audit Devices） | Vaultへのすべてのリクエスト・レスポンスを監査ログとして記録する |
これらを支える中心概念が「動的シークレット」と「リース」です。Vaultは要求のたびにDB認証情報やクラウドの一時credentialを新規発行し、それぞれに有効期限（リース）を設定します。リースは自動失効するほか、不審な利用が疑われる場合は管理者が明示的に取り消す（revoke）ことも可能です*1。固定パスワードを共有し続けるのではなく、都度発行・都度失効を前提にする点が、静的なシークレット管理との大きな違いです。
クラウドKMSとVaultの違い：マネージド鍵管理と横断的なシークレット管理
Vaultの導入を検討する際、「クラウド事業者のKMS（鍵管理サービス）と何が違うのか」という疑問を持たれることがよくあります。両者は重なる部分もありますが、対象範囲と発行の考え方が異なります。
| 観点 | クラウドKMS（マネージド鍵管理） | HashiCorp Vault |
|---|---|---|
| 主な対象 | 暗号鍵の生成・保管・ローテーション | APIキー・DB認証情報・証明書など多様なシークレット全般 |
| 対応範囲 | 基本的に契約しているクラウド事業者の範囲内 | マルチクラウド・オンプレミスを横断して統一的に扱える |
| 発行の考え方 | 鍵そのものは基本的に長期利用を前提に管理する | シークレットエンジンにより動的シークレットを都度発行・失効できる |
| 運用形態 | クラウド事業者のマネージドサービスとして提供される | セルフホストでの自前運用、またはHCP Vaultを選択できる |
実務上、両者は排他的な関係とは限りません。Vaultをセルフホストで構築した場合、起動直後は「シール（封印）」状態にあり、稼働には複数の鍵シェアによるアンシール操作が必要ですが、この鍵管理をクラウドKMSに委ねる「自動アンシール」という構成も用意されています*1。クラウドKMSを鍵の保管に使い、日々のシークレット発行・失効はVaultが担うという組み合わせも現実的な選択肢です。
導入を始めるステップ：セルフホストとHCP Vaultの選択
Vaultの導入は、大まかに次のような流れで進めます。
ステップ1〜3：棚卸しから構築・シークレットエンジン設定まで
最初に着手するのは、現状どこにどのようなシークレットが存在するかの棚卸しです。設定ファイル、環境変数、担当者の手元に置かれた認証情報などを洗い出し、優先度の高いものから移行対象を定めます。次に、セルフホストで自社構築するか、HashiCorpが運用するHCP Vaultを利用するかを、運用体制やデータの機密度を踏まえて選択します。方針が固まったら、KVシークレットエンジンやデータベースシークレットエンジン、PKIシークレットエンジンなど、必要なエンジンを有効化していく流れです。
ステップ4〜6：認証・ポリシー設計から監査・運用まで
エンジンの設定が済んだら、アプリケーションやCI/CDが利用するAppRole認証、担当者が利用するLDAP・OIDC認証など、認証方式を選定し、HCLで記述するポリシーにより最小権限のアクセス制御を設計します。続いて、対象のアプリケーションをVaultと連携させ、動的シークレットを払い出して利用する構成に切り替えます。稼働後は、監査ログの記録・レビュー体制と、リースの更新・失効の運用ルールを整え、継続的に見直していく段階に入ります*1。
認証・ポリシー設計とセキュリティの勘所
Vaultを安全に運用できるかどうかは、機能そのものより認証・ポリシー設計の質に左右されます。押さえておきたい主な論点は次のとおりです。
- 認証方式の使い分け――CI/CDやアプリケーションにはAppRole認証やKubernetes認証、人にはLDAP・OIDCなど、用途に応じて選ぶ必要があります
- 最小権限のポリシー設計――HCLで記述するポリシーはパスごとに権限を細かく定義できるため、root権限を常用せず必要最小限に絞り込むことが重要です
- リースの管理と失効運用――動的シークレットには有効期限があり、更新（renew）や取り消し（revoke）の運用ルールを決めておかないと形骸化しやすくなります
- シール・アンシール鍵の管理――Shamir方式の鍵シェアの保管方法、あるいはクラウドKMSによる自動アンシールの採否は、初期段階で決めておくべき論点です*1
- 監査ログの保管とレビュー体制――誰がいつどのシークレットにアクセスしたかを追跡できるようにし、レビューする担当・頻度を決めておくことが望ましいです
これらは導入初期の設計段階で決めておくほど、後の運用がぶれにくくなる項目です。特にポリシー設計とリース運用は構築しただけでは自動的に整わないため、業務フローとあわせて設計することが欠かせません。
導入と委託の判断軸
Vaultは構築自体のハードルは高すぎないものの、認証・ポリシー設計や運用を軌道に乗せるには相応の知見が必要です。内製と委託のどちらが適するかは、次の観点で整理できます。
| 観点 | 内製が向くケース | 委託を検討したいケース |
|---|---|---|
| セルフホスト運用体制 | 可用性設計やバックアップ、アップグレードを自社で保守できる | 運用負荷を負いきれない、またはHCP Vaultの設定に不安がある |
| ポリシー設計の経験 | 最小権限のHCLポリシーやAppRole設計を描ける担当者がいる | どこまで権限を絞るべきか設計自体に迷いがある |
| 既存シークレットの移行規模 | 対象システムが限られ、段階的に移行できる | 対象システムが多く、棚卸しから移行計画まで一括で整理したい |
| 監査・コンプライアンス要件 | 自社基準での監査ログ運用を整えられる | 業界基準や契約上の要件が厳格で専門知識が必要 |
まずHCP Vaultで小さく試し、ノウハウが蓄積された段階でセルフホストへ移行する、あるいは棚卸しと設計だけを外部パートナーに依頼し運用は自社で回すといった段階的な進め方も現実的です。LASSICのような元請会社は、こうした組み合わせについても中立的な立場でご相談に応じられます。
導入でつまずきやすい点
Vaultは機能が豊富である一方、導入・運用の過程ではいくつかつまずきやすいパターンが見られます。
- KVエンジンだけにあらゆるシークレットを詰め込んでしまい、動的シークレットやPKIなど他のエンジンを活用できていない――用途に応じたエンジンの使い分けを検討する必要があります
- root token（初期の最上位権限）を運用でも常用してしまい、最小権限のポリシー設計が形骸化する――日常運用では権限を絞ったポリシーとトークンに切り替えることが欠かせません
- シール・アンシール鍵の管理が属人化し、鍵を持つ担当者が不在だと再起動できなくなる――鍵の保管方法と手順をあらかじめ複数人で共有しておく必要があります
- リースの更新・失効運用を放置し、期限切れのシークレットでアプリケーションが突然エラーになる――更新・失効の運用ルールを事前に定めておくとよいでしょう
- セルフホストの可用性設計・バックアップ体制を後回しにしてしまう――本番導入前に構成と復旧手順を整理しておくことが望ましいです
いずれも、Vault自体の機能不足というより導入前の準備不足が原因になりやすい点です。構築前に、対象範囲・認証方式・ポリシー・鍵管理・運用担当を一通り決めておくことが、遠回りを避ける近道になります。
まとめ：Vaultはシークレットを一元管理し動的に発行・失効する基盤
本記事では、HashiCorp Vaultを使ったシークレット管理の導入について、主な機能からクラウドKMSとの役割の違い、導入手順、認証・ポリシー設計の勘所、委託の判断軸までを整理しました。Vaultは、シークレットエンジンを軸に静的なシークレットの保管と動的シークレットの発行・失効をまとめて扱えるプラットフォームで、セルフホストとHCP Vaultのどちらでも導入できる柔軟さが特徴です。
一方で、クラウドKMSとは対象範囲や発行の考え方が異なり、マルチクラウド・オンプレミスを横断した管理や動的シークレットの活用を検討する場合に選択肢になります。認証・ポリシー設計や運用体制を踏まえて内製と委託を使い分ける判断軸を持つことが、シークレット管理を継続的に活用する土台になります。
よくある質問
HashiCorp Vaultは無料で使えますか。
Vaultは執筆時点でBusiness Source License（BSL）という形態のライセンスを採用しており、単純な完全オープンソースではありません*3。利用条件・料金体系は変更され得るため、正式に採用を検討する際は公式サイトの最新情報を確認することをおすすめします。
セルフホストとHCP Vaultは、どちらを選ぶべきですか。
データの機密度が高く自社管理下で運用したい場合や既存インフラとの統合が必要な場合はセルフホスト、構築・保守の負担を軽くしたい場合はHCP Vaultが検討しやすいでしょう。運用体制と機密度の両面から判断することが望ましいです。
クラウドKMSとVaultはどちらを選ぶべきですか。
クラウド事業者の範囲内で暗号鍵を管理するだけであればクラウドKMSで足りる場合が多いですが、マルチクラウド・オンプレミスを横断してシークレットを一元管理したい場合や、DB認証情報・クラウドIAM情報を動的に発行・失効したい場合はVaultが選択肢になります。両者を組み合わせて使うことも可能です。
動的シークレットとは何ですか。
Vaultが要求のたびに新規発行する、有効期限（リース）つきのシークレットです。DB認証情報やクラウドの一時credentialなどが該当し、期限切れで自動失効するほか、管理者が明示的に取り消す（revoke）こともできます*1。固定的なパスワードを共有し続ける運用に比べ、漏えい時の影響範囲を抑えやすいとされています。
認証方式はどれを選べばよいですか。
アプリケーションやCI/CDにはAppRole認証やKubernetes認証、人が利用する場合はLDAP・OIDCなど、利用主体の性質に応じて選ぶのが基本です*1。複数の認証方式を併用し、それぞれにポリシーを紐づけて最小権限を徹底する構成が一般的です。
内製と外部委託は、どちらから始めるべきですか。
最小権限のポリシー設計やAppRole設計を描ける担当者がいる場合は、内製から小さく試すのも一つの方法です。対象システムが多い、あるいは監査・コンプライアンス要件が厳格な場合は、外部パートナーへの相談も選択肢に入れるとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・基盤構築のご相談はLASSICへ
元請（プライムベンダー）として、HashiCorp Vaultを使ったシークレット管理基盤の導入支援から、複雑な要件のシステム開発までご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：HashiCorp Vault Documentation（https://developer.hashicorp.com/vault/docs）
- *2 出典：HashiCorp公式サイト（https://www.hashicorp.com/products/vault）
- *3 出典：HashiCorp公式ブログ「HashiCorp Adopts Business Source License」（https://www.hashicorp.com/en/blog/hashicorp-adopts-business-source-license）
