※本記事にはプロモーション（広告）を含みます。

HashiCorp Vaultを導入する際は、まずシークレットエンジンの種類と認証方式の組み合わせを先に設計してから構築作業に入ってください。静的なパスワード管理ツールとして使い始めると、動的シークレットや詳細なポリシー制御といった本来の強みを活かせないまま運用が固定化してしまいます。この記事では、KVエンジンの基本操作からDynamic Secretsによる権限最小化、可用性設計までを実践的な手順とともに整理します。

目次

  • Vault導入前に決めるべき設計方針
  • KVシークレットエンジンの実践手順
  • Dynamic Secretsで権限を最小化する
  • Vaultの可用性と運用設計
  • よくある質問
  • まとめ

Vault導入前に決めるべき設計方針

Vaultは単一の暗号化ストレージではなく、複数のシークレットエンジンと認証方式を組み合わせるプラットフォームです。導入初期にこの組み合わせを決めておかないと、後からポリシーを作り直す作業が発生し、既存のクライアントに影響が出ます。設計段階でチームの権限モデルとインフラ構成を照らし合わせておく必要があります。

シークレットエンジンの選定

Vaultには静的な値をそのまま保管するKV(Key-Value)エンジンと、外部システムへの認証情報をリクエスト時に都度発行するDynamic Secretsエンジンがあります。APIキーやTLS証明書のように値そのものを保管したい場合はKVエンジン、データベースやクラウドの一時クレデンシャルはDynamic Secrets向けのエンジン(Database、AWS、Azureなど)を選びます。両方を併用する構成が一般的で、静的値と動的値を同じマウントパスに混在させないことが運用上のポイントです。

認証方式の選び方

Vaultへのログイン手段はToken認証を基本としつつ、AppRole、Kubernetes、LDAPなど複数のAuth Methodを目的別に使い分けます。CI/CDパイプラインからのアクセスにはAppRole、Kubernetes上のPodからのアクセスにはKubernetes Auth Methodを割り当てるのが一般的な構成です。人間のオペレーターにはLDAPやOIDCを紐づけ、個人アカウントとの対応関係を残すことで監査時の追跡がしやすくなります。以下は代表的な組み合わせの比較です。

用途推奨シークレットエンジン推奨認証方式特徴
アプリの設定値・APIキーKV v2AppRoleバージョン管理と差分確認が可能
データベース接続情報Database Secrets EngineKubernetes Auth接続の都度クレデンシャルを発行
クラウドIAMロールAWS Secrets EngineAWS Auth一時認証情報で権限を限定
運用担当者の直接操作KV v2 / PKILDAP・OIDC個人アカウントと紐づけて監査

この表はあくまで代表的な組み合わせの目安であり、実際の選定は自社のインフラ構成やコンプライアンス要件に合わせて調整してください。バージョンによって機能や設定パラメータが変わるため、最新の挙動はHashiCorpの公式ドキュメントで確認する運用を前提にしてください。

KVシークレットエンジンの実践手順

KVエンジンはVaultの中でもっとも利用頻度が高い機能です。バージョン1とバージョン2があり、バージョン2ではシークレットの変更履歴を保持できる点が大きな違いになります。新規に導入するなら基本的にバージョン2を選ぶ構成が主流です。

有効化とバージョン管理

KV v2エンジンはvault secrets enableコマンドでマウントし、任意のパスに配置します。値を書き込むとバージョン番号が自動的に付与され、過去のバージョンをvault kv getのコマンドでバージョン指定して取得できます。誤った値を上書きしてしまった場合でも、直前のバージョンにロールバックする操作が用意されているため、本番環境での事故対応がしやすくなります。ただし保持するバージョン数には上限設定があり、デフォルト値のまま長期間運用すると古い履歴から自動的に削除されるので、監査要件がある場合は保持数の設定を見直してください。

ポリシーによるアクセス制御

VaultのポリシーはHCL形式で記述し、パスごとに読み取り・書き込み・削除といった権限を細かく指定します。同じKVマウントの中でも、アプリケーションAが参照できるパスとアプリケーションBが参照できるパスを分離しておくことで、片方の認証情報が漏洩した場合の被害範囲を限定できます。ワイルドカードを使ったパス指定は柔軟ですが、意図しない範囲まで権限を付与してしまうリスクがあるため、まず最小限のパスで許可し、必要に応じて範囲を広げる順番で設定するほうが安全です。

  • 読み取り専用ポリシー: アプリケーションの通常稼働時に付与
  • 書き込み権限付きポリシー: デプロイパイプラインなど限定された主体のみに付与
  • rootポリシー: 初期セットアップ後は日常運用で使用しない

Dynamic Secretsで権限を最小化する

静的なパスワードをKVに保管する運用は、値が漏洩した際の影響が長期化しやすいという弱点を抱えています。Dynamic Secretsは、リクエストのたびに一時的な認証情報を生成し、有効期限(TTL)が切れると自動的に失効させる仕組みで、この弱点を補います。

DBエンジンの仕組み

Database Secrets EngineをMySQLやPostgreSQLに接続すると、Vaultはあらかじめ登録したロールに基づいてデータベース上に一時ユーザーを作成し、その認証情報をクライアントへ返します。アプリケーションは起動時にVault経由で接続情報を取得するだけでよく、パスワードをソースコードや設定ファイルに書く必要がなくなります。TTLが切れるとVaultはデータベース上のユーザーも自動的に削除するため、使い終わったクレデンシャルが残り続ける状態を防げます。

