secrets-vault-manager

Secrets Vault Manager

Tier: 強力 Category: エンジニアリング Domain: セキュリティ／インフラストラクチャ／DevOps

---

概要

HashiCorp Vault、クラウドネイティブのシークレットストア、またはハイブリッドアーキテクチャを運用するチーム向けの、本番環境用シークレットインフラストラクチャ管理です。このスキルでは、ポリシーの作成、認証方式の設定、自動ローテーション、動的シークレット、監査ログ、インシデント対応を扱います。

.env ファイルの管理と漏えい検出を扱う env-secrets-manager とは異なります。このスキルはインフラストラクチャ層で動作し、Vault クラスター、クラウド KMS、認証局、CI/CD へのシークレット注入を扱います。

使用する場面

• 新しい Vault クラスターの立ち上げ、またはマネージドシークレットストアへの移行
• サービス、CI ランナー、人間の運用者向けの認証方式の設計
• 認証情報（データベース、API キー、証明書）の自動ローテーションの実装
• コンプライアンス（SOC 2、ISO 27001、HIPAA）に向けたシークレットアクセスパターンの監査
• 大規模な失効が必要なシークレット漏えいへの対応
• Kubernetes ワークロードや CI/CD パイプラインへのシークレットの統合

---

HashiCorp Vault のパターン

アーキテクチャの決定事項

決定事項	推奨事項	理由
デプロイモード	Raft ストレージを使用した HA	外部依存がなく、リーダー選出機能を内蔵
自動シール解除	クラウド KMS（AWS KMS／Azure Key Vault／GCP KMS）	手動でのシール解除が不要になり、自動再起動が可能
名前空間	環境（dev/staging/prod）ごとに 1 つ	影響範囲を分離し、個別のポリシーを適用
監査デバイス	ファイル＋syslog（デュアル）	すべての監査デバイスに障害が発生すると Vault はリクエストを拒否するため、デュアル構成で停止を防止

認証方式

AppRole — サービスやバッチジョブ向けのマシン間認証です。

# Enable AppRole
path "auth/approle/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Application-specific role
vault write auth/approle/role/payment-service \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_num_uses=1 \
  secret_id_ttl=10m \
  token_policies="payment-service-read"

Kubernetes — サービスアカウントトークンを使った、Pod ネイティブの認証です。

vault write auth/kubernetes/role/api-server \
  bound_service_account_names=api-server \
  bound_service_account_namespaces=production \
  policies=api-server-secrets \
  ttl=1h

OIDC — SSO プロバイダー（Okta、Azure AD、Google Workspace）経由の人間の運用者向けアクセスです。

vault write auth/oidc/role/engineering \
  bound_audiences="vault" \
  allowed_redirect_uris="https://vault.example.com/ui/vault/auth/oidc/oidc/callback" \
  user_claim="email" \
  oidc_scopes="openid,profile,email" \
  policies="engineering-read" \
  ttl=8h

シークレットエンジン

エンジン	用途	TTL 戦略
KV v2	静的シークレット（API キー、設定）	バージョン管理、手動ローテーション
Database	動的な DB 認証情報	デフォルト 1 時間、最大 24 時間
PKI	TLS 証明書	リーフ証明書は 90 日、中間 CA は 5 年
Transit	サービスとしての暗号化	90 日ごとにキーをローテーション
SSH	署名済み SSH 証明書	対話型は 30 分、自動化は 8 時間

ポリシー設計

パス単位で細かく設定し、最小権限の原則に従います。

# payment-service-read policy
path "secret/data/production/payment/*" {
  capabilities = ["read"]
}

path "database/creds/payment-readonly" {
  capabilities = ["read"]
}

# Deny access to admin paths explicitly
path "sys/*" {
  capabilities = ["deny"]
}

ポリシーの命名規則: {service}-{access-level}（例：payment-service-read、api-gateway-admin）。

---

クラウドシークレットストアの統合

比較表

機能	AWS Secrets Manager	Azure Key Vault	GCP Secret Manager
ローテーション	Lambda に標準搭載	Functions を使ったカスタムロジック	Cloud Functions
バージョン管理	自動	手動または自動	自動
暗号化	AWS KMS（デフォルトまたは CMK）	HSM による保護	Google 管理または CMEK
アクセス制御	IAM ポリシー＋リソースポリシー	RBAC＋アクセス ポリシー	IAM バインディング
クロスリージョン	レプリケーションに対応	デフォルトで地理的冗長性あり	レプリケーションに対応
監査	CloudTrail	Azure Monitor＋Diagnostic Logs	Cloud Audit Logs
料金モデル	シークレットごと＋API 呼び出しごと	操作ごと＋キーごと	シークレットのバージョンごと＋アクセスごと

どれを選ぶか

