Onboarding Guide
Vaultとは

ユースケース

Vaultの実際の活用シーン
最終更新: 2026/4/13

ユースケース

Vaultは、様々なシナリオでシークレット管理とデータ保護を実現します。ここでは、代表的なユースケースをご紹介します。

1. アプリケーション設定の一元管理

課題

従来の方法では、アプリケーションの設定ファイルに機密情報が含まれていました。

# config.yml（悪い例）
database:
  host: db.example.com
  username: admin
  password: supersecret123  # ハードコーディング
api:
  key: sk_live_abc123xyz    # バージョン管理にコミットされる

問題点:

  • 設定ファイルがバージョン管理システムにコミットされる
  • 環境ごとに設定ファイルを管理する必要がある
  • パスワード変更時にすべての環境で更新が必要

Vaultによる解決

# Vaultにシークレットを保存
vault kv put secret/myapp/config \
  db_host=db.example.com \
  db_username=admin \
  db_password=supersecret123 \
  api_key=sk_live_abc123xyz

# アプリケーションから取得
vault kv get -format=json secret/myapp/config

アプリケーションコード例（Python）:

import hvac

# Vaultクライアントの初期化
client = hvac.Client(url='http://127.0.0.1:8200', token=os.environ['VAULT_TOKEN'])

# シークレットの取得
secret = client.secrets.kv.v2.read_secret_version(path='myapp/config')
db_password = secret['data']['data']['db_password']
api_key = secret['data']['data']['api_key']

# データベース接続
db = connect(
    host=secret['data']['data']['db_host'],
    username=secret['data']['data']['db_username'],
    password=db_password
)

メリット:

  • 設定ファイルに機密情報を含めない
  • 一元管理による更新の容易さ
  • アクセス制御と監査ログ

関連ドキュメント:

公式ドキュメント:

2. データベース認証情報の動的生成

課題

従来の方法では、固定のデータベース認証情報を使用していました。

アプリケーション → 固定のユーザー名/パスワード → データベース

問題点:

  • 認証情報が長期間有効
  • 漏洩時の影響が大きい
  • ローテーションが困難

Vaultによる解決

# データベースシークレットエンジンの設定
vault secrets enable database

vault write database/config/my-postgresql-database \
  plugin_name=postgresql-database-plugin \
  allowed_roles="my-role" \
  connection_url="postgresql://{{username}}:{{password}}@postgres:5432/mydb" \
  username="vault" \
  password="vault-password"

# ロールの作成
vault write database/roles/my-role \
  db_name=my-postgresql-database \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
    GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# 動的な認証情報の生成
vault read database/creds/my-role

Key                Value
---                -----
lease_id           database/creds/my-role/abc123
lease_duration     1h
lease_renewable    true
password           A1a-BbC2cD3d
username           v-token-my-role-x4xd9n8ut92dxv93kd9j

フロー:

1. アプリケーション → Vault: 認証情報をリクエスト
2. Vault → データベース: 一時的なユーザーを作成
3. Vault → アプリケーション: 認証情報を返却（有効期限1時間）
4. アプリケーション → データベース: 一時的な認証情報で接続
5. 1時間後 → Vault: 自動的にユーザーを削除

メリット:

  • 短期間の認証情報（デフォルト1時間）
  • 自動的なローテーション
  • 漏洩時の影響を最小化

関連ドキュメント:

公式ドキュメント:

3. マイクロサービス間の認証

課題

マイクロサービスアーキテクチャでは、サービス間の認証が複雑になります。

問題点:

  • 各サービスが独自の認証情報を管理
  • サービスの追加・削除時の管理が煩雑
  • 認証情報の配布が困難

Vaultによる解決

AppRoleを使用した認証:

# AppRoleの有効化
vault auth enable approle

# ロールの作成
vault write auth/approle/role/service-a \
  token_policies="service-a-policy" \
  token_ttl=1h \
  token_max_ttl=4h

# Role IDの取得（サービスに埋め込む）
vault read auth/approle/role/service-a/role-id

# Secret IDの生成（デプロイ時に動的に生成）
vault write -f auth/approle/role/service-a/secret-id