リース失効の運用

Dynamic Secretsで発行された認証情報にはリース(lease)という管理単位が付与され、TTLの延長(renew)や強制失効(revoke)をVault側から制御できます。長時間動作するバッチ処理では、処理の開始時に取得したリースが途中で失効しないよう、TTLをジョブの想定実行時間より長く設定するか、定期的にrenewを呼び出す実装が必要です。逆に、セキュリティインシデントが疑われる場合は、該当ロールに紐づくリースを一括でrevokeすることで、影響範囲を即座に遮断できます。この即時遮断ができる点が、静的シークレットにはないDynamic Secretsの実務上の利点です。

Vaultの可用性と運用設計

Vaultは起動直後、暗号化されたストレージを復号するためのマスターキーを持たない「Seal」状態にあります。この状態を解除する操作と、日々の運用でログをどう扱うかが、本番運用における設計の中心になります。

Shamirのシークレット分割とUnseal

Vaultはマスターキーをそのまま一人の担当者に渡すのではなく、Shamir’s Secret Sharingというアルゴリズムで複数のキーシェアに分割します。初期化時に設定した閾値(例えば5分割中3つ)のシェアが揃わないとUnsealできない仕組みのため、単独の管理者が勝手にVaultを開封することはできません。クラウド環境ではAWS KMSやAzure Key VaultなどのAuto Unseal機能を使い、シェアの手動入力を省略する構成も広く使われています。手動でシェアを管理する場合は、キーシェアの保管場所を分散し、誰が何個を保持しているかを台帳で管理しておく必要があります。

監査ログとバックアップ

Vaultの監査ログ(Audit Device)を有効にすると、誰がどのパスにいつアクセスしたかがJSON形式で記録されます。監査ログにはトークンなどの機密情報がハッシュ化された状態で残るため、ログそのものを外部に転送しても値が漏れる心配はありませんが、転送先のアクセス権限は別途絞り込んでおいてください。バックアップについては、Vault自体のストレージ(Raftのスナップショットなど)を定期的に取得するだけでなく、Unsealキーやルートトークンの再発行手順もあわせて文書化しておくことが、障害発生時の復旧時間を左右します。

運用項目目安の頻度備考
Raftスナップショット取得1日1回程度ストレージ容量に応じて調整
ポリシーの棚卸し四半期に1回程度不要になったパス権限を削除
監査ログの保管期間確認半年に1回程度社内のログ保持ポリシーに合わせる

よくある質問

Q1. Vaultの導入コストはどのくらいかかりますか

Vaultにはオープンソース版とHashiCorp Cloud Platform上のマネージドサービスがあり、構成によって必要なインフラ費用が変わります。具体的な料金体系は公式サイトの最新情報を確認してから見積もりを行ってください。

Q2. KVエンジンとDatabase Secrets Engineはどちらから導入すべきですか

まずKV v2エンジンでVaultの操作に慣れ、ポリシー設計の基本を押さえてからDatabase Secrets Engineのような動的エンジンへ範囲を広げる進め方が扱いやすい構成です。

Q3. Unsealキーを紛失した場合はどうなりますか

設定した閾値を下回るシェアしか揃わない場合、Vaultは復号できずデータへのアクセスができなくなります。Auto Unsealの利用や、キーシェアの保管場所を複数拠点に分散する運用があらかじめ必要です。

Q4. トークンの有効期限はどう設定すればよいですか

用途ごとにTTLを分け、CI/CDのような短時間で完結する処理には短いTTLを、常駐アプリケーションにはrenewを前提とした運用を設定するのが一般的な考え方です。値の絶対的な正解は環境によって異なるため、まず短めのTTLから始めて運用しながら調整する進め方が安全です。

Q5. Vaultのバージョンアップはどのように進めればよいですか

マイナーバージョンでも設定項目の非推奨化やAPIの変更が入ることがあるため、公式のアップグレードガイドとリリースノートを確認したうえで、ステージング環境での動作確認を経てから本番へ適用する手順を踏んでください。

まとめ

HashiCorp Vaultは、KVエンジンによる静的シークレットの一元管理と、Dynamic Secretsによる権限の時限化を組み合わせることで、認証情報の漏洩リスクを構造的に下げられる仕組みです。導入時にはシークレットエンジンと認証方式の対応関係を先に設計し、KV v2でポリシーの基本を押さえたあと、データベースやクラウドの動的エンジンへ段階的に範囲を広げる進め方が扱いやすくなります。運用フェーズではUnsealの手順とキーシェアの管理体制、監査ログの保管方針を文書化しておくことで、障害時にも落ち着いて復旧作業を進められます。セキュリティ設定の最終判断とバージョンごとの挙動確認は、公式ドキュメントを参照しながら自己責任で実施してください。

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら

職場のIT課題、どこから手をつけるか整理してみませんか？

運営者の無料IT診断では、簡単な質問に答えるだけで社内のIT活用状況を整理し、改善の方向性のヒントをお返しします。売り込みはありません。

無料IT診断を受けてみる

Googleフォームが開きます ／ 無料 ／ 中小企業のIT担当者・経営者向け

ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営