• AWS Secrets Manager：RDS/Aurora の認証情報ローテーションを標準でサポートします。AWS を全面的に利用している場合に最適です。
• Azure Key Vault：証明書管理に強みがあります。Azure AD 統合ワークロードでは必須です。
• GCP Secret Manager：API の構成が最もシンプルです。Workload Identity を使用する GKE ネイティブのワークロードに最適です。
• HashiCorp Vault：マルチクラウド、動的シークレット、PKI、Transit 暗号化に対応します。複雑な環境やハイブリッド環境に最適です。

SDK のアクセスパターン

原則： シークレットは必ず起動時またはサイドカー経由で取得してください。イメージや設定ファイルに埋め込まないでください。

# AWS Secrets Manager pattern
import boto3, json

def get_secret(secret_name, region="us-east-1"):
    client = boto3.client("secretsmanager", region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])

# GCP Secret Manager pattern
from google.cloud import secretmanager

def get_secret(project_id, secret_id, version="latest"):
    client = secretmanager.SecretManagerServiceClient()
    name = f"projects/{project_id}/secrets/{secret_id}/versions/{version}"
    response = client.access_secret_version(request={"name": name})
    return response.payload.data.decode("UTF-8")

# Azure Key Vault pattern
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

def get_secret(vault_url, secret_name):
    credential = DefaultAzureCredential()
    client = SecretClient(vault_url=vault_url, credential=credential)
    return client.get_secret(secret_name).value

---

シークレットローテーションのワークフロー

シークレットの種類ごとのローテーション戦略

シークレットの種類	ローテーション頻度	方法	ダウンタイムのリスク
データベースのパスワード	30 日	2 アカウントの切り替え	なし（A/B ローテーション）
API キー	90 日	新しいキーを生成し、古いキーを無効化	なし（重複期間）
TLS 証明書	有効期限の 60 日前	ACME または Vault PKI	なし（グレースフルリロード）
SSH キー	90 日	Vault 署名証明書	なし（CA ベース）
サービストークン	24 時間	動的生成	なし（短命）
暗号化キー	90 日	キーのバージョン管理（再ラップ）	なし（バージョンの共存）

データベース認証情報のローテーション（2 アカウント方式）

1. 2 つのデータベースアカウント app_user_a と app_user_b が存在します
2. アプリケーションは現在 app_user_a を使用しています
3. ローテーション時に app_user_b のパスワードをローテーションし、シークレットストアを更新します
4. アプリケーションは次回の認証情報取得時に app_user_b に切り替えます
5. 猶予期間の後、app_user_a のパスワードをローテーションします
6. このサイクルを繰り返します

API キーのローテーション（重複期間）

1. プロバイダーで新しい API キーを生成します
2. 新しいキーを current としてシークレットストアに保存し、古いキーを previous に移します
3. アプリケーションをデプロイします。アプリケーションは current を読み込みます
4. すべてのインスタンスの再起動後（または TTL の期限切れ後）に previous を無効化します
5. 無効化する前に、古いキーが使用されていないことをモニタリングで確認します

---

動的シークレット

動的シークレットは必要に応じて生成され、自動的に有効期限が切れます。可能な場合は、静的な認証情報よりも動的シークレットを優先してください。

データベースの動的認証情報（Vault）

# Configure database engine
vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/app" \
  allowed_roles="app-readonly,app-readwrite" \
  username="vault_admin" \
  password="<admin-password>"

# Create role with TTL
vault write database/roles/app-readonly \
  db_name=postgres \
  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

クラウド IAM の動的認証情報

Vault は、有効期間の短い AWS IAM 認証情報、Azure サービスプリンシパルのパスワード、または GCP サービスアカウントキーを生成できます。これにより、有効期間の長いクラウド認証情報を完全に排除できます。

SSH 認証局

SSH キーの配布を、Vault 署名証明書モデルに置き換えます。

1. Vault が SSH CA として機能します
2. ユーザーやマシンは、TTL が短い（30 分）署名済み証明書をリクエストします
3. SSH サーバーは CA の公開鍵を信頼するため、authorized_keys の管理は不要です
4. 証明書は自動的に期限切れになるため、通常の運用では失効処理は不要です

---

監査ログ

ログに記録する内容

イベント	優先度	保持期間
シークレットの読み取りアクセス	高	最低 1 年
シークレットの作成／更新	高	最低 1 年
認証方式によるログイン	中	90 日
ポリシーの変更	最重要	2 年（コンプライアンス）
アクセス失敗の試行	最重要	1 年
トークンの作成／失効	中	90 日
シール／シール解除操作	最重要	無期限

異常検知のシグナル

• 新しい IP／CIDR 範囲からシークレットにアクセスした
• アクセス量が急増した（パスの通常値の 3 倍超）
• 人間向けの認証方式で営業時間外にアクセスした
• サービスがポリシーの範囲外のシークレットにアクセスした（リクエストが拒否された）
• 単一の送信元から複数回の認証に失敗した
• 通常より TTL が著しく長いトークンが作成された

コンプライアンスレポート

以下を含む定期レポートを生成します。