サービスAのコード例:

import hvac

# AppRoleで認証
client = hvac.Client(url='http://vault:8200')
client.auth.approle.login(
    role_id='service-a-role-id',
    secret_id='service-a-secret-id'
)

# サービスBのAPIキーを取得
secret = client.secrets.kv.v2.read_secret_version(path='service-b/api-key')
api_key = secret['data']['data']['key']

# サービスBを呼び出し
response = requests.get(
    'http://service-b/api/data',
    headers={'Authorization': f'Bearer {api_key}'}
)

メリット:

  • サービスごとの細かいアクセス制御
  • 認証情報の自動ローテーション
  • 監査ログによる追跡

関連ドキュメント:

  • AppRole - AppRole認証方法の詳細

公式ドキュメント:

4. クラウド環境での認証情報管理

AWS環境でのユースケース

課題: AWSのアクセスキーを安全に管理したい

Vaultによる解決:

# AWSシークレットエンジンの有効化
vault secrets enable aws

# AWS認証情報の設定
vault write aws/config/root \
  access_key=AKIAIOSFODNN7EXAMPLE \
  secret_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  region=ap-northeast-1

# ロールの作成
vault write aws/roles/my-role \
  credential_type=iam_user \
  policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}
EOF

# 動的なAWS認証情報の生成
vault read aws/creds/my-role

Key                Value
---                -----
lease_id           aws/creds/my-role/abc123
lease_duration     1h
access_key         AKIAI44QH8DHBEXAMPLE
secret_key         je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

Kubernetes環境でのユースケース

課題: Kubernetes上のPodがVaultにアクセスする

Vaultによる解決:

# Kubernetes認証の有効化
vault auth enable kubernetes

# Kubernetes認証の設定
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  token_reviewer_jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

# ロールの作成
vault write auth/kubernetes/role/myapp \
  bound_service_account_names=myapp \
  bound_service_account_namespaces=default \
  policies=myapp-policy \
  ttl=1h

Pod内での認証:

# ServiceAccountのJWTトークンを使用して認証
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
VAULT_TOKEN=$(curl -s --request POST \
  --data '{"jwt": "'"$KUBE_TOKEN"'", "role": "myapp"}' \
  http://vault:8200/v1/auth/kubernetes/login | jq -r '.auth.client_token')

メリット:

  • Kubernetes ServiceAccountとの統合
  • Podごとの細かいアクセス制御
  • シークレットの自動注入

関連ドキュメント:

公式ドキュメント:

5. データ暗号化サービス

課題

アプリケーションで機密データを暗号化したいが、暗号化キーの管理が困難。

問題点:

  • 暗号化キーをアプリケーションに埋め込む
  • キーローテーションが困難
  • 暗号化処理の実装が複雑

Vaultによる解決

# Transitシークレットエンジンの有効化
vault secrets enable transit

# 暗号化キーの作成
vault write -f transit/keys/my-key

# データの暗号化
vault write transit/encrypt/my-key \
  plaintext=$(echo "sensitive data" | base64)

Key           Value
---           -----
ciphertext    vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==

# データの復号化
vault write transit/decrypt/my-key \
  ciphertext=vault:v1:8SDd3WHDOjf7mq69CyCqYjBXAiQQAVZRkFM13ok481zoCmHnSeDX9vyf7w==

Key          Value
---          -----
plaintext    c2Vuc2l0aXZlIGRhdGE=

アプリケーションコード例:

import hvac
import base64

client = hvac.Client(url='http://vault:8200', token=os.environ['VAULT_TOKEN'])

# データの暗号化
plaintext = "sensitive data"
encrypt_response = client.secrets.transit.encrypt_data(
    name='my-key',
    plaintext=base64.b64encode(plaintext.encode()).decode()
)
ciphertext = encrypt_response['data']['ciphertext']

# データベースに暗号化されたデータを保存
db.save(ciphertext)

# データの復号化
decrypt_response = client.secrets.transit.decrypt_data(
    name='my-key',
    ciphertext=ciphertext
)
plaintext = base64.b64decode(decrypt_response['data']['plaintext']).decode()

メリット:

  • 暗号化キーをVaultで一元管理
  • キーローテーションが容易
  • アプリケーションは暗号化処理を意識しない

関連ドキュメント:

公式ドキュメント:

6. PKI（公開鍵基盤）の管理

課題

TLS/SSL証明書の発行と管理が煩雑。

問題点:

  • 証明書の手動発行
  • 有効期限の管理
  • 証明書の配布

Vaultによる解決

# PKIシークレットエンジンの有効化
vault secrets enable pki

# ルートCAの生成
vault write pki/root/generate/internal \
  common_name="example.com" \
  ttl=87600h

# 中間CAの設定
vault secrets enable -path=pki_int pki

vault write pki_int/intermediate/generate/internal \
  common_name="example.com Intermediate Authority"

# ロールの作成
vault write pki_int/roles/example-dot-com \
  allowed_domains="example.com" \
  allow_subdomains=true \
  max_ttl="720h"

# 証明書の発行
vault write pki_int/issue/example-dot-com \
  common_name="test.example.com" \
  ttl="24h"

Key                 Value
---                 -----
certificate         -----BEGIN CERTIFICATE-----...
issuing_ca          -----BEGIN CERTIFICATE-----...
private_key         -----BEGIN RSA PRIVATE KEY-----...
serial_number       39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58

メリット:

  • 証明書の自動発行
  • 短期間の証明書（24時間など）
  • 自動的な更新

関連ドキュメント:

公式ドキュメント:

7. CI/CDパイプラインでのシークレット管理

課題

CI/CDパイプラインで使用するシークレットを安全に管理したい。

問題点:

  • CI/CD環境変数にシークレットを保存
  • パイプライン設定ファイルにシークレットが含まれる
  • シークレットの更新が困難

Vaultによる解決

GitHub Actionsの例:

# .github/workflows/deploy.yml
name: Deploy
on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      # Vaultから認証
      - name: Import Secrets
        uses: hashicorp/vault-action@v2
        with:
          url: https://vault.example.com
          method: approle
          roleId: ${{ secrets.VAULT_ROLE_ID }}
          secretId: ${{ secrets.VAULT_SECRET_ID }}
          secrets: |
            secret/data/myapp/deploy aws_access_key | AWS_ACCESS_KEY_ID ;
            secret/data/myapp/deploy aws_secret_key | AWS_SECRET_ACCESS_KEY ;
            secret/data/myapp/deploy db_password | DB_PASSWORD
      
      # デプロイ処理
      - name: Deploy
        run: |
          ./deploy.sh
        env:
          AWS_ACCESS_KEY_ID: ${{ env.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ env.AWS_SECRET_ACCESS_KEY }}
          DB_PASSWORD: ${{ env.DB_PASSWORD }}

メリット:

  • シークレットをCI/CD設定から分離
  • 一元管理による更新の容易さ
  • 監査ログによる追跡

関連ドキュメント:

公式ドキュメント:

8. コンプライアンス対応

課題

規制要件（GDPR、PCI DSS、HIPAAなど）への対応。

要件:

  • すべてのアクセスを記録
  • 機密データの暗号化
  • アクセス制御の実装

Vaultによる解決

監査ログの有効化:

vault audit enable file file_path=/var/log/vault/audit.log

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

# PCI DSS対応ポリシー
path "secret/data/payment/*" {
  capabilities = ["read"]
  
  # 特定のIPアドレスからのみアクセス可能
  allowed_parameters = {
    "cidr_list" = ["10.0.0.0/8"]
  }
}

データの暗号化:

# Transitエンジンで機密データを暗号化
vault write transit/encrypt/pii-key \
  plaintext=$(echo "personal data" | base64)

メリット:

  • 完全な監査証跡
  • 暗号化の一元管理
  • 細かいアクセス制御

関連ドキュメント:

公式ドキュメント:

次のステップ

ユースケースを理解したら、インストールでVaultの導入を始めましょう。

ユースケースの選択すべてのユースケースを一度に実装する必要はありません。まずは自社の要件に最も適したユースケースから始めることをお勧めします。
© 2026 IBM Corporation. Licensed under CC BY 4.0.