1. アクセスインベントリ — どの ID が、いつ、どのシークレットにアクセスしたか
2. ローテーションのコンプライアンス — ローテーション期限を過ぎたシークレット
3. ポリシーのドリフト — 前回のレビュー以降に変更されたポリシー
4. 孤立したシークレット — 最近のアクセスがないシークレット（90 日超）

audit_log_analyzer.py を使用して、Vault またはクラウドの監査ログを解析し、これらのシグナルを検出します。

---

緊急時の手順

シークレット漏えいへの対応（直ちに実施）

目標時間：検知から 15 分以内に封じ込めます。

1. 範囲を特定する — どのシークレットが、どこで（リポジトリ、ログ、エラーメッセージ、第三者）漏えいしたか
2. 直ちに失効させる — 漏えいした認証情報を、発行元（プロバイダー API、Vault、クラウド SM）でローテーションします
3. トークンを無効化する — 漏えいしたシークレットにアクセスしたすべての Vault トークンを失効させます
4. 影響範囲を監査する — 露出期間中に漏えいしたシークレットが使用されたか、監査ログを照会します
5. 関係者に通知する — セキュリティチーム、影響を受けたサービスの所有者、コンプライアンス担当（個人情報または規制対象データの場合）
6. 事後検証を行う — 根本原因を記録し、再発を防ぐために管理策を更新します

Vault のシール操作

シールするタイミング： Vault インフラストラクチャに影響するアクティブなセキュリティインシデント、キーの漏えいが疑われる場合。

シールすると、すべての Vault 操作が停止します。最後の手段としてのみ使用してください。

シール解除の手順：

1. シール解除キーの保有者を定足数分集めます（Shamir のしきい値）
2. または、自動シール解除用 KMS キーにアクセスできることを確認します
3. vault operator unseal を使ってシールを解除するか、自動シール解除を有効にして再起動します
4. 監査デバイスが再接続されたことを確認します
5. アクティブなリースとトークンの有効性を確認します

完全なプレイブックについては、references/emergency_procedures.md を参照してください。

---

CI/CD との統合

Vault Agent サイドカー（Kubernetes）

Vault Agent はアプリケーションポッドと並行して実行され、認証とシークレットのレンダリングを処理します。

# Pod annotation for Vault Agent Injector
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "api-server"
  vault.hashicorp.com/agent-inject-secret-db: "database/creds/app-readonly"
  vault.hashicorp.com/agent-inject-template-db: |
    {{- with secret "database/creds/app-readonly" -}}
    postgresql://{{ .Data.username }}:{{ .Data.password }}@db:5432/app
    {{- end }}

External Secrets Operator（Kubernetes）

エージェントサイドカーより宣言的な GitOps を好むチーム向けです。

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: api-credentials
  data:
    - secretKey: api-key
      remoteRef:
        key: secret/data/production/api
        property: key

GitHub Actions OIDC

OIDC フェデレーションを使用して、CI における長期有効なシークレットを排除します。

- name: Authenticate to Vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    method: jwt
    role: github-ci
    jwtGithubAudience: https://vault.example.com
    secrets: |
      secret/data/ci/deploy api_key | DEPLOY_API_KEY ;
      secret/data/ci/deploy db_password | DB_PASSWORD

---

アンチパターン

アンチパターン	リスク	適切なアプローチ
ソースコードへのシークレットのハードコード	リポジトリ、ログ、エラー出力から漏えいする	実行時にシークレットストアから取得する
長期有効な静的トークン（30 日超）	古い認証情報、説明責任がない	動的シークレット、または短い TTL とローテーション
サービスアカウントの共有	利用者ごとの監査証跡がない	サービスごとに一意の認証情報を持つ ID を割り当てる
ローテーションポリシーがない	漏えいした認証情報が無期限に残る	スケジュールに基づく自動ローテーション
CI の環境変数にシークレットを保存	ビルドログやプロセステーブルから見える	Vault Agent または OIDC ベースの注入
シール解除キーの保有者が 1 人だけ	バス係数が 1 で、復旧が妨げられる	Shamir 分割（3-of-5）または自動シール解除
監査デバイスが未設定	アクセスをまったく可視化できない	2 つの監査デバイス（ファイル＋syslog）
ワイルドカードポリシー（path "*"）	過剰な権限付与となり、最小権限の原則に違反する	サービスごとに明示的なパスベースのポリシーを設定する

---

ツール

スクリプト	目的
vault_config_generator.py	アプリケーション要件から Vault ポリシーと認証設定を生成する
rotation_planner.py	シークレットのインベントリファイルからローテーションスケジュールを作成する
audit_log_analyzer.py	監査ログを分析して異常やコンプライアンス上のギャップを検出する

---

相互参照

• env-secrets-manager — ローカルの .env ファイルの適切な管理、漏えい検出、ドリフトの把握
• senior-secops — セキュリティ運用、インシデント対応、脅威モデリング
• ci-cd-pipeline-builder — シークレットを使用するパイプラインの設計
• docker-development — コンテナーへのシークレット注入パターン
• helm-chart-builder — Helm チャートでの Kubernetes シークレット管理